Xp Version Control Faq
From XpFaq
What's the exact workflow to IntegrateContinuously using CVS?
The normal sequence of events is this:
- You make some changes to your private work area that you'd like to commit
- Run your ProgrammerTests and make sure you get a GreenBar (checking in RedCode is forbidden)
- Get the IntegrationToken (lunch boxes are common) or
- Wait until the dedicated IntegrationMachine is free; get (the contents of) your private work area to the IM somehow (using a branch is the fancy way; getting to your private work area with NFS or some other drive-sharing method is the easy way)
- Pull everyone else's changes into your private work area: cvs update
- Run the ProgrammerTests again; you may need to make some minor changes to the code if some interfaces have changed. If it's not immediately obvious what to do, yell for help from whoever last changed the code in question. Keep at it until you get a GreenBar or decide to scrap what you've changed and rewrite it (this is an easier option if you integrate more frequently).
- Run the CustomerTests (depending on your local process; if they take hours to run, don't hold up integration for them; you might, alternatively, run a subset of them). If a CustomerTest fails: bail out of integrating; write a ProgrammerTest that would catch the bug; fix the code; start integration all over again from the top.
- Come up with a brief log message: CVS will tell everyone exactly which lines of which files were changed, and what the before and after look like, so the log message should be at a higher level: the what and the why. The name of the task you were working on is a good candidate.
- Commit your changes: cvs commit -m "Added twist bar to feature foo"
- Release the IntegrationToken or IntegrationMachine
- Announce your successful integration: ring a bell, send an email, send an instant message (this can be automated)
- If you used an IntegrationMachine, you may need to update your private work area again: cvs update
This should happen at least a few times a day per person. Some teams commit even more frequently (every five minutes, or every time they get a GreenBar), but that's a matter of style and local context (e.g. how long it takes to get the IntegrationToken or IntegrationMachine, how long it takes to run the tests, etc.) [We really need a HowOftenShouldYouCommit page to cover this; starter text can be taken from here, ExtremeVersionControl, and ExtremeVersionControlDiscussion.]
Won't collective code ownership result in lots of merge conflicts?
If practiced correctly, no. This is a common fear but turns out to be rare in the real world. With a good tool, such as the free CVS, merges are also relatively painless even when they do occur. The most important thing to remember is to IntegrateContinuously: integrate at least once a day. Four times a day wouldn't be too many. Another important thing is to have your code covered with automated UnitTests. They will tell you if the merge does break something even though it happens only occasionally. Another important thing is that refactoring to satisfy OnceAndOnlyOnce typically produces small, loosely coupled objects. Any one change is unlikely to affect many objects. Another important thing is that the probability of conflicts rises hyper-linearly with the number of streams of changes, so pair programming dramatically reduces the probability.
As an aside, CVS is a very bad tool for private/task branch techniques, as anyone who's used it for this can attest. As an example:
You have a 2 minute fix. You make a task branch (this takes 2 hours, since your codebase is rather large, and you have TONS of tags due to the task branch methodology), you fix the bug, you check in, you merge, and tag (another 2 hours) the merge. Total time for 2 minute fix: 4 hours. It's just the nature of the beast.
DistributedVersionControl systems are designed for this use. SubVersion is also much better than CVS in this regard.