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

Re: svn merge --reintegrate trouble again

From: Reid Priedhorsky <reid_at_umn.edu>
Date: Thu, 05 Mar 2009 13:17:59 -0600

On 03/05/2009 09:48 AM, Mark Phippard wrote:
> On Wed, Mar 4, 2009 at 2:17 PM, Reid Priedhorsky <reid_at_umn.edu> wrote:
>
>> Thanks for your help earlier. I ran into trouble again with svn merge
>> --reintegrate, under 1.5.5 on Ubuntu Linux. Hopefully this additional
>> detail will help.
>>
>> Summary: svn merge --reintegrate generates a lot of conflicts, but plain
>> svn merge generates none.
>> $ svn merge --accept postpone $svnroot/br/masli_ib-misc_820
>> --- Merging r9696 through r9738 into '.':
>> U flashclient/Conf.as
>> U flashclient/tools/Node_Build.as
>> U flashclient/commands/Vertex_Add.as
>> U flashclient/commands/Node_Build.as
>> U flashclient/G.as
>
> This is not a comparison to what --reintegrate does. BTW, if you have
> not done any merges into the branch this is a perfectly acceptable way
> to merge the branch back to trunk.
>
> It sounds as if somehow the branch history is not right, or being
> retrieved right. Was the branch created with svn copy?

I think so. I didn't create it, but our internal docs say to use the
command "svn copy $svnroot/trunk $svnroot/br/<BRANCH>".

> From what revision of trunk?

Looks like r9688. (That's the greatest revision of the trunk less than
9696, which is the revision created by svn copy.)

> Was it possibly created from a mixed-revision WC of trunk?

I think it's unlikely. We don't deliberately create mixed-revision WC's.
How could I check this?

The $svnroot on the machine where the branch was created could be a
different way to get at the same repository (different svn+ssh: target
or file: method).

> Let's assume the branch was created by copying trunk at rN. Then the
> merge command to simulate reintegrate would be:
>
> $ svn merge $svnroot/trunk_at_N $svnroot/br/masli_ib-misc_820_at_HEAD
>
> All that --reintegrate does is calculate what "N" should be and then
> run the above command. Everything else it does is just validations
> before running the merge to determine if maybe this is not what you
> want to do.

Is it true that the plain svn merge above is equivalent to (HEAD was
r9737 at the time of the merge):

$ svn merge $svnroot/br/masli_ib-misc_820_at_9696
$svnroot/br/masli_ib-misc_at_9737

and the svn --reintegrate was equivalent to

$ svn merge $svnroot/trunk_at_9688 $svnroot/br/masli_ib-misc_820_at_9737

However,

$ svn diff $svnroot/trunk_at_9688 $svnroot/br/masli_ib-misc_820_at_9696

is empty, and

$ svn diff $svnroot/br/masli_ib-misc_820_at_9696
$svnroot/br/masli_ib-misc_820_at_9737

and

$ svn diff $svnroot/trunk_at_9688 $svnroot/br/masli_ib-misc_820_at_9737

produce identical diffs (except for the notations about paths and
revisions).

So it seems that in this case, svn merge and svn merge --reintegrate
should be equivalent. What am I missing?

Is there some way to get a debug trace from svn merge? It does not
accept the --verbose command.

Much appreciated,

Reid

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1273296

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-06 06:32:27 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.