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

[Daniel Rall]

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.

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

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: </pipermail/svnmerge/attachments/20061207/e6d638ed/attachment-0002.pgp>