On Wed, Sep 29, 2010 at 10:07:01AM +0200, Tino Schwarze wrote:
> On Thu, Sep 23, 2010 at 10:37:30AM -0400, Bob Archer wrote:
>
> > > > The critical paragraph is this one:
> > > >
> > > > "When merging your branch back to the trunk, however, the underlying
> > > > mathematics is quite different. Your feature branch is now a mishmosh
> > > > 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. (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!)"
> > >
> > > The last sentence doesn't make sense to me. It would require me to
> > > merge all changes from trunk into the feature branch before
> > > reintegration?
> >
> > That is exactly correct. Since that is the expected case for a feature
> > branch. That you are adding a feature to trunk so you want to be sure
> > anything modified in trunk is brought into your branch to ensure the
> > feature still works with any trunk changes.
>
> > There is really no magic in a reintegrate. It is simply a tree merge
> > which compares HEAD of trunk to HEAD of branch.
I'd like to note that the above statement is inaccurate.
The text quoted from the book is, unfortunately, also inaccurate.
The reintegrate merge does not always use the HEAD of trunk.
Consider this scenario (proportional font recommended for best results):
/branches/feature +---------rX
/
/trunk r1-----------rA-----------------------HEAD
rA marks the revision in which the feature branch was created.
rX marks the revision at which 'feature' was last synced to trunk.
The branch is considered ready for reintegration.
What reintegrate does is that it compares trunk_at_rX to branches/feature_at_HEAD,
and merges the resulting diff into the working copy of trunk_at_HEAD.
I.e. diff being merged is
svn diff ^/trunk_at_rX ^/branches/feature_at_HEAD
so the reintegrate merge is semantically equivalent to this 2-URL merge:
svn merge ^/trunk_at_rX ^/branches/feature
If trunk_at_HEAD was used, the merge would end up undoing changes committed to
trunk between rX and HEAD, because those changes aren't in the feature
branch yet so they'll appear in reverse in the diff being merged.
Of course, it's possible that rX equals HEAD, but usually it doesn't.
> > The same way you would have done it in 1.4.
Yes. In 1.4, the user had to figure out the value of rX manually.
In 1.5 and later, merge-tracking determines rX automatically.
> > However, it has all these extra checks to ensure
> > that you actually have merged all revs of the target path into the
> > merge-from path.
There are several checks for different purposes.
The check you're describing makes sure that the entire range of revisions
merged from trunk to the branch is contiguous. So if, say, your feature
branch was created in revision rA and you're now at rX, reintegrate requires
that the entire range rA-rX has been merged from trunk into the feature branch.
If that is not the case, you get this error:
svn: Reintegrate can only be used if revisions 2 through 6 were \
previously merged from https://svn.example.com/trunk to the \
reintegrate source, but this is not the case:
branches/feature
Missing ranges: /trunk:4
This check prevents the reintegrate merge from undoing changes made
on trunk between rA and rX.
Other checks include ensuring that the target working copy is at a uniform
revision (with a mixed-rev working copy, conflict resolution is
a nightmare), that there are no switched subtrees in the target working
copy (to prevent reintegrating one part of the feature branch into trunk
and another part into some other branch which some subtree of the
working copy was switched to), and that the working copy has no local
changes (to ease conflict resolution and make sure the committed changeset
is really only about the reintegrate merge).
Actually, virtually any kind of merge would benefit from these working copy
checks, but they're only performed for reintegrate merges right now (I don't
know why).
> > > Otherwise, my feature branch would undo everything not merged from
> > > trunk (because of that latest tree comparison)?
> > >
> > > I've read the section about merging again and the above seems to be
> > > true.
> > >
> > > Therefore, we'd need to ensure (by organizational process) that
> > > nobody checks in anything into the trunk while the feature branch is
> > > being tested for reintegration or these additional changes will get
> > > lost?
People can commit to trunk at any time. If commits made to trunk
after rX conflict with changes on the feature branch, you'll get
conflicts during the reintegration merge. You can either solve conflicts
during the reintegration merge, or abort reintegration, sync the feature
branch with trunk to fix the conflict there, and reintegrate again.
Stefan
Received on 2010-09-29 22:10:07 CEST