[Svnmerge] Patch for non-reflected bidirectional merging support

[Raman Gupta]

Archie Cobbs wrote:
> 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.

Cool!  I like it.

>> 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.

Another possibility is to keep some sort of meta-data store outside the
repository in order to "cache" the results of merge-point checks. So,
only the first time svnmerge scanned a set of revisions for the
merge-point information would it be slow. The next time, it would only
have to scan the new revisions in the repo, the old ones could come from
the cache. Though this may be of limited usefulness given that in most
cases the list of revisions to be integrated will be changing with
little overlap.

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

Yeah, but note that it works just fine on cygwin. :-)

> Thanks for your comments!

You're welcome. When can I expect to thank you for an implementation?
;-)  (I'm just joking -- its not urgent for me, because in the meantime
I'll continue to use my hacked up dot-file implementation which seems to
work reasonably well).

Cheers,
Raman