reintegrate in 1.8.1

[Jacob Weber <ja...@jacobweber.com>]

According to the SVN 1.8 release notes: "Merging to-and-fro between two branches in any order is possible using the automatic reintegration merge (the "keep-alive dance" is no longer necessary)."

So say I merge from a branch into trunk (i.e. what used to be a reintegrate), creating revision X. Does this mean I no longer need to run a --record-only merge to block X from being merged back into my branch? The next time I merge from trunk into my branch, how will SVN know not to merge X?

Thanks,
Jacob

Re: reintegrate in 1.8.1

[Jacob Weber <ja...@jacobweber.com>]

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

> On Tue, Aug 27, 2013 at 4:34 PM, Jacob Weber <ja...@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.

Jacob

Re: reintegrate in 1.8.1

[Mark Phippard <ma...@gmail.com>]

On Tue, Aug 27, 2013 at 4:34 PM, Jacob Weber <ja...@jacobweber.com> wrote:

> According to the SVN 1.8 release notes: "Merging to-and-fro between two
> branches in any order is possible using the automatic reintegration merge
> (the "keep-alive dance" is no longer necessary)."
>
> So say I merge from a branch into trunk (i.e. what used to be a
> reintegrate), creating revision X. Does this mean I no longer need to run a
> --record-only merge to block X from being merged back into my branch?


Correct.  You no longer need to do this.


> 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.


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/