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: Fri, 01 Jan 2010 18:21:46 +0900 Message-ID: <87hbr6npsl.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87d4206n80.fsf@canonical.com> <87637qhjqu.fsf@red-bean.com> <87fx6urat1.fsf@telefonica.net> <87oclig1qj.fsf@red-bean.com> <87bphir8s4.fsf@telefonica.net> <87zl52o82l.fsf@uwakimon.sk.tsukuba.ac.jp> <87ws06plss.fsf@telefonica.net> <87y6kmo0w7.fsf@uwakimon.sk.tsukuba.ac.jp> <87oclipeuj.fsf@telefonica.net> <87637ppyhl.fsf@red-bean.com> <83oclhejpx.fsf@gnu.org> <87hbr9ir78.fsf@stupidchicken.com> <87tyv7ofd3.fsf@uwakimon.sk.tsukuba.ac.jp> <874on7lkfd.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1262337117 28022 80.91.229.12 (1 Jan 2010 09:11:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Jan 2010 09:11:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 01 10:11:50 2010 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 1NQdXx-0005w5-RC for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 10:11:50 +0100 Original-Received: from localhost ([127.0.0.1]:38109 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQdXx-0005WS-Vq for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 04:11:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQdXs-0005W3-6i for emacs-devel@gnu.org; Fri, 01 Jan 2010 04:11:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQdXn-0005VV-4P for emacs-devel@gnu.org; Fri, 01 Jan 2010 04:11:43 -0500 Original-Received: from [199.232.76.173] (port=51173 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQdXm-0005VS-Tn for emacs-devel@gnu.org; Fri, 01 Jan 2010 04:11:38 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:42903) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQdXm-0002X0-9V for emacs-devel@gnu.org; Fri, 01 Jan 2010 04:11:38 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id D0A3E7FFA; Fri, 1 Jan 2010 18:11:35 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D0F421A33D7; Fri, 1 Jan 2010 18:21:46 +0900 (JST) In-Reply-To: <874on7lkfd.fsf@telefonica.net> 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:119190 Archived-At: =D3scar Fuentes writes: > Oh my God. Really, really, really, why so much insistence on having >=20 > 87344 Fixed bug #4223 > 87344.1 Fixed bug #4223 >=20 > instead of just >=20 > 87344 Fixed bug #4223 First, because there is absolutely nobody insisting on that. Take your strawman elsewhere. Second, because without changes in Handa-san's workflow, it will actually look like this anyway: 87345 ChangeLog for 87344 87344 Fixed bug #4223 What Handa-san has done until now, according to his post, would actually result in (for that case) something like 87344 ChangeLog: Fixed bug #4223 87343 Updated callers in quux.c 87342 Updated callers in baz.c 87341 Updated callers in bar.c 87340 Updated prototype in foo.h 87339 Added argument to snafoo in foo.c The problem I'm pointing out is that *for Handa-san, exactly the same personal workflow as in CVS* works fine with bzr, too. He will not notice any problems because in a CVS-alike workflow he probably doesn't use "bzr log", he looks at the ChangeLog. The ChangeLog will look as it does in CVS. But "bzr log -n1" will show the commits as above, which is not very nice for *other* people who find that bzr's advanced features improve *their* workflows. Unfortunately, that's the most likely outcome if he followed your original advice. It was only later that you said "oh, of course he should change his workflow so that he commits coherent changsets". I'm sure he's willing to do so if so advised, but that's not what you said in your first post. And rms, at least, has been opposed to asking anybody to change their workflows until they're ready to do so. Ditto, Eli Z. It's not clear to me that there is a huge advantage to him if he has to alter workflows anyway. Some people might prefer to keep the "C-x v v"-based workflow, and then "merge to mirror + commit to the remote repo" as a separate step that they could do once a day, or once a week for that matter. In that case, we would see 87344 Merge: Fixed bug #4223 87343.6 ChangeLog: Fixed bug #4223 87343.5 Updated callers in quux.c 87343.4 Updated callers in baz.c 87343.3 Updated callers in bar.c 87343.2 Updated prototype in foo.h 87343.1 Added argument to snafoo in foo.c which would by default (ie, just "bzr log") appear as 87344 Fixed bug #4223 of course. This requires maintaining two branches, one for the actual commits, one for merge and commit + push (unbound) or commit (bound). But it does work fairly well for users of vc who use the "C-x v v C-x b ... (repeat)" workflow, and with feature branches. The only thing it's really horrible for is the one-line, one-file fix -- and until Emacs abandons ChangeLogs, those are really rare because the fix will be accompanied by a log, unless the fix is in the ChangeLog itself. Some folks wouldn't like that much, I imagine (ie, those who insist on coherent changeset commits). Finally, note that none of the above mentions the fact that if Handa-san decides to do some extended work on a branch, he'll need to learn the work branch + trunk mirror workflow anyway.