Excerpts from Dave Thomas’ presentation during the Phoenix NFJS. The name of the presentation was "Pragmatic Version Control" and you can even buy the book associated with the topic. I am planning on implementing what I learned during the presentation, if I hit a wall in the process, I will be getting a copy of the book.

Naming Conventions

One of the main problems I found when investigating CVS was the lack of published “better practices”. Everyone suggests using naming conventions through your development team but there is nothing to say what is a good convention vs. a bad one. I was glad to see Dave, publish his recomendation for dealing with tag/branch names.

Usage	Format	Example
Release branch	RB_x_y	RB_1_0
Experiment branch	TRY_initials	TRY_dt
Release	REL_x_y	REL_1_0 REL_3_4a
Bug fix	PRE_fixno POST_fixno	PRE_TR123 POST_TR123
As presented during Dave’s session

File Management

Renaming files while maintaning file history

• Update local workspace cvs -q update -d
• Rename fileA to fileB mv fileA fileB
• Remove fileA from repository cvs remove fileA
• Add fileB to repository cvs add fileB
• Commit changes cvs commit -m 'Rename fileA to fileB'

Renaming a directory

I’ll come back to this one as it is a bit "time consuming"

Branches

There are 2 mistakes most commonly associated with branches in CVS: a) their overuse and b) not using them at all

Keep new development on the main trunk and only branch for off the main trunck

Create a branch prior to a release and to create a development playground. Do release-specific tweaks on the branch

While preparing a release, continue development on the main trunk and continue with commits as normal

Create a release branch

• Update, test and commit any changes with repository
• cvs rtag -b RB_a_b project_name

Working with a release branch

• Check out release branch to a separate working directory
• cvs co -r RB_a_b -d RB_a_b project_name

Create a release

• Synchronize with repository and execute tests
• cvs tag REL_a_b

Dealing with bugs

It is best to create a tag before and after fixing the code. This allows you to identify what were the changes made and create a patch file (or undo if necessary).

Use the same procedure for a release bug fix, just make sure you are working with the release branch

• Fix the bug first
• Update and resolve conflicts if any cvs update
• Create pre bug fix tag cvs tag PRE_bugfix
• Commit changes cvs commit -m 'Fix bug for ...'
• Create post bug fix tag cvs tag POST_bugfix

Merging a bug fix into main trunck

• Update mainline workspace cvs update
• Merge update cvs update -j PRE_bugfix -j POST_bugfix
• Test updates
• Commit changes cvs commit -m 'Fix bug from RB_a_b branch'

There is more dealing with experimental branches (similar to a release branch, just use a different naming convention), modules and submodules. I will add some of this information as I adopt it into our development environment. The presentation also included some great information for dealing with third party code. Again, I will add this information in the near future