On Mon, Jul 13, 2009 at 05:15:42PM +0100, James French wrote:
> Its an ongoing branch so its not a reintegrate merge . We deliberately
> did the reorg on the branch
This is bad practice in Subversion. Don't do tree reorgs on isolated
branches.
> so that once merged down further merges
> would be easy - so yes, I do want all the moves and renames to be
> merged down.
What about doing the same reorg on trunk before merging file content?
That way you'll avoid tree conflicts entirely.
You may have expected Subversion to be smart enough to reliably
merge the renames you did on the branch. But it is not.
A rename in Subversion is a copy followed by a delete.
"svn move a b" literally means "svn copy a b; svn remove a" to the
point where the server does not even know what a rename is.
All the server sees is "add 'a' here (and note that it used to be 'b'
so we can follow the log back in time)" and "delete 'b'".
Those are two independent operations.
Worse, when a rename is merged, subversion does this:
"svn remove /trunk/a; svn copy /branches/b /trunk/b"
While what you want to happen is probably "svn move /trunk/a /trunk/b",
ie. "svn copy /trunk/a /trunk/b; svn remove /trunk/a".
So, Subversion has a fairly broken model of representing moves, and also
of merging copy operations, and we want to fix this in the long term.
But right now we are stuck with this behaviour. It's also why tree conflict
detection is not as good as it could be. E.g. delete vs. a delete is
currently treated as a tree conflict because one or both of the delete
operations could be part of a move, but there's no way for the client
to tell the difference.
So, being this stupid, Subversion needs your help in merging your
tree reorg back to trunk. It is not smart enough to do this for you.
The tree conflict detection was added as a safety net for cases like
this. It exists to warn you that the merge result is probably not what
you want, and to let you know that Subversion needs your help to get
it right.
Stefan
Received on 2009-07-13 18:34:47 CEST