Johan, On Tue, 2010-10-19 at 11:59 +0200, Johan Corveleyn wrote: > 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, Thanks Johan, That provides me with a likely explanation for the events - it seems that a switch was made involving the IlluminationManager subdirectory, which is why some code from there was checked back in to the Trunk.
I think I have 3 possibilities for this, in decreasing likelihood they are: 1) User error with TortoiseSVN, possibly selected switch from the menu instead of merge at some point in time, or copied a directory by hand. 2) Our home grown automated checkout and build tool did something bad, which left bad working copy data. This tool is a python script using the subversion bindings, which fetches the dependencies for a project, as specified in a configuration file. 3) TortoiseSVN left bad working copy data around during the merge (pretty unlikely) Tony -- Tony Butt <tony.b...@cea.com.au>
