The basic idea in branching and merging is don't do it, unless you're sure what you're doing and you absolutely, positively, need it.

However, if you're going to do it anyway, make sure you have read the correct portions of the CVS manual.

Tagging branches

Try to name branches clearly and logically. Otherwise you'll need to check the available branch names each and every time.

For example, I once used the format BRANCH_Rx_y_DDMMYYYY, where DDMMYYYY is the branch date. However, I could never remember this, and working with multiple branches became a headache. Especially since the trunk is easy to get because it's named HEAD.

So, I'd suggest something really simple such as Rx_y_fixes.

--Janne

The "do not do it" advice regarding CVS branches is begging for an explanation. That you should only branch "if you absolutely positively need it" provides no information whatsoever. The failure to remember the format of a branch tag is a reason but not a rational reason. You can lookup branch tags in in a heartbeat and see what the format is if you are not inclined to write it down in several convenient places. You could choose to use something more symbolic like a version or build string and drop the date entirely.

I not only disagree wholeheartedly with the premise but would argue that you should always branch. That is in fact how CVS is used in the industry. It is in fact the very reason CVS was created in the first place: Concurrent Versions System. Tag interesting versions along the trunk and when you release one branch immediately. Add bug fixes to the branch for field updates and continue developing features on the trunk. Merge the bug-fix branch on a regular basis. I know of no competent software development shop that is not using a bug-fix branch. Now, if you do not believe merging is safe then needless to say you should not be using CVS.

Best Practices