[CAF] Branching strategies with Perforce

G. Matthew Rice matt at starnix.com
Fri Feb 10 09:51:24 EST 2006

Olaf Alders <olaf at vilerichard.com> writes:
> regular happening.  ;)  I'm assuming  that when 0.27 gets integrated into
> main that I'll be able to p4 sync  to get the latest version?

Guys, I figure that now is a good time to introduce everyone with the
branching patterns that we're using with CAF.  There are three (well four;
when will I learn to not enumerate a list before it's done :) main types of

Main:  //depot/caf/main/...

    This branch serves the purpose of holding the latest'n'greatest "working"
    code.  I quote working because minor/short term development can occur on
    it providing that the coder doesn't expect to break anything or the code
    will have time to be proven well before an expected release.

Dev:  //depot/caf/dev/<xyz>/...

    These branches are for longer lived projects where the changes will
    introduce stability issues during development.  Sub <xyz> for a short
    descriptive word for the project.  For example, there are currently two
    dev branches:

        matt at brando:~/p4/lpi$ p4 dirs //depot/caf/dev/\*

    These are also meant for group efforts.  There's also (this is the fourth
    type) //depot/scratch/<username>/... directories for people that want to
    go off on their own to work on something or for playing around.

    It is possible to use sparse branching for these development branches but
    I don't think it's necessary since the project is small and branches
    don't incur much overhead.

    The ideal way to use these branches is for the developer to pull any new
    changes in from the main codeline, make sure everything works in the
    development branch and then merge the new code into the main codeline.

Release:  //depot/caf/rel/<version>/...

    These are branches the track the real releases.  Right now, we're just
    doing snapshot branches for each release but they can be used to do patch
    releases without having to worry about unwanted changes from the main
    branch.  To see which releases are available:

        matt at brando:~/p4/lpi$ p4 dirs //depot/caf/rel/\*

    The ideal way to use these branches is to only do bugfixes on the release
    codeline (it's usually easier to reproduce/fix a bug against the release
    that it is discovered) and to then merge them into the main codeline and
    from there to active development branches and, possible, any other
    supported releases.  The nice thing about OSS projects, though, is that
    we'd probably just cut a new release and say, "upgrade or not" and avoid
    the hassle up maintaining multiple concurrently supported versions.

Diagrammatically speaking, the branches look something like this (with flow):

                    ______ //depot/caf/rel/0.25/...
                   /     @
                  /       @ -- bug fixes move back to main codeline
                 /         @
---------------------------------------------> //depot/caf/main/...
  \    \                            \      @
   \    \ - periodic updates   final \    @ - more new features into
    \    \  from main          update \  @    main codeline
     \____\____________________________\@ //depot/caf/dev/i18n/...

I hope you guys have fixed width fonts for this :)

Also, the nice thing about Perforce's "branches look like other directories"
approach means that you can have multiple branches in your workspace (no need
for one per branch) and work on code in the appropriate branch without much
monkeying around (you may have to update your workspace 'View' and 'p4 sync').

g. matthew rice <matt at starnix.com>           starnix, toronto, ontario, ca
phone: 647.722.5301 x242                                  gpg id: EF9AAD20
http://www.starnix.com              professional linux services & products

More information about the caf mailing list