…Another way of thinking about this pattern is that your weekly sync of trunk to branch is analogous to running svn update in a working copy, while the final merge step is analogous to running svn commit from a working copy
I find this approach very unpractical in large developments, for several reasons, mostly related to reintegration step.
- From SVN v1.5, merging is done rev-by-rev. Cherry-picking the areas to be merged would cause us to resolve the trunk-branch conflicts twice (one when merging trunk revisions to the FB, and once more when merging back).
- Repository size: trunk changes might be significant for a large code base, and copying the differences files (unlike SVN copy) from trunk elsewhere may be a significant overhead.
Instead, we do what we call “re-branching”. In this case, when a significant chunk of trunk changes is needed, a new feature branch is opened from current trunk, and the merge is always downward (Feature branches -> trunk -> stable branches). This does not go along SVN book guidelines and developers see it as extra pain.
How do you handle this situation?
After research:
After many brainstorming sessions at visionmap, F2F discussions including Artyom, opening an SVN book case, etc – it looks like this is not possible to do. A feature branch is totally not like working copy. The only working way to update it is recreate a new branch, as described above.