From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Please don't use revision numbers on commit messages (and elsewhere). Date: Fri, 01 Apr 2011 17:55:23 +0200 Message-ID: <87vcyyt190.fsf@wanadoo.es> References: <877hbfvwyo.fsf@wanadoo.es> <87tyeivni1.fsf@wanadoo.es> <87k4fevkc1.fsf@wanadoo.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1301673431 17330 80.91.229.12 (1 Apr 2011 15:57:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2011 15:57:11 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 01 17:57:08 2011 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.69) (envelope-from ) id 1Q5gib-0001Gw-HE for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2011 17:57:08 +0200 Original-Received: from localhost ([127.0.0.1]:57603 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5giT-0001z9-1y for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2011 11:56:53 -0400 Original-Received: from [140.186.70.92] (port=33647 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5ghH-0000vK-Ly for emacs-devel@gnu.org; Fri, 01 Apr 2011 11:55:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5ghG-0001rg-6J for emacs-devel@gnu.org; Fri, 01 Apr 2011 11:55:39 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:60741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5ghF-0001qv-Q9 for emacs-devel@gnu.org; Fri, 01 Apr 2011 11:55:38 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q5ghE-0001wn-9h for emacs-devel@gnu.org; Fri, 01 Apr 2011 17:55:36 +0200 Original-Received: from 131.red-83-59-5.dynamicip.rima-tde.net ([83.59.5.131]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Apr 2011 17:55:36 +0200 Original-Received: from ofv by 131.red-83-59-5.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Apr 2011 17:55:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 67 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 131.red-83-59-5.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:Q190D4OH318NAGAEzytgOswOwUQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:138007 Archived-At: Juanma Barranquero writes: > On Fri, Apr 1, 2011 at 03:20, Óscar Fuentes wrote: > >> Anyone can setup a public repo anytime, anywhere. Let's think of a >> long-lived feature branch of the type of lexbind or bidi which, for >> whatever reason, the participating developers finds more convenient to >> host outside of Savannah. > > I think Eli has already answered that: if/when it happens, we can > discuss how to minimize the problems. Until now, it is entirely > hypothetical. See my response to Eli about this. >> In the case of patches, using revision ids on the commit messages is, >> actually, most convenient, because on that case the referenced ids are >> unambiguous no matter on which branch the patch is applied. > > "Unambiguous" does not mean "I have it accessible and I know which > branch it refers to". Are you defending using revids because they are > unique, or because you don't like to having around multiple branches? Both reasons. Please note that if I read a reference to revision #XXXX on a commit message (or bug report...) and want to see its log on my machine, the scenario is at least as bad as if we were using revision ids. >> On a distributed project, you don't know how many active branches exist >> out there. > > Last time I checked, Emacs wasn't a "distributed project". It is a > centralized project with a distributed tool that helps developers. Once Emacs switched to a dVCS, it is a distributed project. You can insist on its centralization all the time, but the truth is that working on Emacs on a distributed way is a decisions that now belongs to each and every hacker. I can have my private branches, I can publish them from my machine, I can exchange revisions with other hackers. Eventually I can contribute those changes to "central" Emacs, but the process was distributed all the way, because I chose to do so. Whatever informal policy some Emacs hackers follow, it is irrelevant to me. > Sorry, you lost me here. "trunk, emacs-23 and what-not" can be mostly > summarized to "trunk, emacs-23 and nothing else", *unless* you're > actively tracking window-pub, lexbind-new or some other branch, which > most people (even developers) apparently don't do. If we maintained > dozens of branches, all of them vibrant with activity, I could buy it. > But we use a development branch and a release branch, and a few > almost-private-development-branches-that-nobody-tracks, and that > doesn't seem likely to change in the near future. This looks like defeatism :-) >> Do you prefer to wait until the problem has manifested itself on all its >> crudeness? :-) > > Sure I do. And you know why? Because Bazaar revnos are *convenient*, > and Bazaar revids are a royal PITA. I don't want to abandon convenient > shorthands for what, at the moment, is just FUD. Maybe you perceive the issue as FUD because your workflow? I admit that the problem is negligible *now*. How much importance it will adquire on the future depends on how Emacs development evolves. You say it will not turn serious because Emacs development will not change. Okay, time will tell.