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

Why is --reintegrate needed for svn 1.5 merging?

From: Henrik Sundberg <storangen_at_gmail.com>
Date: Fri, 30 May 2008 16:42:58 +0200

From: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html
===
The [--reintegrate] option is critical for reintegrating changes from
a branch back into its original line of development—don't forget it!
It's needed because this sort of "merge back" is a different sort of
work than what you've been doing up until now.
...
When merging your branch back to the trunk, however, the underlying
mathematics is quite different. Your feature branch is now a mish-mosh
of both duplicated trunk changes and private branch changes, so
there's no simple contiguous range of revisions to copy over. By
specifying the --reintegrate option, you're asking Subversion to
carefully replicate only those changes unique to your branch.
===

It seems likely that I will miss --reintegrate now and then. And it
makes the instructions more complicated.
Is it really needed?
What happens if I use --reintegrate when updating my branch (i.e. when
it isn't needed)?

Is the absence of --reintegrate just an optimization? Shouldn't the
opposite be an option instead, in this case?

Why is there a difference depending on the merge direction?
What happens if I want to merge two branches (made from the same trunk
at different times)? How do I know for which direction --reintegrate
should be used?

/$

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-30 16:43:24 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.