[Svnmerge] Bi-directional merging becoming more painful

[Blair Zajac]

Today, I worked on merging a personal branch back into trunk where trunk has 
seen a large amount of development.  I've been finding that the longer you go 
without merging, the more painful it becomes!

The most painful aspect about it was having files being added to the trunk, 
being merged into my branch as adds (then I test my code), then everything being 
merged back into trunk again.  The final merge back into trunk gets a conflict 
for each added file.

Svn merge algorithm doesn't work too well also when there's larger sets of 
changes between the trunk and branch, so you have to deal with conflicts here also.

I ended up looking through the log messages for the commits on my branch that 
actually were fresh commits and merged those into trunk.  Then I updated trunk's 
  svnmerge-integrated property by hand to close out all outstanding merges that 
svnmerge could have done.

I double checked my work by doing a 'diff -ru' between the branch and trunk to 
verify that everything was merged over (ignoring changed $HeadURL$ and the like).

So, given all that, where do we stand on resolving this issue in svnmerge.py?

There was some discussion a while back, but I don't know where people stand now.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<blair at orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/