On Tue, Oct 19, 2010 at 9:40 AM, Tony Butt <tony.b...@cea.com.au> wrote: > On Tue, 2010-10-19 at 18:23 +1100, Tony Butt wrote: >> I have had 2 unusual occurrences with merges with some of our software >> engineers here in the last month. I wrote the first off as user error, >> but a similar event has occurred - still possibly user error. >> >> We are using subversion 1.6.12 on our server, and a mix of TortoiseSVN >> 1.5 and 1.6 clients on our clients, as well as some commandline usage >> through an automated tool. >> >> What has happened is that twice now, an engineer has branched some code, >> and then seen unusual checking behaviour. The second instance was today, > Whoops - make that *check-in* >> and occurred after merging the trunk of the software module into the >> branch, then checking the results back in to the branch. What actually >> happened is that 2 source files were checked back in to the trunk >> instead. The first instance is less clear cut. Unfortunately, in both >> cases, the engineers involved discovered the problem, took steps to >> correct it, including deleting and checking out the relevant working >> copies again, then thought to tell me about it - not too much evidence >> left to trace from. >> >> The first time I assumed that the user involved had performed a switch >> inadvertently, this time I am less sure. >> >> What is most puzzling is that looking at the mergeinfo properties on the >> branch , I see the following: >> >> Properties for <modulepath>/Branches/ >> svn:mergeinfo <modulepath>/Branches/branchA:49494-49689 >> <modulepath>/Branches/branchB:47790-51680 >> <modulepath>/Branches/branchC:52621-53396 >> <modulepath>/Trunk:54546-54710 >> >> Which seems OK, >> >> But in a subdirectory, I see >> Properties for <modulepath>/Branches/Implementation/IlluminationManager >> svn:mergeinfo >> <modulepath>/Branches/branchA/Implementation/IlluminationManager:49494-49689 >> >> <modulepath>/Branches/branchB/Implementation/IlluminationManager:47790-51680 >> >> <modulepath>/Branches/branchC/Implementation/IlluminationManager:52621-53396 >> >> <modulepath>/Trunk/Implementation/IlluminationManager:54546-54710* >> >> Where I expected to see no mergeinfo recorded at all, since our merges >> are done at the <modulepath> level only. Further, I don't know what the >> trailing '*' on the last property line means. >> >> If anyone could explain what the trailing '*' is for, and for extra >> bonus points :-) explain why the mergeinfo is set on the subdirectory, I >> would be quite grateful. I have looked at the subversion book for some >> explanation, but could find no further explanation of the '*'.
You should probably read http://www.collab.net/community/subversion/articles/merge-info.html (very long article) for a thorough understanding. The '*' means "non-inheritable mergeinfo", which means that this mergeinfo only applies up to /Branches/Implementation/IlluminationManager, and will not be inherited by its children (i.e. these revisions from trunk were not merged into the subtree of /Branches/Implementation/IlluminationManager). This kind of thing can happen when working with sparse working copies, and merging into them. Subversion notes that it only merged those revisions up to /Branches/Implementation/IlluminationManager and not below it (see the article for an example, in the section "Mergeinfo Inheritance and Non-Inheritable Ranges"). What you should also know is: once a subtree gets its own explicit mergeinfo, subversion needs to maintain this mergeinfo all the time, because it now no longer inherits the mergeinfo from the root. So a scenario that could explain your mergeinfo is: some user merged /Trunk:54546-54710 into a sparse working copy of the branch, where everything below /Branches/Implementation/IlluminationManager was excluded, and then committed this merge. The same can probably also happen when /Branches/Implementation/IlluminationManager is switched in the working copy where you are merging into. The first paragraph of the section "Mergeinfo Inheritance and Non-Inheritable Ranges" in the article says: "Subversion allows a working copies which are incomplete representations of the repository. This is possible with with shallow checkouts, switched subtrees, or because of authorization restrictions that prevent parts of a tree from being checked out. You can merge into an incomplete tree if you wish and Subversion endeavors to keep your mergeinfo accurate. It does this primarily with non-inheritable mergeinfo ranges." HTH. Cheers, -- Johan
