merge suggestion (and svn_load_dirs problems)

[Paul Forgey <pa...@metainfo.com>]

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