Raman Gupta wrote: > > The new version of svnmerge.py will automatically activate > bi-directional merging when a bidirectional merge situation is > detected. Therefore, you are essentially testing the difference > between not using -b (with the old version) and using -b (with the new > version, whether -b is specified or not). > > In the old version, when -b was not specified, the system would > "dumbly" take your merged changes in step #4 and apply them at step > #6. This might have resulted in conflicts or it might not have > depending on how good svn was at detecting recursive changes, but you > would have at least gotten your "some other changes" merged back.
> 1) Revert the automatic -b detection and continue to require users to > specify this manually. > > 2) Grow a --no-bidirectional switch that turns off bidirectional > detection for cases like this (which basically reverts to the old > behavior when not specifying -b). Speaking as a user, I vote for #1; i.e., default to --no-bidirectional. Here is the reasoning. - If you specify --no-bidirectional but in fact want --bidirectional, the symptom is extra conflicts: something that is easy to notice and straightforward to recover from. - If you specify --bidirectional but in fact want --no-bidirectional, the symptom is old code mysteriously creeping into files: something that is more difficult to notice and difficult to recover from. I would also like to see the svnmerge.py documentation updated to include some caveats about -b. The consensus now seems to be that -b should _always_ be used, but in fact it can cause (recoverable) data loss in some circumstances. It tooks us a long time and considerable hassle to figure out why our branches mysteriously contained old code. I don't know anything about the internals of svnmerge.py and don't feel like I have too much to offer in terms of code changes, but I would be happy to contribute documentation verbiage. > 1) When merging at step #4, only resolve conflicts, and then commit. > Apply "other changes" in a separate commit (sometimes difficult I know). In addition to the annoyance, some projects have policies against checking in code that doesn't build, and semantic conflicts might extend to files which Subversion hasn't identified as conflicting. My $0.02. Reid _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
