I'm not sure I actually *like* asking people to consistently split their
commits up, though. It's very convenient to make a variety of changes
in one commit, at our current size this doesn't feel like a major
problem, and it's certainly a widespread practice. But perhaps it's
worth thinking about.
I'm in agreement with Ted - (plus, I like the term "omnibus commits"
:)) - when you check in a massive change that breaks something, that is
only asking for trouble.
This is why I advocate the frequent-checkpointing style of committing -
each incremental change that you make, that leads to a code that still
works, check it in. This holds even if you're going to check in the same
file twice in one day.
For instance, when I was doing the sections, I made at least 2 passes at
cleaning up and reorganizing the Table/Grid code, with no change to
functionality.. I committed each time before committing any actual
section work, even though I had section work in progress in my own tree.
That way if I have broken something, I can figure out if it was failed
refactoring or new code.
The double bonus is, if you've checkpointed just 5 hours ago and you
realize that you've mostly just written garbage since then, at least you
can throw your code out and go back to where you were 5 hours ago,
rather than losing days of working off in your own tree.
Alec
Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
