display | more...

A source code version control concept where code is "split" into many different versions which allows changes to be made without affecting the main branch of code.

Imagine, for a moment, that you are the project leader of a software development team. You have a product, "foo" version 1.0, that has just been released to a happy and receptive public. (yeah, right! :-) However, the increased exposure of your product to a larger user base has shown it has several bugs and customers have also submitted several enhancement requests. Senior management has told you to:

  • Fix the bugs in version 1.0 and release a bug fix service pack.
  • Add the features requested by your customers and release a new version of foo.

A good version control system will help you accomplish this by splitting the code into two branches:

  1. Before branching. Here there is only one version of the software. When a developer wishes to work on the project, he/she only has one choice of what version of software to change.
    (released version of software)
    +-----+
    ! 1.0 !
    +-----+
    
  2. After branching. Here the developer can check out the project from either the 1.1 branch or the 1.8 "main trunk." If they are working on bug fixes they will use the 1.1 branch as a basis for their work, if they are adding features they will use the 1.8 branch. Version 1.8 is the result of many code changes as features are added to the product (hence producing 1.2, 1.3 etc etc as changes are made)
    +-----+  some versions  +-----+
    ! 1.0 !-- omitted for --! 1.8 ! (pre version 2.0
    +-----+     clarity     +-----+    work)
       !
       !   +-----+
       +---! 1.1 ! (bug fixes)
           +-----+
    
  3. Of course, it is desirable that version 2.0 of the product will incorporate the bug fixes from the version 1.1 work. This is accomplished by merging the 1.1 branch back into the main trunk. (merging is beyond the scope of this node, and is only simply illustrated here) The project leader or build manager will usually accomplish this task, consulting with the engineers who are responsible for the project. Here, the changes from version 1.1 have been merged back into the main trunk. The changes have combined with version 1.8 to form a new version, 1.9. This new version will incorporate both the changes from 1.1 and the feature requests that have been added to form 1.8
    +-----+    +-----+    +-----+
    ! 1.0 !----! 1.8 !----! 1.9 ! (new version)
    +-----+    +-----+  / +-----+
       !               /
       !   +-----+    / (merge)
       +---! 1.1 !---+
           +-----+
         (bug fixes)
    
    

Of course, this is greatly simplified, to fit well into a node.


ASCII art adapted from the CVS manual at http://www.cvshome.org/