From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: bzr repository ready? Date: Sun, 22 Nov 2009 21:28:58 -0500 Message-ID: References: <87639fr3w7.fsf@red-bean.com> <87vdhfpil2.fsf@red-bean.com> <87einvxy9c.fsf@red-bean.com> <20091118230952.GB908@muc.de> <87my2jw05z.fsf@red-bean.com> <83skc9pbf7.fsf@gnu.org> <87iqd5vw5n.fsf@red-bean.com> <877htl53tc.fsf@telefonica.net> <87ws1ku7zd.fsf@red-bean.com> <87hbso4s13.fsf@telefonica.net> <83aaygoy90.fsf@gnu.org> <87vdh36d48.fsf@telefonica.net> <831vjrptha.fsf@gnu.org> <87einr63b6.fsf@telefonica.net> <83y6lzo9e7.fsf@gnu.org> <871vjr750o.fsf@uwakimon.sk.tsukuba.ac.jp> <83tywnnq34.fsf@gnu.org> <873a475bsr.fsf@telefonica.net> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1258943357 11952 80.91.229.12 (23 Nov 2009 02:29:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2009 02:29:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 03:29:10 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 1NCOfu-0007aF-7S for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 03:29:10 +0100 Original-Received: from localhost ([127.0.0.1]:45729 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCOft-0000Yr-J9 for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2009 21:29:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCOfo-0000Ym-HR for emacs-devel@gnu.org; Sun, 22 Nov 2009 21:29:04 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCOfj-0000X8-5n for emacs-devel@gnu.org; Sun, 22 Nov 2009 21:29:03 -0500 Original-Received: from [199.232.76.173] (port=42438 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCOfi-0000Wy-VL for emacs-devel@gnu.org; Sun, 22 Nov 2009 21:28:58 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:58390) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCOfi-0007mO-MC for emacs-devel@gnu.org; Sun, 22 Nov 2009 21:28:58 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NCOfi-0000HY-5m; Sun, 22 Nov 2009 21:28:58 -0500 In-reply-to: <873a475bsr.fsf@telefonica.net> (message from =?utf-8?Q?=C3=93scar_Fuentes?= on Sun, 22 Nov 2009 07:11:16 +0100) 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:117539 Archived-At: BTW, one thing that the people who only have experience with CVS does not appreciate, is a changeset-oriented VCS, where the source base transforms on discrete and well defined steps. Among other things, this makes the Changelog unnecessary, as it turns to be the equivalent of `bzr log'. They are not equivalent. The ChangeLog files are included in the checkout, so you can read them even when you are offline (which is nearly all the time, for me). `bzr log' requires contact with the repository. The obvious solution, running `bzr log' and saving output to a file with every update, is not a full solution since it won't give the real information about branches that were merged. Is there a way to get all the information about what has been merged into the current trunk? Various directories have separate ChangeLog files. Is that true also for `bzr log', or is it one log for the whole package? Another convenience with ChangeLog files is that we split them into manageable-size parts. It would be nice to have a script that would do the same thing to the output of `bzr log', preferring to split at the points where releases occurred.