CVS/SVN best practices for branching and tagging

Question

i'm going to be responsible for deciding how tagging branching is going to happen in our CVS/SVN repo.

Is there any literature that will help me understand the best way to work with CVS? either branching/tagging, etc?

thanks

Answer 1

Well, it doesn't really matter what source control system you use, they all basically follow some form of trunk/branches/tags structure. Even if it's a distributed model, the repositories will be setup in a way to reflect that.

There is a pretty simple explanation to get you started here.

Answer 2

Read this: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Answer 3

Sensible rules of thumb:

• Tag every build (ie., every build with a build number--anything you might send to testers or anyone else).
• Branch every time you need to branch.

Usually you need to branch released versions so you can test and release patches. You might have other reasons for branching.

And you're definitely better off with Subversion.

Answer 4

When going to my first real SCM (from source safe) years ago, I found the following helpful - back then there was a white paper by perforce I think:

http://www.perforce.com/perforce/bestpractices.html

Answer 5

If you want a starter for 10 for subversion:

Treat 'trunk' as a complete history of your development. Everything that ever gets released must appear in trunk at some point and in some form.

Use development branches(branches from trunk) in complicated development tasks. When task is finished, use re-integrate merge to pull changes from the branch into trunk. This way you have a few specific commits to trunk instead of many commits all related to the same task. Delete these development branches when no-longer needed. Name them like 'FeatureX'

Use version branches(again from trunk) to manage marketing versions which are destined to get released to customers/deployed to live. A version is a subset of the revisions in trunk. To use them, branch from trunk at an appropriate revision (may not be head), manually record the revisions from trunk as being merged into that branch, merge in any additional revisions you need from trunk (only from trunk). Do not develop directly onto a version branch, only merge from trunk - although the merge may need extra work to make it compatible with the version. Name like 'Version 2.4'

Create specific tags from your version branches whenever you make a build or hotfix that gets released to customers or deployed into live. Name like '2.4.1', '2.4.2' etc.

Working this way you can use subversion's merge-tracking (version 1.5 and above) to see exactly what's in each tag in a revision by revision basis. To do this, get a working copy of your tag or version branch and do 'svn mergeinfo --show-revs merged http://svn/trunk c:\workingcopy\'

That's great for auditors, auto-generated release notes, testers, and your own confidence about exactly what's in and what's out. Use an auto-generated matrix with this information to see at a glance what different versions contain.

Answer 6

I believe this is from coding horror:

Chris Birmele's paper on Branching and Merging is the best introduction I've found to this essential source control task. There are dozens of ways to branch, and no one correct way to do it. Get familar with your options so you know what the tradeoffs are with each one.

Branching and Merging Primer

Answer 7

I'd recommend using GIT as the tagging/branching process is extremely easy to use. The benefit of using SVN (especially on windows) is the number of GUI tools and the windows shell intergration.

I also second the recommendation for the Pragmatic Programmer books on SVN.

Answer 8

you should leave CVS. CVS is old and not very fast in terms of branching/tagging(branch/tag creation depends linearly on number of files in a project)

You should think of your branching strategy first: do you want to have a

• stable trunk
• feature branches
• developer branches
• unstable trunk / release branches
• platform branches

This heavily depends on your project and development philosophy

If you want to use SVN you really have to think of your repository layout, because nearly all softwareprojects are module-based and you should find a structure in which you can easily tag all needed modules. SVN with its folderbased approach of branches/tags is not easy to achieve this requirement.

This said it should be clear, that multirepository layouts are more difficult to maintain a stable tagging system. I prefer a "tag all" approach, however this is my personal choice.

Answer 9

The later entries in Eric Sink's Source Control HOWTO cover branching and merging.

Answer 10

I'd recommend reading the two Pragmatic Programmer books on SVN and CVS called "Pragmatic Version Control Using CVS" and "Pragmatic Version Control Using Subversion".

Both are excellent resources full of recipes describing what you want to do rather than the nuts and bolts descriptions of technology itself in the books previously mentioned.

HTH

cheers,

Rob

Answer 11

I recommend you SVN on Windows, Git on Linux. Don't use CVS, imho it's terrible.

SVN Book is that what you need first.

Tag every public build (release). Branch is a copying out trunk for some reason - e.g. another way of development. Branch repository everytime when you need :)

Answer 12

My personal experience during more than 10 years of CVS at the FreeBSD project is: switch to something else as fast as you can. CVS is file oriented not snapshot/changeset oriented which makes merging beween branches rather painful. Branches are painful with CVS anyway.

As for resources for CVS see CVS Home

If you want to talk about SVN, I'd suggest the SVN Book itself and this question.

Answer 13

The Cederqvist is generally regarded as the guide to CVS.