I think merge needs an option or behavior adjustment to not merge a
delete operation if the merged file has changes from the old file.
That is, $vendorurl/old/file is different from the merge ./file and
$vendorurl/new/ removes the file. I think the result should be ./
file being marked as a conflict. Otherwise the merge results in lost
changes. While you could sensibly argue a deleted file no longer has
relevance regardless of what the merge version did to it, here's how
it sort of screwed me.
There are two cases we've run across where svn_load_dirs.pl fails to
properly identify moved files or gets confused. These are freely
available open source projects so somebody could easily reproduce
this if they need to.
The first case is the openssl distribution. There are several files
titled test.c. When initially importing the stock version into our
vendor repository (following the suggestions in the book titled
"Vendor branches"), different instances of test.c seem to get
misidentified as links to the same file. They aren't, nor are the
contents similar.
The second case is tracking the changes from ISC's bind distribution
between 9.3.0 and 9.3.2. There's a mess in lib/dns/sec/dst which
they finally cleaned up. Several source files in here got moved to
lib/dns. We have local changes in some of these files. When merging
9.3.0 and 9.3.2 into my working sandbox, these files were seen as
removed from lib/dns/sec/dst and added to lib/dns, not moved, and
thus my local changes were lost by the merge.
I can appreciate svn_load_dirs needs to do a lot of guesswork and
can't get it right every time.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 17 10:28:13 2006