Feature branches in CVS?

Question

I'm duty-bound by policy to use CVS in this certain project, so even though I'd really to switch to something else, like Git, I cannot.

So, my real question goes like this: We have a convention that we create a new branch in CVS every time we make a release (we also tag, but that is besides the point). We call these version-branches, and they allow us to easily check out a specific version and make hot-fix changes to it - this is what our minor-releases are.

But now I have some large-ish, risk-ridden changes coming up and if I was working in Git, I'd be creating a feature-branch in the blink of an eye. However, working in CVS, I tried creating feature branches in another project and found that things quickly turned out messy. I ended up with lots of branches and I lost track of which branches were synched, which needed merging and which were no longer in use.

So, inching closer to the question mark, is it feasible to use feature-branches in CVS? Are they too much trouble to be worth it or will I eventually end up being sorry for not using them? Should I bite the bullet and just start coding in HEAD but bend my cpding process to introduce the changes in the most unobtrusive way possible?

Answer 1

One thing to consider is to actually close the feature-branch when you are done with it, once you have merged it back with the main trunk. In this context, close simply means abandon the branch, not a real deletion.

Once the work is merged, there really is no need for the branch to "exist".

In order to quickly identify what branches are feature branch, I would suggest having a naming convention leak "FEAT_MY_FEATURE" or "FEAT_20080926" (start date?). This would make it easy to disregard all those feature branches when browsing the repository structure.

Answer 2

If you are the only one developing on the feature-branch, you could simply use Git as your "sandbox development" system and then once you have the changes done, merge them into your CVS repository.

You still gain the benefit of source control for your intermediate work product.

Answer 3

There is an excellent discussion of branching strategies called streamed lines which might help - it describes the advantages and disadvantages of using feature branches.

It also covers options for code line owenership and policies that you might like to implement

Answer 4

I have worked in an environment for several years where this was common practice and it was really painful. Make sure that the merges are part of your project plan because they are going to consume a lot of time and are sources of delay.

Documenting the branches and assigning them specific responsibilities helped a little.

We had to create a tool to help us merge changes incrementally (one change at a time, instead of merging the tip of branches) because CVS does not behave well if the two branches diverge.

Often synchronize (at least once a week).

I think the best way to approach this in retrospect would be to make sure that divergence remains minimal and splitting the risky development in different milestones by using Scrum for example.

I also encourage you to read SCM Patterns. This books contains a lot of good advices.