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
pgps7Wk9taStD.pgp
Description: PGP signature
_______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
