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

[Raman Gupta]

Daniel Rall wrote:
> 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.
> 
>> 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.

Yikes! This merge model is too complicated for me but I think its
because my background is cvs/subversion, so I'm not used to being able
to easily do this type of thing. Perhaps if the tool handled this for
me, I'd find some reason to use it. To help kick-start my thinking
process, could someone provide some uses cases for doing this type of
graph merging? For example, for the linear model there are the use
cases of feature branches or release branches. What are some use cases
for graph-based merging? This is not a challenge -- I'm sure there are
many use cases, but I just want to know what some of them are.

>> 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.
> 
> Is it even possible to implement this model with svnmerge.py, or will
> dir prop conflicts from Subversion's 'merge' operation always impede
> it?  How the --source option to 'merge' currently avoid these property
> conflicts?

Anything is possible -- worst case, we would just have to write the
algorithms to "merge" the merge memory (meta-merge!) as part of
svnmerge.py. I think to implement full support for transitive merging,
instead of the half-baked implementation accident it is now (IMHO),
that, or something similar, is what would have to be done.

BTW, I'm in the process of a major move so I'm going to be out of
touch for a few days...

Cheers,
Raman