The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

commit comment management

For anyone that is using CVS to help them manage their project(s), how do you store up all the changes or keep track of the changes you have made to your source files ready for the end of day commit?

I'm trying to think of some good practices (because I'm new to CVS) and something I'm struggling with is remembering all the little fixes, changes and features I make so that I can write decent comments.
Gavin Laking Send private email
Monday, January 10, 2005
It's really simple: just diff before commit and *read every line that has been changed*. this is a best practice or should be if it isn't.

In general though, you don't need to wait to the end of the day AND if you're using CVS you don't need to commit just because it's the end of the day. You should commit when you finish a section up to the point where the code is working again and passes tests.
Dave Seitel
Monday, January 10, 2005
Amen to that. I have a diff displayed to me automatically before commit, side-by-side with the comment window. Helps writing meaningful comments a lot.
Monday, January 10, 2005
Thank you for your responses. I've settled for committing more regularly (like fixing and testing a bug) and I run diff on the source file before writing my comments. At the moment, I don't think that is a problem because I only have a few source files but working through a directory as below could get tiresome if I go above 20 and make changes to all 20 files:

# cvs diff index.php
-- some output
# cvs commit -m "comment based on some output" index.php
-- changes made blah blah
# cvs diff organise.php
-- come different output
# cvs commit -m "comment based on new output" organise.php

Is there a preferred way of working here which will save me a lump amount of time each time I commit?

Thanks again, you'll make a developer out of me yet.
Gavin Laking Send private email
Tuesday, January 11, 2005
You shouldn't commit just once a day.

You should commit everytime you have a stable bunch of code.  If you have unit tests, it should be when they're passing.  If you don't, it should be whenever you finish one section and go to move on... as long as it doesn't break anything else.

I try to commit my code atleast 3-4 times each day.  Therefore, I don't have to track all of the changes, just the particular thing I'm working on.
KC Send private email
Tuesday, January 11, 2005
Also, if you're using some sort of bug tracking software (and you should be), include which bug number caused you to change the code.  You'll thank yourself for that later.
Aaron F Stanton Send private email
Tuesday, January 11, 2005
Gavin, "cvs diff" with no arguments to see all at once in directory.
Tuesday, January 11, 2005
You might want to pipe that to a file, by the way.
Aaron F Stanton Send private email
Tuesday, January 11, 2005
BTW, "svn diff" will display a combined diff for not just current directory, but for its subdirectories as well (if they're under version control.)
Tuesday, January 11, 2005
cvs stat

tells you what you've changed and what changes are pending.

svn is nicer.  You'll never go back...
hoser Send private email
Tuesday, January 11, 2005
I do:

cvs -q upd (in the main directory)

This give you an 'M' flag for every modified piece of code.
I like to cvs diff them individually.

Better, use the PCL CVS mode in emacs, as it has a very powerful 'diff' feature. There is an application called Cervisia available for Linux that does this kind of thing as well. The equivalent on windows is WinCVS.
Greg Reynolds Send private email
Thursday, January 27, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz