On Feb 18, 4:25 pm, Todd Denniston <[email protected]> wrote: > *I* have been _fortunate_ enough that A) all my projects have forced a > comment at commit time, B) > Appropriately disciplined anyone who did not use a reasonable checkin > comment. Our biggest problem > is when folks checkin ONE FILE at a time instead of a coherent checkin of the > tree (with > individualized comments on EACH file) [has me reaching for my LART, by just > thinking about it again]. > So I can see what you are talking about, I have just only seen it polar > opposite in my environment.
Having blank or dummy comments is indeed a problem, and where I work we try to educate developers to invest the extra 15 seconds in producing better commit messages. As for having the same comment for the whole tree - it is not always the best option. For example: suppose I make some business-logic change, and to do this I need to add some enhancement in a utility function in a separate file, e.g. str.c. I prefer to have the comment on str.c describe what I changed in str.c, although I may include a comment on the context of the change and a bug ID for easier tracing. To allow better handling of change sets, we created a review system that allow developers to aggregate commits by change sets. The commit message of the first commit to be included in a review is automatically used as the review title, but the developer can later edit this title. If the commit message included a bug ID it is automatically added to a list of bug IDs related to the review. This system also handles review work-flow (author->reviewer->author) and auto-merging between branches. Yaron Yogev IT Software Developer Jungo LTD
