[Svnmerge] Multiple conflicting revisions of one file in a merge

[John Ricklefs]

Hello,

We've recently converted our CVS repository to Subversion and had great
results. Svnmerge.py has been a key part of that conversion, and is
making merging incredibly simple from our trunk to each of our
development team's branches.

We've come across an oddity, however. When using the --bidirectional
flag to ignore reflected revisions (or using the latest trunk version of
svnmerge.py to include the flag automatically), svnmerge is calling
three consecutive merges, while skipping the reflected ones, as
expected.  In the process, some files are put in Conflict, and then put
in Conflict again... which results in a tangled mess of a merge. For
example, our structure is ...
/product/trunk
/product/branches/team/prime
... where svnmerge-integrated on branches/team/prime is set to
"/product/trunk:1-19814" while svnmerge-integrated on product/trunk
includes "/product/branches/team/prime:1-18495". The HEAD revision is
currently 20153.

>From a pristine checkout of product/branches/team/prime $ svnmerge.py -n
merge -S svn://repo/product/trunk ...
svn --non-interactive merge --force -r 19845:19956
svn://repo/product/trunk .
...
svn --non-interactive merge --force -r 19980:20004
svn://repo/product/trunk .
...
svn --non-interactive merge --force -r 20091:20153
svn://repo/product/trunk .
...

When this merge is actually run, a conflict is generated in 2  of the 3
merges, resulting in this sort of structure for that particular file...
File.cs
File.cs.working
File.cs.2.working
File.cs.merge-left.r19845
File.cs.merge-left.r20091
File.cs.merge-right.r19956
File.cs.merge-right.r20153

Using TortoiseMerge or P4WinMerge to handle this is somewhat ghastly, as
it chooses File.cs.merge-right.r20153 and File.cs.2.merging into
File.cs, but the prior conflict from File.cs.working means that the
conflict markers in File.cs.2.working show up in File.cs as part of the
merge... which is definitely not what we want.

I'm not sure if there is something I am missing that I can tell our
developers to do to try to simplify this, except to run each of the
above three merges independently, resolving conflicts and committing
each time.  Has anyone else seen this behavior, or have a better
workaround to suggest?

Thank you in advance,
--John