> > 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. The same way you would have done it in 1.4. 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. > 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? Well... if you do a reintegration merge svn checks to ensure that everything from the branch you are re-integrating to has been merged into the branch. If it detects missing revisions it will abort with an error about missing revisions. So svn enforce your "process". > > > Given a very simple repo with three revisions like that: > > > > > > /trunk/file (r2) > > > /branch/bla/file (r4, mergeinfo in r3: Merged /trunk/@1-2) > > > > > > If I ran "svn merge /branch/bla" it's possible to detect that > r3 is the > > > result of a merge, so only r4 needs reintegration into trunk. > > > > Actually, I think if you ran that at the moment, r3 would still > try to > > be merged back into trunk (and conflicts would result). I could > be > > wrong. > > I gather it would be rather difficult for Subversion to figure out > which > revision in the branch contains which changes from trunk (it would > need > to figure out which revision added the appropiate revisions to the > mergeinfo property). It does do that.. see above. It checks the mergeinfo on the branch to ensure that it includes all the revisions made to trunk since the branch was created. You should really run some of these use cases through a test repo. That is the best way to understand what is going on and how it works. Hth, BOb
