[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: --reintegrate merge problems

From: Greg Troxel <gdt_at_ir.bbn.com>
Date: Tue, 02 Jun 2009 21:47:38 -0400

Brian Rieck <BRieck_at_sandcherry.com> writes:

> First I hope that it is okay to send attachments to the listsrv and that
> dev is the right list for this.

I think users is right; you aren't proposing patches.

> 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.

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

> 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.

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.

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.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

  • application/pgp-signature attachment: stored
Received on 2009-06-03 04:15:00 CEST

This is an archived mail posted to the Subversion Users mailing list.