[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Commit practices

From: Karl Fogel
Subject: Re: Commit practices
Date: Sat, 29 Dec 2007 23:58:51 -0800
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

Richard Stallman <address@hidden> writes:
> The reason I have asked people not to commit multiple files
> is that they bloat the log entries of each file, making them
> essentially unusable.
>     I did it this way for a reason.  Someday we are going to want to
>     migrate the CVS tree to a VCS that has real changesets.  We're almost
>     certainly going to do it with a tool functionally like cvs2svn that
>     tries to reconstruct commit groups using date, the content of the
>     comments, and possibly this Commit-ID thing I see in the CVS logs. It
>     will be helpful, when we do that, if there as many similarities across
>     related commits as possible for the migration tool to grab onto.
> In effect, the suggestion here is that we abandon the idea
> of useful readable info associated by the VCS with each file.
> That would mean that the ChangeLog file is the only place
> for such info.
> I won't say "absolutely not".

Grouping each logical change together in one commit (even when the
change involves multiple files) allows tools like cvs2cl to do their
job (see http://www.red-bean.com/cvs2cl for more).  Thus, the info
recorded by the VCS *would* still be useful -- no need to abandon that
idea.  By the way, cvs2svn uses essentially the same algorithm.

So, the ChangeLog would not be the only place for this info.


All the CVS documentation I've seen specifically recommends grouping
each logically unified change together in one commit.  That is also
the way I have always used CVS, and the way CVS maintainers use CVS.
I realize this sounds like "argument from authority", but given our
finite resources, the time-tested experience of others may be worth
taking into account.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]