[Svnmerge] Bi-directional merging becoming more painful

[Blair Zajac]

Giovanni Bajo wrote:
> Blair Zajac <blair at orcaware.com> wrote:
> 
> 
>>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.
> 
> 
> You could have used "svnmerge block" to this effect.

Yes, but I view blocking as blocking out more logical commits than "merging" 
commits.  Also, one can remove the block later, which would bring back the same 
problem.

>>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.
> 
> This discussion predates my involvement with svnmerge. I'll try to study the
> issue better and come back to you.
> 
> My gut feeling is that, when doing bidirectional merges, we could automatically
> mark head -> branch merges as blocked in head, so they don't get merged back.
> To do this, you would probably need a way to gather the list of the
> head->branch merges, which is exactly what we were discussing two weeks ago
> ("svnmerge log"). Assuming you can access that list, those merges could be
> hidden in "svnmerge avail" and automatically blocked by "svnmerge merge".
> 
> OTOH, we didn't really reach a consensus on how to implement "svnmerge log".

This goes to the two commit solution, if I read this correctly.  Merge in the 
branch and than change the head.

There's at least one case, when you track a vendor svn repository, that this 
won't work, since you may not have commit rights to head.  Also, the two phased 
commit process is lossy if the developer doesn't use 'svnmerge commit' to change 
the head.

Regards,
Blair