Ah, perhaps you were asking whether someone from another branch could --reintegrate between 5 and 6. Well, yes, but that's not a problem.
Suppose I 'drop' the branch as follows.
cd ~someone/trunk/wc
svn update
svn merge --reintegrate ^/branches/somebranch .
svn commit
Creating revision 123. This revision 123 is the 'poison' revision that will cause all sorts of trouble if we tried to merge from trunk into branch again.
Anyhow, I can sync (at pretty much any time between the drop and the next time I want to pull trunk changes up into somebranch) with:
cd ~someone/somebranch/wc
svn update
svn merge -c 123 --record-only ^/trunk
svn commit
Note, I am specifically merging only the poison revision in order to prevent problems in future. There is nothing in revision 123 that will impact the branch (it was, after all dropped from branch in the first place). Even if someone from another branch had, in the meantime, dropped revision 124 this would in no way be a problem.
Next time I merge trunk into somebranch I will see 124 as a new trunk change (no different to seeing any other trunk change) and revision 123 will be seen as 'already merged' because of my --record-only merge earlier, hence it will not cause trouble.
Even if someone adds to the somebranch before I do the bookkeeping --record-only merge it does not matter. Just so long as the bookkeeping is done before the next merge from trunk.
If you're disorganised and allow a change on trunk between the last integration into the branch and the 'drop' then you may have an issue, but that issue will simply be remerging work, Subversion will keep track of it just fine.
Suppose trunk was at 120 when you integrated up to somebranch (bringing somebranch up to date with the head of trunk). Then someone updated the trunk, adding 122. Then you 'drop' somebranch to create 123 on trunk (it would be better to pull 122 into somebranch, rebuild, retest and then drop---but let's suppose you need to mess trunk about for some reason). There may be some merge work in trunk between 122 and 123 changes. If you then merge --record-only 123 up to somebranch the next time you integrate trunk up to branch you will need to 'remerge' revision 122. The best way to avoid this is to stop working on trunk. Use trunk as a 'release' branch and use 'support' branches for defect resolution etc. That way you keep control over your integration patterns and can avoid this sort of complexity.
Maintaining trunk in this way also makes the 'drop' simpler because you can 'merge --reintegrate' and 'resolve --accept theirs-full' (not that this should be necessary if you're merging is organised properly). Assuming you make sure the source branch is always up-to-date with respect to branch before dropping (and why would you not? If you are merging during a release you are releasing untested code, which is pretty risky stuff---unless your system is properly segmented into sub-systems/modules in which case you are releasing these CI, and the providing the merging effort is isolated to one CI you should have no issues, but this is getting too complex for a forum post and somewhat off topic, so I'll stop now).
No comments:
Post a Comment