> 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.
I assume by this you mean trunk was merged into feature at rX?
> 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
Ah... thanks I was close. It is sort of what I meant.. ;) thanks for clarifying.
> 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
some messages are keepers, like this one!
BOb
Received on 2010-09-29 23:46:56 CEST