From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: CVS commits and logs Date: Mon, 06 Nov 2006 11:30:07 +0900 Message-ID: References: <87r6wh1o5h.fsf@olgas.newt.com> Reply-To: Miles Bader NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1162780539 26733 80.91.229.2 (6 Nov 2006 02:35:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 6 Nov 2006 02:35:39 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 06 03:35:37 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GguKe-00039F-ID for ged-emacs-devel@m.gmane.org; Mon, 06 Nov 2006 03:35:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GguKe-0007xB-3z for ged-emacs-devel@m.gmane.org; Sun, 05 Nov 2006 21:35:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GguKO-0007v4-R0 for emacs-devel@gnu.org; Sun, 05 Nov 2006 21:35:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GguKM-0007s0-QR for emacs-devel@gnu.org; Sun, 05 Nov 2006 21:35:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GguKM-0007rr-LK for emacs-devel@gnu.org; Sun, 05 Nov 2006 21:35:10 -0500 Original-Received: from [203.180.232.83] (helo=mgate03.necel.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GguKL-00051M-8H; Sun, 05 Nov 2006 21:35:09 -0500 Original-Received: from relay21.aps.necel.com (relay21 [10.29.19.50]) by mgate03.necel.com (8.13.8/8.13.1) with ESMTP id kA61ciqe028882; Mon, 6 Nov 2006 11:35:02 +0900 (JST) Original-Received: from relay31.aps.necel.com ([10.29.19.16] [10.29.19.16]) by relay21.aps.necel.com with ESMTP; Mon, 6 Nov 2006 11:35:02 +0900 Original-Received: from dhapc248.dev.necel.com ([10.114.97.235] [10.114.97.235]) by relay31.aps.necel.com with ESMTP; Mon, 6 Nov 2006 11:35:02 +0900 Original-Received: by dhapc248.dev.necel.com (Postfix, from userid 31295) id 76CA657; Mon, 6 Nov 2006 11:30:07 +0900 (JST) Original-To: Bill Wohler System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <87r6wh1o5h.fsf@olgas.newt.com> (Bill Wohler's message of "Sun\, 05 Nov 2006 15\:15\:06 -0800") Original-Lines: 48 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:61845 Archived-At: Bill Wohler writes: > I agree if only one file is committed. However, if multiple files are > committed, I'd say leave the file names and strip the leading TABs. And what about multiple _authors_? Most of my commits are from automatic merging, which more often than not involves multiple authors. [I could just strip the author info from the commit messages, but it seems silly to remove useful information.] > I check in the ChangeLog at the same time as I check in the file whose > change it describes. It's easy and the ChangeLog check-in is less > prone to be forgotten. It seems this is a common practice. Is there a > good reason for your rule? Yes. Indeed, I think it's far better practice to check in all changed files (including ChangeLogs) with one CVS command, because it reduces the chance that someone will see a partial commit (something I see rather commonly actually -- some people seem to have a habit of commiting the source files first, and then waiting a while before committing the related ChangeLog changes (and it's not so uncommon that they just forget to commit the ChangeLog entirely!). Anyway, because of the nature of most of my commits, these rules seem very hard to follow -- doing so would automatically would be difficult, and the amount of extra work required to do so manually non-trivial -- I see no choice other than to basically ignore them. I can't see much justification for these specific rules anyway, other than a vague sense that the commit logs are prettier. [If there is some better justification, please do tell.] In fact, I think a rather different commit guideline might be more useful from a technical point of view: Commit all files in a single "changeset" with a single "cvs ci" command, with a single log message. This of course requires a commit-message format which can represent, at the least, multiple file. This particular guideline is useful because (1) it reduces the window of opportunity for race conditions, and (2) the identical commit messages are a _really_ useful hint to programs which scan the CVS repository trying to group related commits into logical changesets; this is typically done by gateways from CVS to a more modern source-code management systems. -Miles -- Fast, small, soon; pick any 2.