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 */
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.
Fixing a bug is one atomic commit. Making changes to a docstring is
completely unrelated to fixing that bug and it is an error to include it in
the same commit. In practice we've found that conscientious grouping of
changes virtually eliminates the cruft that was originally being complained
about. When I first looked at bitkeeper I thought the per-file comments
were a nice idea but after using it for a few weeks in a pilot project we
decided it was useless in 99% of check-ins. For the remaining 1% of
check-ins we weren't overly bothered with the slight amount of cruft that
was introduced. Obviously, those were only the opinions of the developers
at my company and others will obviously disagree.
Justus
---------------------------------------------------------------------
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