I'm in the oft-cited situation of having to deal with branches A-B-C, where B was created from A, and C was created from B. I think this is called a transitive merge situation from this post
http://www.nabble.com/-PATCH--Transitive-merge-fix-to12054733.html#a12054733 That tread seems to indicate that r26037 has a commit (Aug 2007) that helps this situation. I just updated to 36086. I'm not sure if the behavior I'm seeing is this transitive scenario, or something different. I've been able to merge a changeset 1 (which has changes to 4 files) from branch A to branch B normally, creating changeset 2. When I attempt to merge B's changeset 2 into branch C, I get the property conflict notice (easily remedied). Svnmerge reports 1 of the files being 'U'pdated in my local working copy, but there's no mention of the other 3 files. Additionally, svn stat tells me that no actual files were changed, even the one that svnmerge told me was in a 'U' state. Is the patch mentioned in this post (linked off of the main svnmerge page) appropriate for transitive merges? It seems to apply to reflected merges, but I could very well be wrong about that. http://www.nabble.com/-PATCH--Eliminate-spurious-svnmerge-integrated-property-conflicts-to11746047.html#a11746047 If svnmerge is unable to help, does svn's merge tracking address this problem? I hesitate to move with the limitations of the 'reintegration' option. That, and svnmerge just looks easier to use... Thanks! - Mark _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
