On 2002-01-23 17:14:31 Justus Pendleton wrote:
>>> I'm confused, why is a file involved in a commit if nothing about it
>>> changed? If something about it has changed, why isn't that being
>>> in the log message?
>> Now, later I run "svn diff foo" (meaning, I only want to see the log
>> messages for commits involving 'foo'). I'll see that whole log
>> message up there.
>I understand, that's what bitkeeper does and I'm not convinced that it is
>generally useful feature. We want commits to be atomic because we want
>grouping of files to have some semantic meaning. If an atomic commit has
>semantic meaning then why prefer it over what CVS provides? If I want to
>undo a changeset because the bugfix is wrong why should that also remove
>docstring you added?
>In my opinion and experience with perforce, the change comment is supposed
>to describe the change effected by the entire changelist, not the details
>changes to particular files. The comment should be relatively high level.
>If I need to find the details of which function had a docstring added to
>and when, the tool should provide a different way to find that -- like the
>p4pr.pl script people in the perforce world use, although there is
>room for improvement there -- I shouldn't be looking in the comments for
>just as I don't expect C source code comments to say
>/* This is a loop from 1 to 10 */
The docstring thing was just an example, surely. You can have a high-level
description of what was done to a single file, and it isn't the same as why
you did it. The kind of change comment you're talking about might say
something like "fix bug 1234", and maybe have some details of the bug,
but it won't tell you that you did that by adding functions f and g to
and type t to foo.h. You could tell that by doing a diff, but that gives
the entire text of f and g and t, when all you want is the plain fact that
they were added.
Where would you put that information?
For that matter, where do CVS users put it now?
I've started to use CVS here at work, so I would really like to know :-)
>If two files are undergoing unrelated changes such that they need to be
>documented separately -- such as your example showed -- then I would
>strongly question why they are being grouped into a single transaction.
So would we all. I agree that the log messages in cmpilato's example
did *look* unrelated, but imagine for the sake of argument that they
were not, that all the changes were an essential part of one feature
or bug-fix. That's the case that isn't addressed by having a single
message per commit.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:58 2006