-----BEGIN PGP SIGNED MESSAGE-----
Martin J. Stumpf wrote:
| The problem is that I may work non-stop for 8 hours on a project and
| touch a dozen files. With each class in its own src file and headers, I
| often need to make many modifications as the API evolves. The problem
| is that I don't want to commit too early because I know in my head what
| design requirement I am implementing in this work session and I am 'not
| finished yet' with the current coding objective. ...
I would encourage you to get away from that mentality, and rather commit
as soon as possible, whether or not the task is finished. If that would
break policy on the branch you are working on, then you can always
create a new branch for the task, and later merge it back into the main
I have started to get into the habit of doing this, however, I realise
others may find it difficult, since you have to actually remember to do
the commit, and you may even have to break out of your environment (for
example, if there is no shortcut key, or nice little button).
Donn M. Seeley writes in
~ In my experience, the worst problems are created by engineers who
don't want to check in their code until it's perfect and by those who
resist making informative log comments.
| Maybe I should be committing more frequently. Maybe I should create log
| message files. With the latter, the daily commit becomes laborious.
| What do you guys do to make the log really helpful on large projects?
You could list more than one change in the same log, say a bulleted
list, or short paragraphs separated by blank lines. You might even take
some ideas from the GNU Change log format, where files and functions are
listed, followed by a description of the change, but I found this to be
unwieldy. As well as having to remember or work out what changes you
have made (the svn status and svn diff commands help here), it will be
more difficult to pick out specific parts later on, if you ever need to.
Committing early has the advantage that you should still be clear on
what changes you actually made, which, incidentally, also helps with
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jan 17 01:34:21 2005