You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Tony Butt <to...@cea.com.au> on 2010/10/19 07:23:53 UTC
Unusual merge result
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,
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 '*'.
Thanks in advance,
Tony Butt
CEA Technologies
--
Tony Butt <to...@cea.com.au>
Re: Unusual merge result
Posted by Tony Butt <to...@cea.com.au>.
Johan,
On Tue, 2010-10-19 at 11:59 +0200, Johan Corveleyn wrote:
> On Tue, Oct 19, 2010 at 9:40 AM, Tony Butt <to...@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 <to...@cea.com.au>
Re: Unusual merge result
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Oct 19, 2010 at 9:40 AM, Tony Butt <to...@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
Re: Unusual merge result
Posted by Tony Butt <to...@cea.com.au>.
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 '*'.
>
> Thanks in advance,
> Tony Butt
>
> CEA Technologies
--
Tony Butt <to...@cea.com.au>