...
- The satellite developer will be continually growing the branch, by saving milestone changes in their work using commit commands.
- As the branch grows, satellite developers will generally want to incorporate changes occurring along the trunk in order to minimize differences between the codesets. This would be done by applying merge operations along the way, comparing head revisions in both the branch and trunk and applying them to a branch working directory. These merge operations should run a comparison "from" a previous revision on the trunk (i.e. the revision at branch formation or at last merge operation) "to" the head revision on the trunk. The changes should then be applied to a branch working copy. A good note should be kept regarding the revision number range of the merge, so that future merges run from the new starting point along the trunk.
- During branch development, the satellite developer may notice some changes that would be of immediate value to the trunk codeset, i.e. they may fix a bug that impacts trunk functionality independent of the branch. The subset of files/changes would be ascertained using a merge command, and applying them to a working copy of the trunk. These modifications would be rolled into a patch file created by Subversion. This file would be sent to the core development team for review, likely using the TortoiseMerge utility to ascertain the changes made to individual files. Any changes approved by the core development team would be applied to a trunk working copy and uploaded via commit commands.
- At various milestones along branch development, its features may be rolled into the main codebase using the merge functionality, comparing head revisions along the branch and trunk, likely with close collaboration between the satellite developer(s) and the core development team, in order to resolve any conflicts that may need to be resolved. In some cases, this may be accomplished via the patch file mechanism described above.
- In general, the merge operations for both immediate patches and branch milestones should involve comparisons of revisions along the branch history, as opposed to comparisons between the head revisions of the branch and trunk, following this advice. This may merit further discussion. For this reason, the merge history should be well-recorded in the log comments in order to identify revisions along the branch at which they occurred. Subversion does not presently track merge history (this is considered one of its leading shortcomings).
- The final version along the branch would be incorporated into the trunk via a merge procedure, most likely in close collaboration with the core development team as above. The directory in the branches subdirectory may then be moved to an archive folder, so it no longer appears as an active project.
...