[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: raises hand for bite-sized issue #604

From: <peter.westlake_at_arm.com>
Date: 2002-01-23 19:06:20 CET

On 2002-01-23 17:14:31 Justus Pendleton wrote:
>cmpilato@collab.net writes:
>
>>> I'm confused, why is a file involved in a commit if nothing about it
has
>>> changed? If something about it has changed, why isn't that being
mentioned
>>> 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
a
>generally useful feature. We want commits to be atomic because we want
the
>grouping of files to have some semantic meaning. If an atomic commit has
no
>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
the
>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
of
>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
it
>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
certainly
>room for improvement there -- I shouldn't be looking in the comments for
it,
>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
foo.c
and type t to foo.h. You could tell that by doing a diff, but that gives
you
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.

Peter.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:58 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.