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 _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
