[Svnmerge] Patch for non-reflected bidirectional merging support

[Raman Gupta]

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

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

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

Cheers,
Raman