The Initial Code Import
To make the initial code import, I first created two VOBs (versioned object base, the project repository)--one for the products and another one for the components. (Again, we were using Rational Clearcase LT, and the terminology varies from tool to tool.) Then I imported both all the code for the project and for the different components.
Once everything was there, I compiled each of the applications (having a project group or makefile-based build system helps). If it goes well, then you have your first controlled release. So what I did was label the entire source tree with the name of the release, V151 in this case.
Once the code was there, we prepared some documents about setting up views and filling in the configspecs.
And The Process Will Follow...
Putting all the codebase under source control was the first step to bring some order into the project. But then it was necessary to introduce a whole working process together with the tools.
Our process was quite simple: Every single change to the source code had to be registered into a homemade task control application. It would assign a number to the issue (being a bug, new feature, or whatever), and with this number (and in our case a prefix) we would create a branch in Clearcase. We are using a branch per task pattern, so every single development is isolated in its own branch. It would be a big burden for several SCM tools, but not for clearcase.
So each task has its own branch and is assigned to one developer. Hence each developer gets completely isolated from the others, his own changes won't affect his colleagues, and neither he will be bothered by incomplete modifications from the rest of the group. You will get this benefit using any SCM tool, is just a consequence of workspaces, but if you add branches to the picture then developers get extra facilities like version control on their ongoing work. This is really useful once you get used to it.
Figure 3 shows the development cycle we used.
Basically the project manager is responsible to introduce tasks in the in-house task control tool. Tasks are assigned to developers. Each developer works on one task. Once a developer finishes his work on a task, he undertakes unit tests. The task won't be finished until all the unit tests are passed. When we started with SCM we didn't have unit tests in place, but as we were progressing we started to introduced this technique, which proved to be helpful. We use Dunit. Once a task is finished the developer moves to another one, creating a new branch and so on.
After some time, you end up with a pool of finished tasks, with their associated branches containing all the modifications.
