On Mon, Apr 22, 2013 at 10:00 PM, Z W <mpc8...@gmail.com> wrote: > Hi Johan > > Thanks for responding.
You're welcome :-). I'm putting the users list back in cc to keep it in the loop. Please remember to use reply all for this reason. > We didnt know of the subtree merging concept and you are right, we did > perform some merges at the files level in the subdirectories. > > When you say > "What might happen though is some elision (i.e. rearrangement) of > mergeinfo: if you merge r345 at the root level, and it has previously > been merged to all its operational targets with subtree merges (like > in your example), SVN will remove the subtree mergeinfo, and just note > that the entire r345 has been merged at the root level." > > In other words, if we now try to "re-merge" at the root level as you > suggested, those previous subtree merges would not hurt, meaning messed up > with double merges, right ? No, it will not hurt. If everything works as advertised, this is a perfectly supported use case (subtree merge tracking), and double merges should not happen. Feel free to double check by just trying it in a freshly checked out working copy of your branch. You should be able to run the merge you want to do, and then check what has happened by running 'svn diff'. > We like to do it right this time the way you suggested. Yes, establishing a policy of always merging at the "root level" (i.e. avoiding subtree merges) makes things a lot simpler. Another suggestion: previously in this thread you said you're using SVN 1.6. I would highly recommend upgrading to 1.7 (at least for the client(s) ...). The SVN client 1.7 has a lot of good improvements for merge tracking. See: http://subversion.apache.org/docs/release-notes/1.7.html#merge-tracking-enhancements -- Johan
