[Svnmerge] Excluding "initialized revisions"

[Raman Gupta]

John Ricklefs wrote:
> Hi everyone,
> 
> I recently asked the list about effective ways of dealing with files
> that are put in Conflict multiple times by a single svnmerge.py call
> (which results in a confusing mish-mash of conflict markers).  After
> doing some research on the case that we had, I discovered that
> svnmerge.py was forcing the exclusion of a revision that was an
> initialization of another branch.  After making a single change to the
> code (having analyze_revs() return an empty RevisionSet("") in place of
> initialized_revs), svnmerge.py stopped generating three consecutive
> merges, and instead used two merges (the other skipped revision was an
> expected reflected_rev).
> 
> In our case, we have no issues with bandwidth or server processing power
> so limiting the number of calls to our repository is not an issue.  What
> we're concerned about is the "correctness" of the merges and reducing
> the chance of the aforementioned multiply-conflicted files. That said,
> is there any reason we shouldn't combine initialized_revs into
> phantom_revs to reduce the number of "svn merge" commands?

I think these revs were originally excluded from the merge to reduce
conflicts in the svnmerge-integrated property. However, with other
more recent changes to prevent conflicts in that property, I believe
the change you are suggesting can actually be made with no ill effects
to svnmerge.py as it stands today.

I wouldn't combine them into phantom_revs though -- that would pollute
the meaning of phantom revs. Rather, just combine them back into the
mergeable revs, just as phantom revs are. I think only merge should
change. The avail behavior is correct as is.

Cheers,
Raman Gupta