Beginning Eclipse CVS – Branching Tutorial 1: Branching Strategies

Posted on by

<= Back to previous section “Setting up the Eclipse Interface for CVS”

NOTE: This section of the Eclipse CVS tutorial is based on Paul Glezen’s article on the Eclipse website: Branching with Eclipse and CVS, and is used with his permission under the terms of the EPL license. The changes I am making to his version are mainly to expand it with more step by step images and explanations, and integrate it with my own beginner tutorials in an attempt to make it more accessible to beginners and designers. Experienced developers will probably prefer to work from Paul’s version.
When working together in a team, developers often need to isolate code lines from each other to prevent conflicts. Besides the possibility of simply stepping on each other’s toes and overwriting new versions with older versions, different functions under development may conflict with each other while being tested.

To prevent this, projects can be developed in concurrent paths, with one path being devoted to the main line of development and others set aside for testing new features or bugfixes. One line can be kept stable or close to stable, with others not yet even in testing. Several common configuration strategies are used for team collaboration on software development.

 
Continue reading below break:

The field of Software Configuration Management is the discipline of designing methods for effective development team collaboration and version tracking that promote productivity and reduce risk. Branching and merging strategies are software configuration management practices that allow pieces of code to be worked on in isolation from the rest, then later, merged back into the whole. The process of merging involves some extra work and added risk because it can introduce new bugs, but the added productivity of working in the branch often outweighs the extra costs.

There are several commonly used branching strategies. The choice can be determined by the requirements of the project or the workflow preferences of the team. Branches can correspond to phases of development, specific tasks, or particular releases.

Chris Birmele of Microsoft Australia recommends validating your chosen strategy by considering what would happen in a change scenario – would you have to completely restructure your branches to compensate? Try to predict the worst case and plan for it.

A commonly used branching strategy is one that corresponds to the three phases of development activity: Development, Test and Production. For in-depth discussions of branching strategies, see Microsoft Team Foundation Server Branching Guidance: [LINK] or PDF ( license)

Code Promotion branches: Branches associated with phases of development.

BranchingChecklist.JPG.jpeg

(from [LINK])

Branching by Release: 
Aa730834.branchmerge02(en-US,VS.80).gif
(from [LINK])
 Branching by Task:
Aa730834.branchmerge04(en-US,VS.80).gif
(from [LINK])

Whichever configuration you choose it’s imperative that all team members are on board and fully understand the workflow and best practices associated with tagging, merging, etc.  Symptoms of problems with team member’s comprehension of the strategy, or of having chosen the wrong structure include avoidance of merging, deferring merges until the very end of the project and general confusion about versions. A longer list of “symptoms” can be seen here [LINK]

The branching structure used in the following tutorial is a task-based branch, where the branch is used for work on a specific tasks. These are short-term branches which are merged back into the main line of development – the Trunk – as soon as the task is completed.

branching.jpg

Resources

  • Team Foundation Server Branching Guidance
  • MSDN: Branching and Merging Primer by Chris Birmele

    • Continue to next section “Create the Workspace and Project” =>