[cvsnt] Branch and Tag Naming Conventions

Mike Wake mike.wake at thales-tts.com
Mon Dec 6 11:21:17 GMT 2004

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.


At the moment I do something like this and have done so for about a year 
with some success.

I have a sysid.h file that I manually control and edit to denote the 
state of the baseline.  The process may look like it needs some 
automation but the amount of time it takes is minimal and I haven't felt 
the need.

Whenever a new "official" release is made or I enter a Development phase 
"dev" or a prerelease/feature freeze phase "pre" I edit this file and 
commit it.  I can then look at a revision "Graph" of this file to get a 
feel for the baseline/branching history of the product.

So the sysid.h file contains something like this
#define BLAH_MAJOR      4
#define BLAH_MINOR      3
#define BLAH_REVISION   1
#define BLAH_MODE       "_dev"

Then somewhere in "main.c" I report the version of the product I am 
controlling using the cutomary -v flag.
#include "sysid.h"

void show_version(void)
    printf( Version   : %d.%2dr%d%s\n",
            BLAH_MAJOR, BLAH_MAJOR, BLAH_MAJOR, %mode );
    printf( BuildDate :  %s %s\n",
            __DATE__, __TIME__ );

Before I create a tag for release I first enter a pre-release/feature 
freeze phase where all bugs registered in Bugzilla for the upcoming 
release's target milestone are tested and independantly verified.  In 
this example the target milestone would be "v4.03r1" and the version 
reported would be "v4.03r1_pre".  People verifying the bugs include how 
they tested the bug together with the version and BuildDate.  Any issues 
found are resolved and committed and a complete rebuild is made.  A new 
build date is then available for subsequent testing.

When an Official Release is to be made I change the sysid.h file to 
produce v4.03r1. And do a full rebuild and commit the executable to the 
I also tag the source at this point using the following convention.
ie blah_2004_12_06_v4_03_r1_release

I also create a branch at this point called

I then add a new target milestone to bugzilla v4.03r2.
I change my sysid.h file on the HEAD to produce v4.04r1_dev and commit it.

When I inevitably start work on v4.03r2 to fix post_release bugs or 
introduce or backport features to customers who dont want the risk or 
hassles of taking the latest version I update to the 
blah_2004_12_06_v4_03_rX_branch and change the sysid.h file to produce 
v4.03r2_dev.  Development continues until v4.03r2_pre and finall v4.03r2 
at which point i create a tag called

If i need to do some potentially risky or intrusive development, I do it 
on a branch and use the BLAH_MODE string to keep tabs on what the branch 
is for. ie The branch would be called something like 


Adrian Crossley wrote:
> Hi
> We are about to migrate to CVS.
> We want to adopt the develop on trunk, tag for releases, branch from tags for post-release bugs method of using it.
> Can someone point me to a good convention for naming the tags and branches please?
> thanks in advance
> Adrian Crossley
> _______________________________________________
> cvsnt mailing list
> cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook