[svnbook commit] r2910 - trunk/src/en/book
blair at orcaware.com
Fri Dec 14 02:09:08 CST 2007
> Author: sussman
> Date: Mon Dec 10 16:32:10 2007
> New Revision: 2910
> Keep filling out chapter 4.
> * src/en/book/ch04-branching-and-merging.xml: more work on TODO sections.
> <para>Congratulations, your branch has now been re-merged back
> - into the main line of development. You'll no longer need your
> - branch at this point anymore, so you can do some basic
> - housecleaning in the repository:</para>
> + into the main line of development. Notice our use of
> + the <option>--reintegrate</option> option this time around.
> + The option is needed because this sort of <quote>merge
> + back</quote> is a different sort of work than what you've been
> + doing up until now. Previously, we had been
> + asking <command>svn merge</command> to grab the <quote>next
> + set</quote> of changes one branch and duplicate them to
> + another branch. This is fairly straightforward, and each time
> + Subversion knows how to pick up where it left off. In our
> + prior examples, you can see that first it merges the ranges
> + 345:356 from trunk to branch; later on, it continues by
> + merging the next contiguously available range, 357:380. When
> + doing the final sync, it merges the range 381:385>.</para>
Are those inclusive or exclusive? Should that be 356:380 and 380:385 instead?
> + <para>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 <option>--integrate</option> option, you're asking
You mean --reintegrate?
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair at orcaware.com>
Subversion training, consulting and support
More information about the svnbook-dev