> 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 tr...@rx to > branches/feat...@head, > and merges the resulting diff into the working copy of tr...@head. > I.e. diff being merged is > svn diff ^/tr...@rx ^/branches/feat...@head > so the reintegrate merge is semantically equivalent to this 2-URL > merge: > svn merge ^/tr...@rx ^/branches/feature Ah... thanks I was close. It is sort of what I meant.. ;) thanks for clarifying. > If tr...@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
