The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

CVS - do you use branches and tags

Do you use branches and tags at your work place?

We have had a bunch or problems with branches and tags with CVS - basincally making the final reconcile.

We may go ahead with two cvs trees instead - one for development and the other for production.

Some other rules:

Developers will not work on files simultaneously

Once approved code will be migrated from development CVS tree to production cvs tree

The above seems a steps back but al least it is stopping us from the reconcilation headache and we minimize the risk of moving unauthorized changes to production.
NoCable Send private email
Monday, October 18, 2004
At my company, we tag each CVS module and we use those tags to build releases. That way, we know exactly which code versions each deployment has. Also, developers can check in code at any point while controlling when they release it.

Branches are a major headache, which I avoid whenever possible. You have to worry about maintaining and testing each branch, along with merging changes. I prefer to release the latest and greatest code to each customer. If different customers require different behavior, if statements and configuration files are a lot better than CVS branches.

Branches do make sense if you want to release a minor change to an old release, but upgrading the entire code base is risky. However, high-quality code and testing should reduce that risk.
Monday, October 18, 2004
Switch from CVS to CVSNT. CVSNT is a CVS branch that works on both Linux/Unix and Windows (despite what the name may hint).

It has significantly better support for merging/branching, it supports atomic commits, renames, and has various other bells and whistles. It's backward compatible, so once you migrate your server you start enjoying the benefits; you will need to upgrade clients to fully enjoy them (e.g., rename).

Also, if you aren't doing it yet, consider TortoiseCVS as a client. It supports CVSNT and rocks in general.
Ori Berger Send private email
Monday, October 18, 2004
OR just move to Subversion....

I forgot how difficult/bad cvs was until I had to use it on Sourceforge this past weekend.

KC Send private email
Monday, October 18, 2004
+1 for the suggestion for Subversion.

Branching/merging in CVS is hard at best. It's very well thought out in Subversion.
Brad Wilson Send private email
Monday, October 18, 2004
I use both: tags constantly, branches sparingly.  The advantage of branches is the magic -j switch.  On fairly stable projects, it lets you automatically merge branches.  Unfortunately, it doesn't seem to handle file removes, so if the project has changed a lot there's still a need for a visual diff and lots of "cvs remove ..." commands.

If you decide to stick with CVS, I recommend _Pragmatic Version Control_ by Dave Thomas and Andy Hunt.  Url:
David Gingrich Send private email
Monday, October 18, 2004
Stop yer bitchin', try branching and merging in Visual Source Safe and then we'll talk. Everything else is cake. ;)
Jon Newton Send private email
Monday, October 18, 2004
+1 on subversion.
Jon Newton Send private email
Monday, October 18, 2004
Tags are great, and don't cause problems.

Branches in CVs.  Yes, CVS will branch/merge nicely.  You can also fix a cavity yourself using only a cordless drill and some quick setting epoxy.  The pain level is about the same for these 2 activities.
Monday, October 18, 2004

What you're planning is exactly the opposite from how version control systems are meant to be used.

Live by it, or die by it...
Monday, October 18, 2004
I like subversion too, but I don't think it supports branch merging (á la CVS's 'update -j'). The question is, what sort of problems are you having? I don't see how using two seperate repositories is going to make things any easier, and you lose the automated branch merging in the process.

Admittedly, automatic merging of branches is no panacea, you still have to resolve merge conflicts and deal with files that have been removed and so on. But anything you have to do manually with two seperate branches you'd have to do manually with two seperate repositories. The difference is, you'd have to do much more by hand with a seperate repository...

Laurie Harper
Tuesday, October 19, 2004
I agree with genius.  Why would you possibly create two repositories and manually migrate changes?  Whatever problems you had with merging would only be worse with this scheme.  You've taken a difficult mostly-automated process and turned it into a difficult manual process -- a big step backwards.

My guess is that you were merging changes between branches in an unruly manner.  You should always merge the entire branch (not just one file) and do so between tagged points.  If you don't want the entire branch merged, then in my opinion you're using branching wrong.

If you'd like some suggestions on setting up the branches, send me an email describing your development/deployment process.
Jeremy Stein Send private email
Wednesday, October 20, 2004
We used to have a policy of merging cvs branches, and that policy lasted about one week, and it was a miserable week.
The Real PC
Friday, October 22, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz