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 pr开发者_如何转开发oblems merging content, but the content (particularly svn:mergeinfo, for obvious reasons) keeps displaying tree conflicts and always gives us trouble.

What should we do?

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.