[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: find changeset for a file
From: |
Yaron Yogev |
Subject: |
Re: find changeset for a file |
Date: |
Sat, 19 Feb 2011 21:54:34 -0800 (PST) |
User-agent: |
G2/1.0 |
On Feb 18, 4:25 pm, Todd Denniston
<address@hidden> 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