[Svnmerge] Patch for non-reflected bidirectional merging support

[Jim Fulton]

Raman Gupta wrote:
> Jim Fulton wrote:
> 
>>Raman Gupta wrote:
>>
>>
>>>Jim Fulton wrote:
>>>
>>>
>>>>Raman Gupta wrote:
>>>>
>>>>
>>>>>[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]
>>>>
>>>>Did you see the alternate solution that I proposed?  I think it
>>>>is simpler and cleaner than using dot files.
>>>
>>>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.
> 
> 
> True. And reverting the property changes after merges is not a big deal.
> 
> 
>>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.
> 
> 
> Yes, I agree, the extra dot-file is annoying. However, I feel that the
> second transaction is a bigger downside than the extra dot-file (mainly
> for the reason I outline below, plus the loss of atomicity).
> 
> 
>>>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
> 
> 
> OK, but that doesn't answer my question.  Since the property change on
> the source branch must occur after the user has executed the merge-point
> commit, the timing of it requires a separate execution of the svnmerge
> script initiated by the user, unless you start using post-commit hooks
> in some way.  A solution might be to have svnmerge act as a wrapper
> around the commit operation so that once the commit is completed it can
> apply the property change. But this depends on the user remembering to
> do "svnmerge commit" instead of "svn commit".

Ah, good point. I had forgotten that svnmerge wasn't doing the
commit.

> If you don't use the svnmerge commit wrapper, then you still need to get
> the revision number of the merge-point commit to set the property. Do
> you get this from the user as a parameter  (what if they make a
> mistake?) or parse the log of the branch to get it (what if the user
> didn't use the standard svnmerge log message?) or parse the results of
> "svn info" (what if the user made a second commit before executing the
> after-merge operation?).

Right. The only sane way to do that is to provide the wrapper, which is
unappealing.

> 
>>>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.
> 
> 
> Lets just say that the extra transaction really is the lesser of 2 evils
> (though I'm not sure it is :-), I think the question of how the second
> commit is initiated is a show-stopper for the properties solution as
> proposed. I don't like that it depends on the user to do the Right Thing.

I agree.

Thanks for coming up with a solution.  I'll try it out.

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