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

Re: Re: Re: Re: Re: [Subclipse-users] Branch merge issues

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 27 May 2009 13:31:25 -0400

On Wed, May 27, 2009 at 8:34 AM, Stephen Colebourne
<scolebourne_at_joda.org> wrote:
>> Here is an example that shows the eligible revs from the Subclipse
>> trunk that can be merged to the Subclipse 1.4.x branch.
>> $ svn mergeinfo --show-revs=eligible
>> http://subclipse.tigris.org/svn/subclipse/trunk/subclipse@HEAD
>> http://subclipse.tigris.org/svn/subclipse/branches/1.4.x/subclipse@HEAD
> I ran this (from the directory of the working copy of the branch, although I doubt that matters). I > got back the correctly filtered list of revisions after the revision I indicated was merged.

The example I gave above lists the parent folder of the projects I'd
merge into. When merging multiple projects, it'd look at the parent
folder to see what was eligible to merge. It'd be worth trying that
folder in the command.

>> > I've tried it with the svn:mergeinfo only on /branch1, and on /branch1/eclipseprojecta and
>> > /branch1/eclipseprojectb. In both scenarios, a multiproject merge brings back every revision
>> > and takes a loong time.
>> When you ran the merge to set the mergeinfo, was it something like this?
>> $ svn co url://server/repos/branches/branch1
>> $ cd branch1
>> $ svn merge --record-only -r1:MAXREV ^/trunk
>> Where MAXREV is the max revision from trunk that you knew was merged
>> to the branch?  You could really only use --record-only if you
>> typically fully-synch the trunk revisions to the branch and you knew
>> it had all of the trunk changes up to some revision.
> Yes, those were basically the commands I ran (where MAXREV was the revision just after cvs
> migration). I don't understand why you say they would need to be fully syched before doing this.
> According to the svn 1.5 online manual, all this does is block these revisions from being
> considered. (ie. I'm happy to not have any svn merge features for versions before my MAXREV).

I just meant in order for merge tracking to be accurate. As long as
you are OK with it excluding previous revisions, it should be OK.

>> Finally, keep in mind that SVN automatically knows the "natural
>> history" for a branch.  So if it was created by coping trunk_at_1000, it
>> already knows that the branch contains r1-1000 from trunk.
> Does that mean that the svn:mergeinfo needs to start at rv1000 in your example?

The mergeinfo created by SVN would start after 1000. It would not
create mergeinfo for the "natural history".

> What would be useful info for you to find out what the issue is here?

Not sure.

Mark Phippard
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-05-27 19:31:47 CEST

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

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