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: Sat, 04 Nov 2006 14:29:38 +0200 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1162643397 2591 80.91.229.2 (4 Nov 2006 12:29:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 4 Nov 2006 12:29:57 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 04 13:29:56 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 1GgKen-00072q-45 for ged-emacs-devel@m.gmane.org; Sat, 04 Nov 2006 13:29:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GgKem-0006Wr-LE for ged-emacs-devel@m.gmane.org; Sat, 04 Nov 2006 07:29:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GgKeZ-0006Wl-Ok for emacs-devel@gnu.org; Sat, 04 Nov 2006 07:29:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GgKeV-0006WH-8F for emacs-devel@gnu.org; Sat, 04 Nov 2006 07:29:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GgKeU-0006WE-UA for emacs-devel@gnu.org; Sat, 04 Nov 2006 07:29:35 -0500 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GgKeU-0007uz-Db for emacs-devel@gnu.org; Sat, 04 Nov 2006 07:29:34 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-21-235.inter.net.il [80.230.21.235]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id GEB09248 (AUTH halo1); Sat, 4 Nov 2006 14:29:31 +0200 (IST) Original-To: emacs-devel@gnu.org In-reply-to: (message from Eli Zaretskii on Sat, 04 Nov 2006 13:40:21 +0200) 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:61768 Archived-At: > Date: Sat, 04 Nov 2006 13:40:21 +0200 > From: Eli Zaretskii > > . CVS log entries should be simply the ChangeLog entries with the > file name and the leading TABs stripped. It is okay to reformat > and refill the text to make a better use of the line real estate > after the leading TABs were removed, but otherwise the text should > remain intact (but see below for an exception). > > . 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. > > . Since the previous rule separates the text for similar or related > changes in different files, entries that say "Ditto." or otherwise > refer to text for other files' entries should be rewritten to be > self-contained in the CVS log. This is an exception from the > first rule, which says that the ChangeLog text should generally > remain intact. > > . The ChangeLog files should be committed with an empty log message > (unless this is a real change in the ChangeLog file itself, not an > addition of log entries). One other rule: the date label of the ChangeLog entry should reflect the date on which the change was _committed_ (as opposed to the date when the change was made in someone's local sandbox). In other words, the dates in the ChangeLog should be monotonically increasing from bottom to top. This is frequently an issue when installing someone else's changes, but can also be a problem if you make a change in your local sandbox, then wait for a while before committing it.