[Svnmerge] [PATCH] Eliminate spurious svnmerge-integrated property conflicts

[Blair Zajac]

Daniel Rall wrote:
> On Tue, 05 Dec 2006, Raman Gupta wrote:
> 
>> Daniel Rall wrote:
>>> On Fri, 06 Oct 2006, Raman Gupta wrote:
>>>
>>>> Sometimes, svnmerge.py will cause spurious conflicts in the merge
>>>> memory property. The last step of the action_merge function sets this
>>>> property explicitly to the new correct value anyway, so any conflicts
>>>> that occurred during the merge are irrelevant.
> ...
>>> While I think your patch makes us quite a bit better off than before,
>>> I noticed that it does also clobber any transitive merge info from a
>>> merge source which itself would otherwise attempt to be applied (and
>>> cause a conflict) as part of the merge.  See the ### comment in my
>>> test case to make sense of that mouthful.  ;-)
>> Yes, I should have been clear in my patch description about that. I
>> think that the ability of svnmerge.py to carry-through this transitive
>> merge data has been an accidental side-effect of the implementation
>> rather than a designed-in feature, and so I've never really trusted
>> it. I tend to want to specifically add merge relationships between
>> branches rather than have them carry over implicitly.
> 
> Let me start off by saying that I've never personally used the
> svnmerge.py's transitive merge info.  However, some of my customers
> are trying to use it -- they expect to be able to do graph-like
> merging, rather than just the linear merging that I've personally been
> doing with svnmerge.py (e.g. to keep Subversion's merge-tracking
> branch up to date with its trunk).
> 
> That said, I consider transitive merge info an *essential* part of
> merge tracking, and have implemented support for it as well as
> possible given Subversion's architecture on the merge-tracking branch.

I agree.  I think svnmerge.py should keep this support, and I could use it also, 
if it didn't get merge conflicts.

Regards,
Blair

> 
>> For example, most of the time, in my workflow at least, the
>> "transitive" merge information is actually cruft that doesn't make
>> sense e.g. I end up with merge info about one release branch on
>> another release branch because they share the trunk as ancestor, and
>> bidirectionally merge with the trunk also. So the patch I submitted
>> actually improves this situation for me by eliminating the carry-over
>> of those values.
> 
> The usefulness of the transitive merge info depends on your branching
> model.  It sounds like your merge model is very linear.  (I typically
> use this model myself.)  Consider this circular merging model:
> 
> 1. Init branch B from A.
> 2. Init branch A from C.
> 3. Merge changes from A -> B.
> 4. Init branch C from B.
> 5. Merge changes from B -> C (which currently fails due to a property
> conflict without Raman's patch).
> 6. Merge changes from branch C back into A.  This should really skip
> the merge of the change merged into C from B in step #5, because it
> originated in A, and thus needn't be merged because it's already in A.
> 
>> If keeping transitive merge data is important to people, perhaps what
>> is needed is a discussion of the transitive use cases people wish to
>> support, and then a specific implementation to achieve the
>> requirements, perhaps enabled by use of a "--transitive" flag.

I think we should support this out of the box without any additional flags.  If 
you are proposing to remove merge information that may be useful later on, then 
I am definitely a -1 on that, since you will have thrown away information that 
you may not be able to easily recover.

Regards,
Blair