From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs is on Bazaar now. Date: Mon, 28 Dec 2009 22:51:13 +0900 Message-ID: <877hs7p5pq.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87d4206n80.fsf@canonical.com> <87637r610w.fsf@red-bean.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262007657 26459 80.91.229.12 (28 Dec 2009 13:40:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Dec 2009 13:40:57 +0000 (UTC) Cc: kfogel@red-bean.com, Andreas Schwab , emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 28 14:40:49 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 1NPFq4-0008Hu-Qz for ged-emacs-devel@m.gmane.org; Mon, 28 Dec 2009 14:40:49 +0100 Original-Received: from localhost ([127.0.0.1]:42128 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPFq5-0000mt-4M for ged-emacs-devel@m.gmane.org; Mon, 28 Dec 2009 08:40:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NPFpy-0000kR-31 for emacs-devel@gnu.org; Mon, 28 Dec 2009 08:40:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NPFpu-0000iG-7x for emacs-devel@gnu.org; Mon, 28 Dec 2009 08:40:41 -0500 Original-Received: from [199.232.76.173] (port=40791 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPFpt-0000iD-9u for emacs-devel@gnu.org; Mon, 28 Dec 2009 08:40:37 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:38675) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NPFpt-0006eX-0A for emacs-devel@gnu.org; Mon, 28 Dec 2009 08:40:37 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 106151535AF; Mon, 28 Dec 2009 22:40:34 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1578F1A33D7; Mon, 28 Dec 2009 22:51:14 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 1444e28f1a3d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:118868 Archived-At: Kenichi Handa writes: > For instance, I recently committed these changes in CVS > (just before it becomes readonly) > > 2009-12-25 Kenichi Handa > > * composite.h (composition_adjust_point): Update prototype. > > * composite.c (composition_reseat_it): Don't make a composition > spanning over point. > (CHAR_COMPOSABLE_P): Treat U+200C (ZWNJ) and U+200D (ZWJ) as > composable characters. > (composition_adjust_point): New arg NEW_PT. Callers changed. > > * keyboard.c (command_loop_1): Force redisplay if the last point > was within a composition. > (adjust_point_for_property): Don't adjust point for automatic > composition when called after buffer modification. > > At that time, each changed file got it's own CVS log because > I committed each file with C-x v v while supplying its own > log by using C-c C-a. > > Now with bazaar, according to the wiki page, it seems that I > must commit all files at once with a single log, and thus > all changed files are given the same log. Is that true? It's true that all files committed at one time get the same VCS log. > Is that the right thing? Yes. There are alternatives that are closer to your CVS workflow. However, some involve per-file commits. Those will probably be opposed by many developers because they will make the VCS logs harder to read and understand. There are also tools that allow you to manage changes on a piece by piece basis. Then you finish by grouping them into a single commit. The disadvantage to those tools is that they will require additional effort on your part to install and learn them. If adjusting to this style is really uncomfortable for you, we can discuss the options. > If so, is there any convention about the format of the log? > Can I use a relevant part of ChangeLog file as is? Reusing the ChangeLog entry is very common in other projects that use ChangeLogs. A good Emacs ChangeLog entry will generally correspond to a single commit in Bazaar, so it can be reused for the VCS log for that commit. As Juanma says, it's very useful to the readers to provide a one-line summary at the top of each entry. Eg, the ChangeLog entry quoted above looks like it describes a set of changes that should constitute a single commit[1], and that log would be in good style if you add a summary, such as "Improve redisplay and point handling in character composition". Footnotes: [1] The change to CHAR_COMPOSABLE_P might better be split out into a separate commit, unless that change is needed because of the other changes.