Re: find changeset for a file
Yaron Yogev <[email protected]>
| Newsgroups | gmane.comp.version-control.cvs.general |
|---|---|
| Organization | http://groups.google.com |
| Message-ID | <894a2d6f-7cf6-42bb-b396-808df0b51527@p12g2000vbo.googlegroups.com> |
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