From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giorgos Keramidas Newsgroups: gmane.emacs.devel Subject: Re: Workflow to accumulate individual changes? Date: Thu, 31 Dec 2009 15:43:57 +0200 Message-ID: <87oclfdzs2.fsf@kobe.laptop> References: <87637of4y8.fsf@kobe.laptop> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262267062 21633 80.91.229.12 (31 Dec 2009 13:44:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Dec 2009 13:44:22 +0000 (UTC) Cc: lekktu@gmail.com, Andreas Schwab , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 31 14:44:15 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NQLK2-0001cv-Do for ged-emacs-devel@m.gmane.org; Thu, 31 Dec 2009 14:44:14 +0100 Original-Received: from localhost ([127.0.0.1]:58680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQLK2-00066z-QO for ged-emacs-devel@m.gmane.org; Thu, 31 Dec 2009 08:44:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQLJx-00061q-4g for emacs-devel@gnu.org; Thu, 31 Dec 2009 08:44:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQLJs-0005sp-FK for emacs-devel@gnu.org; Thu, 31 Dec 2009 08:44:08 -0500 Original-Received: from [199.232.76.173] (port=39376 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQLJs-0005sl-Bs for emacs-devel@gnu.org; Thu, 31 Dec 2009 08:44:04 -0500 Original-Received: from poseidon.ceid.upatras.gr ([150.140.141.169]:58746) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQLJq-00024y-Gb; Thu, 31 Dec 2009 08:44:02 -0500 Original-Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 66962EB4829; Thu, 31 Dec 2009 15:44:01 +0200 (EET) Original-Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 86E3844FE0; Thu, 31 Dec 2009 15:44:04 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Original-Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 257P-hrCB86r; Thu, 31 Dec 2009 15:44:04 +0200 (EET) Original-Received: from kobe.laptop (ppp-94-64-238-171.home.otenet.gr [94.64.238.171]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 29BB244FDF; Thu, 31 Dec 2009 15:44:04 +0200 (EET) Original-Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id nBVDhxpj003455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Dec 2009 15:44:00 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Original-Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id nBVDhv7Z003452; Thu, 31 Dec 2009 15:43:58 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) In-Reply-To: (Eli Zaretskii's message of "Thu, 31 Dec 2009 07:23:28 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (berkeley-unix) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:119149 Archived-At: On Thu, 31 Dec 2009 07:23:28 -0500, Eli Zaretskii wrote: >> From: Andreas Schwab >> Cc: lekktu@gmail.com, keramida@ceid.upatras.gr, emacs-devel@gnu.org >> Date: Thu, 31 Dec 2009 12:44:46 +0100 >> >> Eli Zaretskii writes: >> >> > Are you suggesting that the commit message should not mention the >> > changes in individual files at all, just the general idea? >> >> Yes, that's what they are for. > > But then the corresponding ChangeLog entries should have the text > identical or very similar to the commit message in front of them, or > else have some other means of locating the log entries easily. > > Anyway, I'm okay with this policy, if Stefan and Yidong approve it. I think it's very useful to see file changes in the ChangeLog. It helps a lot when an Emacs user downloads a tarball of the sources from the FTP site, because file changes are visible without full access to the original branch itself or access to a bzr client. Maybe we can try to strike a balance between not keeping the ChangeLog up to date at all and making it difficult to commit *one* changeset that includes both ChangeLog updates _and_ file updates by committing the ChangeLog updates separately? This way, we can have a very short summary in the ChangeLog commit, e.g.: : keramida@kobe:/tmp/bzrdemo$ cat ChangeLog : 2009-12-31 Giorgos Keramidas : : * foo: Add a new 'foo' file. : : keramida@kobe:/tmp/bzrdemo$ bzr log --show-ids : ------------------------------------------------------------ : revno: 2 : revision-id: keramida@ceid.upatras.gr-20091231133847-f7og1ku98r1ng019 : parent: keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1 : committer: Giorgos Keramidas : branch nick: bzrdemo : timestamp: Thu 2009-12-31 15:38:47 +0200 : message: : ChangeLog for keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1 : ------------------------------------------------------------ : revno: 1 : revision-id: keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1 : committer: Giorgos Keramidas : branch nick: bzrdemo : timestamp: Thu 2009-12-31 15:36:56 +0200 : message: : Add a new 'foo' file. : : keramida@kobe:/tmp/bzrdemo$ To avoid doubling the revisions we keep in the repository, by following *every* single commit with a ChangeLog update, we can batch ChangeLog updates. So a developer can work in his own local branch and commit several local changes before updating the ChangeLog. Then a single ChangeLog commit on top of those can be stacked on top of the batch of local changes, right before they are pushed to the trunk. In a related side-node, it seems vc-update-change-log doesn't grok bzr branches. What are the missing bits? Can we add them now that Emacs itself uses bzr?