RE: --reintegrate merge problems

I thought I'd post some good news for a change. After deleting all the mergeinfo from trunk I was able to create and immediately --reintegrate merge a branch as I would expect. I did have to update trunk after creating the branch because I got the " Cannot reintegrate into mixed-revision working copy" error even though I was at the latest rev, but I don't really see that as a problem and I'm sure someone has a perfectly reasonable explanation for why that is. I'm going to continue investigating. Below is a copy of what I did.

D:\SVP\trunk>svn cp http://svn-backup/sc/SVP/trunk http://svn-backup/sc/SVP/branches/user_branches/test_3 -m"new branch after deleting all merge info"

Committed revision 7098.

D:\SVP\trunk>svn merge --reintegrate http://svn-backup/sc/SVP/branches/user_branches/test_3 .
svn: Cannot reintegrate into mixed-revision working copy; try updating first

D:\SVP\trunk>svn up
At revision 7098.

D:\SVP\trunk>svn merge --reintegrate http://svn-backup/sc/SVP/branches/user_branches/test_3 .

D:\SVP\trunk>svn st
 M .

D:\SVP\trunk>svn diff .

Property changes on: .
___________________________________________________________________
Added: svn:mergeinfo
   Merged /branches/user_branches/test_3:r7098

D:\SVP\trunk> ___________________________________________________________________
Added: svn:mergeinfo
   Merged /branches/user_branches/test_3:r7098

D:\SVP\trunk>

-----Original Message-----
From: Brian Rieck
Sent: Thursday, June 04, 2009 11:15 AM
To: 'Paul Burba'; 'Greg Troxel'
Cc: 'users_at_subversion.tigris.org'; 'tnelson_at_onresolve.com'; 'Geoff.Rowell_at_varolii.com'
Subject: RE: --reintegrate merge problems

Hello,

Trent suggested in a reply to my post on the dev list that he thought that the problem could be caused by self-referential mergeinfo on trunk:

Quoting Trent:

*********
This sounds very similar, if not identical, to a problem I’ve run into recently:
- Trunk gets self-referential mergeinfo added to it, i.e. /src/trunk:2-115.
- A branch is created from trunk_at_HEAD (let’s say HEAD = 389).
- The branch inherits trunk’s self-referential svn:mergeinfo in the copy.
- This breaks the wazoo out of any subsequent merges to or from trunk; branch was created from trunk_at_389, but Subversion relies on the svn:mergeinfo when it’s present, rather than consulting the natural history, which results in it trying to apply 116-389 to the branch during the merge.

I can see some self-referential svn:mergeinfo against trunk in your attachments. In my situation, any branch that was created when that mergeinfo was present is completely hosed.

                Trent.

********************

I have restored Tuesday night's backup to a test server and recreated the problem. Then my plan was to remove the self-referential mergeinfo using a script that Geoff Rowell suggested. The script worked great - thanks Geoff!

So after removing references to trunk in trunk's mergeinfo I:

- committing the prop changes from removing the mergeinfo references to trunk
- created a new branch off of trunk
- tried to do a --reintegrate merge and I got ---> "svn: Cannot reintegrate into mixed-revision working copy; try updating first". I'm not sure how I could be out of date as I'm the only person with access to the backup server and I just committed all the changes.
- svn up --> Nothing is updated
- tried to do a --reintegrate merge again and the "mixed-revision" error goes away but svn wants to actually merge a bunch of stuff - adds, removes, conflicts - I think the list is different as I only recall conflicts before and now there are adds and removes- I will verifying this.

So unfortunately there is something else or something more happening than just the self-referential merge info on trunk. I find it odd that I would get the "mixed-revision" error even though nothing could have changed on trunk, then doing a no-op svn update makes the error go away. Maybe that is unrelated to the problem at hand but I wouldn't describe my confidence in the health of the repository as high.

As always - thanks for the help so far everyone.

What I'm planning on doing now:

1) Just for the heck of it I'm going to try removing all merge info from trunk on the backup server to see what happens.

2) I'm going to re-restore the repo from backup and verify that the behavior is different before and after removing the self-referential mergeinfo from trunk.

Thanks,
Brian

-----Original Message-----
From: Brian Rieck
Sent: Wednesday, June 03, 2009 9:36 AM
To: Brian Rieck; 'Paul Burba'; 'Greg Troxel'
Cc: 'users_at_subversion.tigris.org'
Subject: RE: --reintegrate merge problems

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=2359503

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-04 19:56:47 CEST