[Svnmerge] Phantom revs support done!

[Blair Zajac]

Giovanni Bajo wrote:
> Blair Zajac <blair at orcaware.com> wrote:
> 
> 
>>1) Would mind running
>>
>>svn ps svn:executable '*' *
> 
> 
> Done, thanks!

Thanks for fixing all the issues.

Now for some more serious feedback :)

1) The Python script currently does not remove the merge target from the list of 
paths in the svnmerge-integrated property.

This is one of the patches that I made to the Bourne shell svnmerge script.  See 
revision 15340.

http://svn.collab.net/viewcvs/svn?rev=15340&view=rev

Since I do quit a bit of bi-directional merging between a single trunk and 
branch, having this in would make my life much easier without having to specify -S.

2) Applying the merges.

I recommend not merging just those revision ranges where commits happened in the 
source location, but instead, performing as few merges as possible.

Today, I ran a test comparing the Bourne shell and Python svnmerge's with a 
merge from a branch to a trunk where the trunk hadn't received merges from the 
branch for some 4000 revisions, of which only 10 or so revisions had changes to 
apply (the repository has 80 different projects in it, each with their TTB).

I didn't run the commit in this test, just the merge command.

With the Bourne shell script, it merged the 4000 consecutive revisions over in a 
single merge operation.  One file had a single conflict in it.

With the Python svnmerge and it merged only those revisions tha changed paths in 
the branch.  The one file that had a single conflict in the Bourne shell merge 
now had two conflicts and two sets of conflict markers, two sets of the *.mine 
and *rXXX files, because that file was changed in two commits that were not in 
the same revision range (otherwise svnmerge would have merged them together) but 
touched the same part of the file.

Since the Bourne shell merge did a single merge, it bundled the two commits to 
the same part of the file into a single merge and let me deal with the conflict 
as a whole.  With the Python merge, I now had more of a mess to clean up.

There's no problem in 'svn merge' from including revisions that don't impact the 
target of the merge, so I propose changing the merge behavior to perform as few 
merges as possible.  The generated commit message file using -f can still 
include the actual revisions that changed the merge target instead of including 
all the phantom revisions.

If I wanted to deal with the conflicts separately, I can always run svnmerge 
with a revision range to deal with them one at a time.  But with the way it 
works now, I don't have a way of bundling the commits together and treating them 
as a whole.

Regards,
Blair