From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: CVS commits and logs Date: Mon, 06 Nov 2006 06:21:50 +0200 Message-ID: References: <87r6wh1o5h.fsf@olgas.newt.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1162786949 6997 80.91.229.2 (6 Nov 2006 04:22:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 6 Nov 2006 04:22:29 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 06 05:22:27 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 1Ggw03-0005E3-5D for ged-emacs-devel@m.gmane.org; Mon, 06 Nov 2006 05:22:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ggw02-0005Si-HY for ged-emacs-devel@m.gmane.org; Sun, 05 Nov 2006 23:22:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ggvzp-0005Qz-UY for emacs-devel@gnu.org; Sun, 05 Nov 2006 23:22:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ggvzo-0005Pu-Fr for emacs-devel@gnu.org; Sun, 05 Nov 2006 23:22:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ggvzo-0005Pi-As for emacs-devel@gnu.org; Sun, 05 Nov 2006 23:22:04 -0500 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Ggvzo-0002rC-1Y for emacs-devel@gnu.org; Sun, 05 Nov 2006 23:22:04 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-144-51.inter.net.il [80.230.144.51]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id GEL19594 (AUTH halo1); Mon, 6 Nov 2006 06:21:56 +0200 (IST) Original-To: Bill Wohler In-reply-to: <87r6wh1o5h.fsf@olgas.newt.com> (message from Bill Wohler on Sun, 05 Nov 2006 15:15:06 -0800) 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:61846 Archived-At: > From: Bill Wohler > Date: Sun, 05 Nov 2006 15:15:06 -0800 > > Eli Zaretskii writes: > > > . CVS log entries should be simply the ChangeLog entries with the > > file name and the leading TABs stripped. > > 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. But the next rule says each commit should be only one file, so there's no ``if''. > > . Each file should be committed separately, even if the changes are > > related, and the CVS log entry should be for the changes in that > > file only. In particular, the modified files and the ChangeLog > > file with the appropriate log entry should be committed separately > > (thus the CVS log entries for ChangeLog files should never include > > log entries for the modified files). Exception: it is okay to > > commit several changes to a single ChangeLog file in one "cvs ci" > > command if those changes are related to the same feature/bugfix. > > This isn't clear. In the first sentence you say, "even if the changes > are related" but the exception says--paraphrased--"except if the > change are related". Which is it? The exception is from the second sentence that talks about ChangeLog files only. > by enumerating all of the file names in a single log message, you > can see easily which files are affected by a given change. As I understand, this can be seen from the ChangeLog itself, you don't need to go to CVS. Also, if multiple file commits are allowed, nothing prevents people from committing unrelated changes in one go. > 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? Those are not my rules, I just took a liberty of describing the rules Richard requested me to follow a long time ago.