[Svnmerge] overzealous exclusion of reflective merges?

[Reid Priedhorsky]

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