It is very tempting to just simply say

   cvs commit .

in a top level directory, and then type in all of the changes at once. However, if you really only made a small change (like edited a typo in the javadoc) you don't want to hear about changes in every other file. Imagine the following log entry:

- Change frobozz() to accept ints instead of Integers
- fixed plenty of bugs
- new RegularExpression class does regular expressions
- Forgot to reset m_credit in Ugh.
- Incorporated Brian's changes into the main CVS tree
- fixed typos

Now, when you have to find out which version of MyClass.java was the last functional, you will have to wade through hundreds of lines of totally non-essential stuff. Not good. Also, can you be reasonably sure you've remembered everything? Every change you made?

A much better way is to make sure your IDE supports CVS and commit each file individually. For example, Emacs with PCL-CVS works wonderfully. So does CodeGuide.

Commit files individually! Otherwise your comments become unreadable.


But wouldn't this, in all likelyhood, mean that the build is broken between when you start checking in files and when you finish? What if you get interrupted for an hour?

I think what's being gotten at here is that a checkin should only be about one or two things, and that I agree with, especially towards the end. When we're in Alpha, it's one bugfix per changelist. -- MahlenMorris

Yes, of course. Thanks for pointing that out. This ties in with the CommitAFeature -principle, which says that you should only commit one fix in at a time. If you commit a huge number of changes in, each file individually, then it's quite likely that the CVS tree would be in a non-compiling state at some point, breaking DontBreakTheBuild -principle. --JanneJalkanen

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-8) was last changed on 22-Aug-2007 14:58 by JanneJalkanen