I'll try my hand at writing something for the manual. Just want to make
sure I fully understand this.
So, the problem was never with running --reintegrate multiple times, it
was doing a merge back into the branch from trunk? Branch would see r100
(for example) as needing to be merged back into the branch which already
contained all/a lot of those diffs?
> -----Original Message-----
> From: Mark Phippard [mailto:markphip_at_gmail.com]
> Sent: Friday, February 20, 2009 4:01 PM
> To: Bob Archer
> Cc: Brian Erickson; users_at_subversion.tigris.org
> Subject: Re: Fwd: svn1.5 seems to fail simple merge-tracking scenario
> On Fri, Feb 20, 2009 at 3:54 PM, Bob Archer <Bob.Archer_at_amsi.com>
> >> > 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
> > 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
> > 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
> > 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
> > 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
> Mark Phippard
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-20 22:07:38 CET