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