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

Re: Fwd: svn1.5 seems to fail simple merge-tracking scenario

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 20 Feb 2009 16:00:40 -0500

On Fri, Feb 20, 2009 at 3:54 PM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>> > Back on branch1
>> > $ svn merge --record-only -r100 ^/trunk
>> > $ svn ci -m "Mark r100 as merged"
>> >
>> > $ svn ci -m "More work on branch"
>> > $ svn merge ^/trunk
>> > $ svn ci -m "Catch back up with trunk"
>> >
>> > Back on trunk
>> >
>> > $ svn merge --reintegrate ^/branch1
>> > $ svn ci -m "Commit all work from branch1"
>> > Committed revision 200
>> >
>> > Lather. rinse. repeat.
>
> What is this doing? You are telling the branch that everything in r100
> on trunk has already been merged into trunk?

You are telling it that r100 from trunk has been merged into the
branch. Basically, you are keeping SVN from trying to merge that
revision back to the branch. The branch does not know it already has
the code from that change.

You are doing this so that you can do future "catch up" merges from
trunk without it trying to merge that revision back.

> Because if you try to merge
> into branch from trunk it will try to bring in changes committed in r100
> on trunk which was really the commit of your --reintegrate merge?
>
> This is about as obvious as... well, it's NOT obvious.
>
> Why then does the manual say to delete the branch after integration?

Because it is easier to write and understand. If someone can explain
this alternate approach in a simple paragraph I am sure they'd include
it. Submit a patch.

> Is there anything in the works to no require the manual mergeinfo to be
> created? I see why this is problematic because it would require the
> merge to create mergeinfo in two working copies on in trunk and one on
> the branch?

No, there is not any work planned on this. The blog posts explains it
pretty well. Merge tracking did not redefine what a merge in
Subversion is. There are some ideas, and a little code, for a new
merge algorithm but it remains to be seen if it will ever pan out and
it is not being actively worked on. I also suspect it'd be a lot
slower.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1200497
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-20 22:01:36 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.