Fog Creek Software
Discussion Board


We have a new policy at work regarding CVS. Every time I add or modify a file I have to check it out and tag it as my own development branch. After it's tested I have to merge it with the main development branch, and then merge it with the stable production branch.
All of us who are not used to CVS branching are spending a lot of time on this process and are having trouble with it. Sometimes the branching and merging takes up more time than coding. Even the manager who decided on this policy has trouble with it sometimes.
Does it sound like we're being overly careful, or is this a typical version control process? Are we having trouble just because we aren't used to it yet? In other words, will it eventually become second nature and not seem like a waste of time?
When we're in a hurry and have to fix a bug immediately, we cheat and just check it out of the production branch, make the needed changes, and then check it back in to the production branch.
Entering log comments with every commit also takes time, and it can be hard to think of what to write. If you changed one little thing then the comment might seem silly, and if you changed a lot of things it can be hard to them describe briefly.
I completely understand the importance of version control and I am not questioning that every file should be checked out, modified in my own directory, and then checked back in. But although I can see that branching would be needed under certain conditions, my feeling right now is that we should not be branching and merging as much as we are, because it wastes time.

Saturday, December 21, 2002

"When we're in a hurry and have to fix a bug immediately, we cheat and just check it out of the production branch, make the needed changes, and then check it back in to the production branch."

Since you're already cheating, I'm not so sure you'll ever consider the constant branching "second nature". You'll, however, consider "cheating" second nature.

Sounds like a failed system to me.

Lennart Fridén
Saturday, December 21, 2002

The tip of the CVS tree should be the current development, branches should be considerable divergences or long term development.

The tip is not for production, production itself should be a branch.

This is not to say that its ok to break the tip, its important that before checking in that its been tested to at least build and not break anything else.  This means checking out and merging before checking back in.

The last point is where bottlenecks occur and where people tend to take shortcuts, and then end up spending time backing code out and doing it all over again anyway.

Simon Lucy
Sunday, December 22, 2002

Yes, we have a branch for production and the main default branch is for development. My question is about the policy for individual development branches. If I have to fix a minor bug, I don't think I should create my own branch, then merge it with the main branch, then merge that with the production branch. I think I should just check out the production version, fix it, and check it back in. If the policy is overly complex and time-consuming, no one will follow it. Not because we like to cheat, but because we might under pressure to fix something immediately. On the other hand, once we have enough experience with branching and merging we might not consider it complex and time-consuming. But I'm concerned that it will never become quick and easy because of having to type so many log comments.

Sunday, December 22, 2002

That's fair enough, but if its a bug in the trunk, then it should be fixed in that and merged into any branches.  You shouldn't create branches just for the sake of it, no.

Simon Lucy
Sunday, December 22, 2002

From your description the system doesn't sound that bad.  The environment that I am working in only has a main production branch and developers create a separate branch for each modification, then merge back to the main.  There is no common development branch. 

I can see where your system has some advantages.  We sometimes merge several changes to the main branch, then find that there are bugs due to incompatible changes, and we have to back out changes.  This shouldn't be happening in the stable production branch.

If your management is pressuring you to bypass the procedure to get in quick bug fixes, then they need to rethink their policy and decide what's important.

Sunday, December 22, 2002

Perhaps the point could be brought out and discussed in a meeting with the staff to establish clear guidelines and see if it makes sense to have exeptions.

It seems to me that bug should be fixed out of the developement branch then merged into production. But making a branch so you can hunt down an = in the place of an == or something silly like that is overkill.

On the other hand, significant changes might be better in their own branch. The definition of significant can vary from environement to environement and also with the maturity of the code base.


Sunday, December 22, 2002

Maybe your CVS client is no good.  Checking in/out should not take more than a few mouse clicks.  This is my experience with SourceSafe.  Merging should be only a few more clicks.  I think some clients allow you to automate the whole process through shell scripts.

You say CVS operations takes more than coding.  Wow!

Amour Tan
Sunday, December 22, 2002

Looks like the manager who setup this policy has only works with other version control systems where the only practical way to work is this one (eg: Clearcase, Continuus)

As Simon Lucy pointed out, VCS is meant to be used differently, with the HEAD revision being the latest concurrent development branch, and the specific releases being separate branches.

Robert Chevallier
Monday, December 23, 2002

Finding a good branching strategy is hard. Karl Fogel's excellent book on CVS has some good ideas about how to approach branching. They're in the part of the book that's freely available online:

Beth Linker
Monday, December 23, 2002

My opinion is that if branches are mandatory, CVS is the wrong tool for the job.  You'd do better with Perforce or ClearCase, which have much better support for branching.

There are only a few valid reasons to make a branch:

1)  You need (or may need) version control for intermediate steps of development that won't affect other developers.

2)  You need a way to develop your changes across multiple machines.  You can use checkin and update as a way of synchronizing that development without affecting others.

If you aren't doing 1 or 2, then I can't see any reason for the overhead of a branch.

But, if the process nor the tool isn't going to change, I would invest a little time in a few scripts for getting the work flow you need as automated as possible.


Robert Anderson
Monday, December 23, 2002

Right now I'm finishing an application that I developed alone. When I make small changes or enhancements, is it ok not to branch?
For example, I check out the files, modify and test them on my local workstation, then check them back in to the repository, check them out on the development server,
and test them again. Finally I request to have them updated on the production server. None of that requires branching, it seems to me.

Monday, December 23, 2002

The way you are describing this makes no sense.
1. You make a branch for your working copy.
2. This gets merged with the development branch when you check in.
3. You then join the develoment brach with the production branch.
Is that the procedure? Your development branch and production branch are kept the same, but maintained separately?
If it is, someone does not understand how CVS is supposed to be used. The manual explains this very clearly.
It is easy, you check out the main, development branch. This is development, it may be unstable. You should definately have a policy of only checking in working code. Your working copy is just that, the code you work on.
You should do branch tags on each RELEASE. This way you can check out the release and make fixes and updates. These fixes can be joined back into the main line very easily.
Every release is a branch from the development tree. There is no reason to maintain a production branch that you make releases from.
This is the abstract of a good article on the subject from the Sept issue of IEEE Computer.

Doug Withau
Monday, December 23, 2002

I agree with Doug that this policy makes no sense at all. Unless a branch is used by > 1 entity (typically > 1 person but maybe you playing both developer and builder, or developer on multiple platforms), it is 100% overhead.

Even if you are sharing code between systems, you might be able to get away without a branch. You just move the modified files around. You can even do this to move proposed checkins to a build or test machine. Anyone know any cool tools to do that on CVS?

Monday, December 23, 2002

*  Recent Topics

*  Fog Creek Home