[Svnmerge] Patch for non-reflected bidirectional merging support

[Archie Cobbs]

Raman Gupta wrote:
>>The "mixed" case an odd one, and probably one it's safe to punt on,
>>i.e., treat is a non-reflected and let the user deal with any conflicts
>>for the "reflected" changes therein.
> 
> Your analysis is interesting and seems to be correct. But, following on
> your "odd" comment, I think that trying to do this for cyclical changes
> between more than two branches is difficult, to say the least, and also
> not something that would generally be done on a real project. At least I
> can't think of any use cases for doing something like this, except
> special isolated cases involving specific changes of limited scope. I
> don't think we should worry about those because svnmerge is generally
> useful only for branches involved with repeated merging.
> 
> Therefore, I think we can assume that we only need to support branches
> being merged back to their direct ancestors and to their direct
> children. So, in your example, b3 would first be merged back to b2 (its
> direct ancestor), and then b2 would be merged back to b1 (its direct
> ancestor), reducing the problem to a simple bi-directional one. b1 and
> b3 would never be involved directly.

Yes, this might be the right practical answer. More generally: we
can have a "maxdepth" parameter which will bound the depth (height)
of the history trees we compute.

Then what you say above is like setting maxdepth=2. But there's no reason
we couldn't just set the *default* maxdepth=2, and let the user increase
that with a command line flag if they wanted to trade some performance
for further refinement... or set maxdepth=0 to get the "traditional"
behavior.

> I think the only downside is that it will be quite a lot slower than the
> dot-files implementation because it has to check the remote
> svnmerge-integrated property for every candidate revision, instead of
> being able to get all of the merged revisions for exclusion in one nice
> call (especially if you decide to keep the recursion). However,
> personally I'd be willing to live with this performance loss in exchange
> for the removal of the dot-files. Also, as a general UI design
> principal, the impact of slow operations such as this can be reduced by
> providing some sort of progress interface to the user, like
> 
> "Checking for reflected changes... 2/9" or similar.
> 
> That will be easier without the recursion too, because you will know
> upfront how many revisions need to be checked.

Yes, I worry about the performance hit too. Some sort of progress
indication will probably be necessary. As long as the whole operation
takes seconds rather than minutes we should be OK, as merging is
probably not that frequent. Also, doing "svn diff -N <dir>", which
is the operation performed for each node of the tree, should be
relatively quick to complete.

The slowness will of course be proportional to the number of revisions
being merged, because each one will be the root of its own tree that
needs to be computed.

Someday it will be time to rewrite this monstrous script in C anyway :-)
That would also make it more portable (making Windows users happier).

Thanks for your comments!

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com