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

[Daniel Rall]

On Fri, 08 Dec 2006, Blair Zajac wrote:

> Daniel Rall wrote:

>> Raman Gupta 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.
> 
> I agree.  I think svnmerge.py should keep this support, and I could use it 
> also, if it didn't get merge conflicts.
...
> >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.

I also want intrinsic support for transitive merge info (without use
of additional flags).  However, for the case described above, it would
be nice if svnmerge.py worked *at all*.  At least for such a case, I'm
definitely in favor of something along the lines of Raman's patch.

Given that this use case currently blows up, how are folks using
svnmerge.py to merge changes, which themselves contain merge info,
into a branch without triggering a property conflict?  Is this even
feasible today with svnmerge.py?
-------------- 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/20061209/d63f4e02/attachment-0001.pgp>