[Svnmerge] Patch for non-reflected bidirectional merging support

[Jim Fulton]

Raman Gupta wrote:
> Jim Fulton wrote:
> 
>>Raman Gupta wrote:
>>
>>
>>>Hi all,
>>>
>>>I have attached two patches. The first is incidental and fixes a couple
>>>of bugs svnmerge that I found while testing. These bugs are:
>>>
>>>[snip]
>>>
>>>The second, and far more interesting, patch adds merge-point tracking.
>>>This improves the bi-directional merging support of svnmerge by
>>>preventing reflected changes from being merged. See here for initial
>>>discussion fo the problem, and a description of the solution implemented
>>>in the patch:
>>>
>>>http://www.orcaware.com/pipermail/svnmerge/2005-August/000000.html
>>>
>>>[snip]
>>>
>>
>>Raman,
>>
>>Did you see the alternate solution that I proposed?  I think it is
>>simpler and cleaner than using dot files.
>>
>>Jim
> 
> 
> 
> Hi Jim, yes I saw your email. However, I would take some convincing
> regarding your assertion that using properties on the source branch is
> simpler and cleaner.

OK

> I'm not sure I like having a merge operation modify a different branch
> than the one being merged to, the main reason being that it will require
> a second commit. This breaks the atomicity of the operation, as well as
> possibly introduces some other complexities in terms of having yet
> another revision that should essentially be ignored in terms of merging.

Yup, although the merge of this second revision should be pretty harmless.
I would even bother to ignore it in svnmerge avail.

In any case, the second transaction *is* a downside.  OTOH, I would say that
introducing a new file into the tree is a downside as well.

> I'm also not sure how one would implement this in a clean way -- would
> you ask the user to execute a script, after the merge has been
> committed, that sets the property on the source branch? Yuck.

No, I would have svnmerge make a temporary checkout and update the
property automatically.  (Note that I would use the -N option


> In addition, the dot-files give you a "free" way to track the revision
> of the commit via the $Revision$ keyword.

The use of the keyword is definately clever.

> That being said, I'm not totally pleased with the dot-file solution
> either. But until someone can convince me of a better way, or Archie
> integrates a different solution into svnmerge, that's what I'll be using.

For me, using the extra transaction is the lesser of 2 evils, especially
if svnmerge avail could be smart enough to ignore it.  OTOH, perhaps I can
get used to the extra dot file, especially since this other solution is
already implemented.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org