Micah Elliott wrote: > I have a simple use case that seems very common, but doesn't work > with svnmerge: 1) A developer is merging changes from trunk to his > branch, and a conflict occurs. He resolves it in favor of his > branch's version. Then 2) he merges his branch back to trunk and > *the same conflict has to be resolved again*. > > Why isn't there some ability to record that he has already > resolved this same conflict? (I can share my thoughts on how to > approach a solution to this, but for now I'm just asking in case > this is a pilot error on my part.)
There isn't because nobody has yet come up with an elegant way to do this within the confines of svnmerge. If you have some ideas, please do post them to the list. > I'm not sure what the technical name is for this ability. I > thought it was "reflection", but svnmerge appears to use that > name in a different way. The term "reflection" in svnmerge refers to the entire revision, including the conflict resolution changes. So, if I merge rev 5 from trunk to branch and that is rev 6, and then create rev 7 on the branch and merge back to trunk, rev 6 is "reflected" and only rev 7 is merged to trunk (assuming -b flag is set). > This was touched on briefly before in this thread: > > http://www.orcaware.com/pipermail/svnmerge/2007-February/000857.html > > And the answer basically was: > > "it seems that the conflict will have to be resolved manually > for both merges ... and with the current design of svnmerge, > this cannot really be fixed." > > [snip] > > Is there a good reason that this can't be implemented/fixed in > svnmerge.py for some/most merge situations? Solving this seems to require tracking extra information about merges that cannot be easily stored within merge properties, which is how svnmerge.py currently operates. I think there was quite a bit of discussion on svn-dev about how to track this information in svn 1.5. Some of the solutions involved internally creating separate commits for the real reflected changes, and for the conflict resolution changes. There were some other solutions also, but IIRC all involve some relatively major backend/schema changes. Cheers, Raman Gupta _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
