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

Re: reintegrate in 1.8.1

From: Jacob Weber <jacob_at_jacobweber.com>
Date: Tue, 27 Aug 2013 14:35:23 -0700

On Aug 27, 2013, at 1:39 PM, Mark Phippard <markphip_at_gmail.com> wrote:

> On Tue, Aug 27, 2013 at 4:34 PM, Jacob Weber <jacob_at_jacobweber.com> wrote:
> The next time I merge from trunk into my branch, how will SVN know not to merge X?
> Magic :)
> Internally, the code still does reintegrate. It just figures out when it needs to do it. It turns out you could have always avoided doing --record-only, but only if you "knew" to use --reintegrate on that first merge from trunk back to the branch. SVN figures this out and is doing it for you.
> If you are merging between branchA and branchB, if the last merge between those two branches went in the "same direction" it does a sync merge, if it went in the "opposite direction" it does a reintegrate merge.

Nice. Doing --record-only won't hurt though, will it? I'm concerned that some people might be accessing my repository with a 1.7 client, so this magic wouldn't work for them.

I was under the impression that reintegrate just did a two-way diff of the two branches, and applied the differences to the destination branch (from the 1.7 manual: "By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!)")

But I'm guessing from what you said that it's more complex than this. Otherwise, if you had changes in the trunk that hadn't been merged into a branch, you would lose them when you reintegrated from the branch back into the trunk.

Received on 2013-08-27 23:35:59 CEST

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.