Daniel Rall wrote: > 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.
I agree. I think svnmerge.py should keep this support, and I could use it also, if it didn't get merge conflicts. Regards, Blair > >> 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. 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. Regards, Blair _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
