We have some common code that a vendor took about a year ago and
essentially forked. Now, I've been tasked to bring the vendor's copy of
the common code up-to-date (5000+ revisions later) . I was hoping it
would be as simple as importing the vendor's code into a branch, then :
svn co $SVNROOT/branches/vendor/common
svn merge -r 4000:9000 $SVNROOT/trunk/common common
and then sort out the conflicts. And at first glance, that appeared to
work. But it didn't.
It turns out that over the past year we moved some files around in the
common code. This is what appears to be causing the merge to be incorrect.
For example, the original common code has common/src/KTask.c. In the
vendor's forked code base, KTask.c was modified to work with linux 2.6.
On the trunk, around rev 5600, trunk/common/src/KTask.c was moved
(using svn mv) to trunk/common/kernel/src/KTask.c. When I run the merge
command as shown, the working copy's common/kernel/src/KTask.c does not
contain the linux 2.6 changes from common/src/KTask.c . It only
contains the rev 5600-9000 changes of /trunk/common/src/KTask.c.
When processing changeset 5600, it appears as though svn removed
common/src/KTask.c and then copied /trunk/common/src/KTask.c rather than
copying /branches/vendor/common/src/KTask.c (or the working copy's
common/src/KTask.c) into my working copy at common/kernel/src/KTask.c .
Is that the correct behavior for svn?
Looking at the changeset in viewvc, the file is listed as:
trunk/common/kernel/src/KTask.c
(Copied from trunk/common/src/KTask.c, r5600)
When applying a merge, is there a way to remove the common path elements
(trunk/common) so that you are doing a relative merge rather than using
"absolute" paths? I would have expected svn to do that by default.
My client is now 1.4.2 and the server is running 1.3.2.
- cls
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 6 23:38:36 2007