Re: Unusual merge result

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.butt_at_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.butt_at_cea.com.au>