This kind of thing should be working, as svn works with global-revision-number-based changesets, and the changeset for a move is the logical operation "copy A to B; delete A". When you 'svn up', that is what should happen.
And that is precisely what does happen. However it fails to delete A as there were files not under revision control (target/*). Modified files also cause the update to fail with a conflict.
If you have locally modified A, subversion will
not delete it but should issue a warning. You can then commit in the old location, svn up, and the "move" change is merged with the file changes.
this does not occur.
I guess the basic rule for now is that we do not use 'svn move'.
It is fine - you just need to make sure everyone is aware of the move and is given an opportunity to prepare their local stuff.
Thinking about how to do this better, it is probably best for everyone to coordinate manually, merge in the changes, then create a branch, apply the changes there, then replace the trunk with the branched version...
sounds like way too much work.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
