Version Control for code yet to be unit tested

My team has a dozen engineers, some of whom work on modules that will take 2-3 weeks to complete.

Now we in开发者_开发知识库tegrate each module to the main branch of CVS only after unit testing is completed.

The problem with this is for a good 2-3 weeks the code sits only on an engineer's computer and is not under version control.

The programming language used is C.

Is there any elegant way to manage non unit tested code under version control.

Thanks

James

Your process of 2-3 weeks before check-in to the "main" branch is not out-of-the-norm, as would be a similar re-design "root canal" effort (serious restructuring work that is sometimes necessary).

However, I would tend to get pretty nervous about that much time outside of version control.

1. Don't code angry.
2. Don't code drunk.
3. Don't code for a long time without version control "check-point".

A strong recommendation is that the local developer use Mercurial or Git for local version control for that 2-3 weeks, and then you can check the "finalized" project back into the (main) CVS branch. They are really built for exactly that scenario.

That's what we do -- it works, and it makes diffs-and-patches and collaboration between individual developers quite trivial.

(For us, Mercurial is local, Subversion is the "main" version control system.)

...for a good 2-3 weeks the code sits only on an engineer's computer and is not under version control...

Hm well to me programming outside of version control is like driving with reverse gear: technically doable but generally quite er counterproductive.

In that sense, I would say any other approach that somehow allows your developers to continuously keep their work under VC would be more elegant than nothing at all. For that, there are many known ways - googling for version control branching strategy shows plenty resources explaining your options and criteria how to choose.

Without experimenting it's rather hard to tell which of these options is a better fit for your project. When studying resources I refer to above I'd recommend to check details of what is usually called Feature Branch. This strategy rather closely matches the case you describe "modules that will take 2-3 weeks to complete" - although I wouldn't bet on that it's the best fit for your team.

Note also that at least for "internal" developers needs you have an option to use version control system other than old-fashioned and inconvenient CVS.

If your company policy requires all your code to be unit tested before checking in, I think it is pretty good policy, and you should do just that: write your unit tests, perhaps even before writing code.

But if I misunderstood you and it is just that there should be large testing session when everything is done, well, then it is too bad. You will definitely encounter pesky integration problems. If you cannot change that policy, at least have your local VCS. Also, you could have config with "featureX_Enabled" switches, and try not to forget to set it to '0' when checking in.

Anyway, switch to Git or Mercurial, they would be so much less painful to use.