Re: Unusual merge result

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,

-- 
Johan