[Svnmerge] overzealous exclusion of reflective merges?

[Raman Gupta]

Reid Priedhorsky wrote:
> Reid Priedhorsky wrote:
>> All,
>>
>> We have been having trouble with changes not being merged. Here is the 
>> steps and what I think is happening:
>>
>> 1. create branch A by copying TRUNK
>> 2. make some changes on A and commit them
>> 3. make some changes on TRUNK and commit them
>> 4. merge these changes on A back to TRUNK:
>>     a. svnmerge merge
>>     b. some edits -- fix conflicts, maybe some other changes
>>     c. commit
>> 5. make some more commits on TRUNK and commit them
>> 6. merge TRUNK to A
> 
> [I sent this e-mail to the list yesterday afternoon, and received the 
> e-mail myself, but it has not appeared in the list archives. So, I'm 
> unsure it actually went out to the list. I am resending it, this time 
> with the script linked rather than attached. If it is a duplicate, my 
> apologies for the noise.]
> 
> OK, I think that I have identified the problem. It seems to be triggered
> by editing files in Step 4b that have no Subversion-identified conflicts.
> 
> I have created a shell script which illustrates, available at 
> <http://www.cs.umn.edu/~reid/merge-test2.sh>. Both my old copy of
> svnmerge.py (unknown revision, but filesystem date of 2007-06-08) and
> Subversion 1.5rc9 work correctly, but the current version of svnmerge.py
> (as downloaded from the website) fails to merge the Step 4b changes from
> trunk to branch whether or not -b is specified.

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.

With the new version, svnmerge.py is "smarter" -- it says, oh this was
merged from the target branch, therefore I don't want to merge it back
-- and voila, you lose your "some other changes".

Possible solutions in the code:

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).

3) Work at a sub-revision level and exclude only merged in diffs vs.
"other diffs" for merged revs (I don't think this is really feasible
in svnmerge.py -- work is being done in svn proper to support this,
though I don't think its included in 1.5).

Possible user-level solutions:

1) When merging at step #4, only resolve conflicts, and then commit.
Apply "other changes" in a separate commit (sometimes difficult I know).

Does anyone have anything to add to the above?

Cheers,
Raman