Modx Absolute Path

Is there a way to force modx to not use absolute path.
In my development process i code things locally. Then using subversion and anthill pro we deploy the code to a dev server.

its in the settings

where in the settings is it?
Modx 2.0.0 Rc1

rest of Original Post

Is there a way to force modx to not use absolute path.
In my development process i code things locally. Then using subversion and anthill pro we deploy the code to a dev server.
The problem i get is that the site does not load at all on Dev server.
When i look at the error.log
this is what i get:
2010-04-07 12:00:51] (ERROR @ E:\var\www\html\knopfnotes\core\model\modx\modmanagerrequest.class.php : 102) PHP warning: include_once() [<a href=’function.include’>function.include</a>]: Failed opening ’C:/Program Files/Zend/Apache2/htdocs/knopfnotes/manager/controllers/default/security/login.php’ for inclusion (include_path=’.;E:\xampp\php\pear\’)

the E:\var\www\html\ that is my dev server.
the c:/program files/Zend is my local computer.

Are you correcting the path settings in the Configuration when you move a site?

No i am not where would i do that?

Tools -> Configuration. Set the file path in the file manager tab, and the file path and (maybe) the url in the Interface and Features tab. The url is probably fine with just "assets/". You need the full file path, like "/home/mydomain/www/assets/". On my Mac now, my full file path is "/Applications/XAMPP/htdocs/installation/assets/". I have the extra directory in there because all of my local installations are in a subdirectory of htdocs.

FWIW, I’ve added a ticket to encompass several "absolute path" issues that are encountered when moving a Revo site as of 2.0.0-rc1:
[*] [#MODX-1843] Remove absolute path dependencies to make deployments more portable

I’ll be following up with some subtasks for the specific problems, but most of the problems can be resolved by running setup in upgrade mode on the new target. If you find additional ones, please don’t hesitate to comment on the ticket.

Alternatively for now, you could create branches to represent your various deployment environments and promote changesets between them while maintaining the branch-specific customizations.