CODEWITHSUNDEEP
svnbranching-and-merging
Jason S
Jason S

Reputation: 189626

svn: merging between branches other than trunk

We have a SVN project with branch B that I work on, and branch C, that a coworker works on. (he works primarily on one area of code and I work primarily on another)

How are he and I supposed to merge, if we wish to stay in sync prior to doing any merges to the trunk?

We don't have any problems merging content, but the content (particularly svn:mergeinfo, for obvious reasons) keeps displaying tree conflicts and always gives us trouble.

What should we do?

Upvotes: 4

Views: 1898

Answers (1)

Zephan Schroeder
Zephan Schroeder

Reputation: 695

If you can both work in the same branch then consider doing a baseless merge of all changes to one branch and abandon the other branch. If you have other changes in your branch that must remain separate then CAREFULLY consider cherry-picking just the changes that should be baseless merged to single branch, then revert those changes in the source branch.

Structure (for reference):

  • Trunk
    • Branch A
    • Branch B

Process would be something like the following:

  1. FI (Forward Integrate) Trunk to both children. (Merge Trunk to Branch A, then Trunk to Branch B).
  2. Baseless merge from B to A.
  3. Abandon B (at very least lock to prevent accidentally using retired branch).
  4. FI Trunk to A again (re-establishing merge relationship and ironing out any merge conflicts before further changes are introduced.
  5. Both you and other developer continue developing in branch A until stable.
  6. FI Trunk to A (pick up latest changes from other developers or other trunk activity)
  7. Quickly build and run smoke tests in A (confirm FI successful and A is still stable)
    1. If More changes to trunk occur during smoke test then repeat 6 & 7 or possibly lock trunk until steps 6 - 8 can be completed.
  8. RI (Reverse Integrate) A to Trunk

IDEA: If possible avoid having to share unstabilized changes between child branches in the future. Baseless merges and cherry-picking changes are both higher risk operations than standard full parent-child merges. One apprach is to use a common Development branch, then branch by feature only when needed. All developers use the common dev branch for changes. When breaking change needs multiple developers to build&stabilize create the feature branch. Once stabilized integrate back to Dev branch and retire the feature branch.

Upvotes: 2

Related Questions