On Tue, Jun 2, 2009 at 9:47 PM, Greg Troxel <gdt_at_ir.bbn.com> wrote:
> Brian Rieck <BRieck_at_sandcherry.com> writes:
>> We have been having a lot of problems trying to do -reintegrate merges
>> back to trunk. I'm experiencing some especially odd behavior now. To
>> make the problem as simple as possible I did the following:
>>
>> 1) Create a new branch of of trunk
>>
>> svn cp <url to trunk> <url to new branch>
>>
>> 2) Do nothing in the new branch, don't even check it out
>>
>> 3) try to do a merge back to trunk
>>
>> Svn merge -reintegrate <url to branch> <path to trunk
>> cp>
>
> If you have done anything on the trunk this is odd/wrong; to do a
> reintegrate then all parent changes should have been merged to the
> child. I can believe things are not ok if this is empty (as a corner
> case bug).
>
>> When doing this I get a ton of conflicts. When I look at the svn status
>> in one of the directories it shows what appear to be tree conflicts. The
>> attached file merge_output_and_status.txt shows the output of the merge
>> command, then I give up and CTRL-C, then a cd to a directory where there
>> were conflicts and the output of svn status in that directory.
Hi Brian,
I can't replicate what you are seeing with any simple examples. If
you could come up with a reproduction script the demonstrates the
problem that would be tremendously helpful in tracking down any bugs.
I know this is easier said than done...
> This is odd; I have been doing reintegrate merges a lot and they've been
> fine. But that's with real changes on the branch and also on the
> parent.
>
>> Some additional background:
>
>> -The most common problems up to now have been that there are missing
>> ranges in the branch mergeinfo. I've been dealing with that by manually
>> adding the missing ranges to the mergeinfo on the branch.
We may have discussed this previously in another forum, but refresh me
memory, what exactly do you mean by "missing"? Do you mean:
A) Create branch from trunk_at_100
B) svn merge %trunk_url% branch_wc
(maybe many times, let's say the final
time trunk's HEAD is at r200)
C) The mergeinfo on branch is *not* '/trunk:101-200'?
Or do you mean something else entirely?
> You are saying missing, but not saying if you had done merge of the
> trunk (without revision ranges) to the branch. If you let svn merge
> what it wants there should not be missing ranges.
>
>> -We recently moved to 1.6.2, although I wouldn't be surprised if some
>> developers upgraded before the organization officially upgraded. Prior
>> to that wethe server and I assume most of our users were on 1.5.5
>
> and is this a 1.6 problem?
>
>> -I am fairly certain that some people have been merging to trunk without
>> -reintegrate and I wouldn't be surprised if there some folks did some
>> cherrypicking merges back to trunk as well.
>
> sounds like you need a bit more cm policy enforcement :-)
>
>> -Also attached are two more files - trunk.mergeinfo and
>> trunk.mergeinfo.recursive which show the output of
>>
>> svn pg svn:mergeinfo $SVN_TRUNK
>> and
>> svn pg svn:mergeinfo --recursive $SVN_TRUNK
>>
>> The output is quite different between the two. The same commands run on
>> the http://svn.collab.net/repos/svn repository yield identical results.
The output is always different if a path has subtree mergeinfo. The
first is asking "give my the me the explicit mergeinfo on trunk", it
gives:
$ svn pg svn:mergeinfo $SVN_TRUNK
/branches/4.1.00_Dev:3-4948
/branches/4.2.00_Temp:5009-6210
/branches/user_branches/VpadReco:782-3787
/branches/user_branches/criggs_audio_db:6259-6958
/branches/user_branches/cwall_4.2_vmc_mock:5028-6952
/branches/user_branches/sdk-refactoring:2843-2861
The second command asks "give me the explicit mergeinfo on trunk and
on any subtree of trunk". Embedded within that output we see the same
mergeinfo for trunk:
http://svn/sc/SVP/trunk - /branches/4.1.00_Dev:3-4948
/branches/4.2.00_Temp:5009-6210
/branches/user_branches/VpadReco:782-3787
/branches/user_branches/criggs_audio_db:6259-6958
/branches/user_branches/cwall_4.2_vmc_mock:5028-6952
/branches/user_branches/sdk-refactoring:2843-2861
Does that make sense?
Also, you might want to take advantage of the new -v option to propget
in 1.6. It formats the output in a way that is much easier on the
eyes.
> Your merge info looks like you are merging the wrong path. If you have
> the right path, the output should be very small/compact, or at least svn
> st should seem less.
>
> You have a lot of subtree mergeinfo, probably from 1.5.x < 1.5.4
> clients. This is almost certainly a mess and you should probably get
> rid of mergeinfo at all points other than module roots.
Subtree mergeinfo in and of itself shouldn't cause problems for
reintegrate, unless it was created from subtree merges (i.e. someone
merged -rM:N from trunk/some/child to branch/some/child, but rM:N was
never merged to the rest of branch.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2359085
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-03 16:14:26 CEST