-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
branch.
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
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=69&page=6
~ 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
documenting code.
- --
Simon Ward
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB6wYxSv/U/7hQbiwRAvd+AKCm/09YucCX8zMLyvZxbpk2kE2WLQCeK6FC
1OxTOZ2CnOBeF5jJ5/7XwTA=
=725E
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 17 01:34:21 2005