I've posted a meditation on perlmonks about more fully using all the features CVS has to offer, namely branches (which I've rarely used). I want to "Take it to the next level" so to speak.
The gist of it is that we'll use the trunk for "stable" releases, and create branches for each new project/bugfix. Each branch will eventually be merged back into the trunk, and a new release tagged on the trunk. I would appreciate any tips the community here has to offer, especially in the way of managing a complex CVS tree.
At work we branch once we start a new release and wrap up the old release, then we merge the bug fixes and such into the trunk on a regularly so you don't have to make the bug fix twice.
but I don't think it will work for us. In our case there are 2 developers here, and we generally don't work on the same projects. The release dates for said projects will probably never coincide. So whatever we do will have to support independent projects.
If all development is on the trunk, then we can only check in changes once we know they are stable & won't break the trunk. This has the benefit of letting each other know quickly if API's change. But it also can potentially hurt the other developer from making major changes since it will probably impact the other person. This style of branching was used at a previous employer where everyone worked on features for a given release.
If we develop on branches, we get independence from stepping on each other's toes and commit often. Yes, this can potentially make merges "fun", but I think it's worth the effort in this case because of the added independence to experiment. It also just seems to fit better for us since each person is working on different releases.
To make an analogy: The trunk is the stable portion of the tree. Everything else depends on it being solid. When we want to do something new, we create a branch, which grows upwards. Then when it's mature, we merge it back into the trunk, and the trunk gets bigger & stronger. It's not a perfect analogy, but it does pretty well IMHO.