After being away I've been trying to catch up on all the changes and for
some commits its not so easy to work out whats going on.

Big commits including multiple changes and vague or brief commit messages
make it really difficult to review changes. There was an Subversion Best
Practices talk at ApacheCon which talked about this pointing out the
importance of making it easy to review changes, especially with the
Commit-Then-Review style of working used be most Apache projects. The talk
pointed out things like: Commits should be for discrete changes with commit
log messages that make it easy to understand the change. Its not so hard to
do several commits instead of one big one, especially if you commit early
and often, and that also makes development more open than just committing
big chunks of finished function which has been developed off line. There's
also plenty of space in the commit log comments for whole sentences ... or
even several sentences if its a non trivial change.

Does this all sound like reasonable approach to everyone?

  ...ant

Reply via email to