Sorry I missed replying to a couple points at the bottom in the last reply.
-----Original Message-----
From: Brian Rieck
Sent: Wednesday, June 03, 2009 9:31 AM
To: 'Paul Burba'; Greg Troxel
Cc: users_at_subversion.tigris.org
Subject: RE: --reintegrate merge problems
-----Original Message-----
From: Paul Burba [mailto:ptburba_at_gmail.com]
Sent: Wednesday, June 03, 2009 8:13 AM
To: Greg Troxel
Cc: Brian Rieck; users_at_subversion.tigris.org
Subject: Re: --reintegrate merge problems
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).
>
I agree that this is odd/wrong. Since about 3 seconds passed between the copy and the attempted merge I did skip merging from trunk to the branch before trying the --reintegrate merge. I expected a nothing to happen when I did the merge as the branch and trunk are identical. The reason I tried it at all is because I had a user create a branch, do a small task, merge to his branch from trunk and then try to do a --reintegrate merge back to trunk. He saw tons of conflicts and came to ask me about it. I tried the simplest branch creation and --reintegrate merge scenario I could think of and saw the same problem he did.
>> 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?
We have seen these sorts of errors after merging to the branch and commiting the changes from the merge to the branch:
***************
$ svn merge --reintegrate http://svn/sc/SVP/branches/user_branches/rbeach_ulaw .
svn: Reintegrate can only be used if revisions 5595 through 6487 were previously merged from http://svn/sc/SVP/trunk to the reintegrate source, but this is not the case:
branches/user_branches/rbeach_ulaw/external_lib/jboss/portal/2.7.1/server/reco
Missing ranges: /trunk/external_lib/jboss/portal/2.7.1/server/reco:5595-6477
branches/user_branches/rbeach_ulaw/local_build
Missing ranges: /trunk/local_build:5595-6477
branches/user_branches/rbeach_ulaw/local_build/dirlist.bat
Missing ranges: /trunk/local_build/dirlist.bat:6394-6477
branches/user_branches/rbeach_ulaw/local_build/master_build.bat
Missing ranges: /trunk/local_build/master_build.bat:6394-6477
branches/user_branches/rbeach_ulaw/local_build/poptree.bat
Missing ranges: /trunk/local_build/poptree.bat:6394-6477
branches/user_branches/rbeach_ulaw/local_build/solaris_master_build.csh
Missing ranges: /trunk/local_build/solaris_master_build.csh:6394-6477
branches/user_branches/rbeach_ulaw/platform
Missing ranges: /trunk/platform:5595-6477
********************
> 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 did do the merge from trunk to branch and I agree that 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'm not sure if it is a 1.6 problem. We definitely seen the missing ranges error with both 1.5 and 1.6 although I believe that the time I saw it with 1.6 that the branch was created with 1.5 if that matters. The problem with all the conflicts has only been seen with 1.6 but I can't say with certainty that it is or is not 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 :-)
Unfortunately they took away my cattle prod. Seriously though is this a possible cause of mergeinfo getting screwed up? The way I read the svn book is that you shouldn't do this but I have some developers that I think are doing it anyway because they think it should be okay regardless of what I say.
>
>> -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?
Yes that makes sense and after I sent it I started thinking that the svn repo is probably identical because you guys delete your branches after you merge back to trunk. Again I need the cattle prod.
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.
I'll check that out.
> 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.
I would love to clean up any extraneous mergeinfo. I'll start with killing any dead branches. Any other guidance would be very much appreciated as I'm a bit nervous about making things worse.
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.
If I'm reading this right it is bad to cherry pick some changes from trunk to a branch unless you eventually merge all of trunk to the branch? I actually thought this was okay.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2359115
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-03 17:41:30 CEST