> -----Original Message----- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Tuesday, June 28, 2011 2:20 PM > To: Michael Fletcher; users@subversion.apache.org > Subject: RE: Apparently Spurious svn:merginfo > > > We are having problems with a large number of svn:mergeinfo > > properties > > being modified each time we merge. These svn:mergeinfo are on > > unrelated > > files to the actual change being made. Though it does seem as if > > they > > correlate to prior merges that have happened. If we commit these > > property changes they will happen again the next time we merge. > > > > At this point when we merge we will see 80 files with svn:mergeinfo > > changed when we might only be merging one file. It's becoming > > difficult > > to determine what exactly we have changed. > > > > I looked in the FAQ and googled and nothing exactly seemed to match > > what > > we are seeing. > > > > Mostly, we have TortoiseSVN 1.6.8 / Subversion 1.6.11 on the client > > and > > svn 1.6.15 on our server. The repository is old, having had nearly > > every major version of SVN that ever existed. > > > > We merge sometimes from our "trunk" to a branch and sometimes from > > our > > branches back to trunk. We often have multiple releases in flight > > so a > > fix will be merged from ^/branches/7.00.39 to ^/branches/7.00.40 > > and > > then to ^/branches/7.00.41 and then to ^/trunk. Or the reverse. > > > > At some point people were reverting the svn:mergeinfo properties > > and > > performing the checkin because they didn't know what they did. > > Nobody > > should be doing that any more. > > > > Any help would be appreciated. > > This is a pretty common complaint people have, I'm surprised you > couldn't find any threads about it. If I were writing an svn merging FAQ > this would probably be question number 1 or 2. > > What is most likely happening is that you have mereinfo on your child > nodes that is not present in your root node. This usually happens when > someone does a merge for a specific file or folder rather than doing the > merge at the project root. > > I was going to write all about this, but quickly was able to find this > article on line that saves me much typing. > > http://blog.syntevo.net/2011/03/16/1300268640000.html > > BOb
It looks like the 1.7 merge command will make the problem a bit better in at least two ways. 1) It will only update mergeinfo on sub-trees that were affected in the merge, even if other sub-trees have mergeinfo properties. (I am probably not doing full justice to this change -- see http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording.) 2) As the same link shows, the merge command will be more verbose about when it is updating meta-data versus merging content. Often times, people only merge a sub-tree because they know that the branch they worked on only changed content in that one tree. That's fine, but it adds more mergeinfo at the sub-tree level, instead of at the branch level. If you want to elide mergeinfo on lower levels, you can run record-only merge(s) at the higher level so that the mergeinfo property goes away at lower levels without actually removing data (you just move it up to a higher level). Of course you have to do the research to verify it is a safe/correct thing to do for that particular circumstance. I was headed down this path before getting side-tracked on to other work. One useful thing to know is which branch meta-data is different from one sub-tree to another. I just started comparing merge info on directory path versus another via this little script: #!/bin/bash dir=$1 if [[ $1 = "." ]] then svn pg svn:mergeinfo $1 else svn pg svn:mergeinfo $1 | sed -e "s,/$1:,:," fi That gives output stripped of relative path info so that they can be directly diff'ed to see which merges are missing in which sub-trees. Caveat: I am not sure that's a valid comparison in the future 1.7 world. -Steve
