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

[Daniel Rall]

On Fri, 08 Dec 2006, Raman Gupta wrote:

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

Apparently graph-like merging is well-supported by established tools
like ClearCase.  I assume AccuRev, and anything else which boasts good
merge tracking, also support this style of merge tracking.

But the above case isn't really graph-like, it's more like a
multi-tier, linear merging model.

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

I've asked my co-worker, Auke, to describe our customer use cases in
more depth.  I believe they're using it to port changes across very
long-lived (10+ years) active code streams, where (I'm assuming) each
new generation of code stream branches off the previous most recent
stream.  When a bug is fixed in one of these streams, it must be
ported back across all other active streams.  Performing the porting
by branch by branch, from "most recent" to "oldest" stream,
step-by-step back through time, seems like the best way to go about
this.  You can read more about this user's habits here:

http://subversion.tigris.org/merge-tracking/summit-survey.html#medical-systems

I occasionally use a model like the above case (which was reported by
Auke originally) myself in larger scale distributed development
projects to decouple the construction of several distinct major
features.  This model puts off a lot of the integration costs until
nearer RC time (when it's time to pay the piper ;), but if the
features really don't overlap much, it can over good savings by
decoupling development teams (kinda the opposite of continuous
integration).  I'll try to describe that model here:

I have a branch targeted for release (A).  It contains changes to
several major sub-systems, each of which get feature branches (B is
one such branch).  With each sub-system, there is a distinct set of
individual changes which take place, each segregated onto its own
branch (C).  C may want updates from B, and B may want updates from C.
Either B will need C (and all other C-type branches rolled into it),
before being merged back into A, or all C-type branches will be merged
directly into A.  Either way, the model is related to the use case
described above.


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

I did this in Subversion's core on the merge-tracking branch, but it
would be difficult to do in a robust fashion outside of Subversion,
since you'd need to avoid having 'svn merge' merge those directory
properties (or possibly do something after the property conflict
occurs to resolve it).

See combine_forked_mergeinfo_props() in libsvn_wc/props.c
<http://svn.collab.net/repos/svn/branches/merge-tracking/subversion/libsvn_wc/props.c>.

How were you thinking of pulling this off?


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

Thanks for the heads-up, and good luck with the move.

- Dan
-------------- 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/a2c97af9/attachment-0001.pgp>