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 02:11:50 +0200 Message-ID: <87tyeivni1.fsf@wanadoo.es> References: <877hbfvwyo.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 1301616737 17892 80.91.229.12 (1 Apr 2011 00:12:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2011 00:12:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 01 02:12:14 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 1Q5RyG-0001Lv-Nr for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2011 02:12:13 +0200 Original-Received: from localhost ([127.0.0.1]:48062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5RyF-0004Qm-VE for ged-emacs-devel@m.gmane.org; Thu, 31 Mar 2011 20:12:12 -0400 Original-Received: from [140.186.70.92] (port=53243 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5RyA-0004QR-1s for emacs-devel@gnu.org; Thu, 31 Mar 2011 20:12:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5Ry8-0001Qt-NN for emacs-devel@gnu.org; Thu, 31 Mar 2011 20:12:05 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:46466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5Ry8-0001QW-9u for emacs-devel@gnu.org; Thu, 31 Mar 2011 20:12:04 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q5Ry5-0001Ij-LF for emacs-devel@gnu.org; Fri, 01 Apr 2011 02:12:01 +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 02:12:01 +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 02:12:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 72 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:1pq9MJcfqzDm5MmoH3OphAaccj0= 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:137960 Archived-At: Juanma Barranquero writes: > On Thu, Mar 31, 2011 at 22:47, Óscar Fuentes wrote: > >> A revision number only makes sense on the branch where it was created >> (and this only after setting some options, as Emacs did.) > > Yeah, well, we're dealing with Emacs, not some random bzr branch. The Emacs project has a number of branches published on a well-known site, and hopefully other branches distributed along a number of personal machines. I'm saying that using revision numbers is confusing when those revisions are merged across branches. Across *any* branches, including the "random" ones (whatever your definition of "random branch" is.) >> If I'm reading >> the VC log on a random branch and see "Fix breakage introduced by rXXXX" >> and want to look at the referenced revision, I need to switch to trunk >> and hope that XXXX corresponds to one of its revisions. > > Revision numbers refering to the trunk seem to be, until now, the most > common case. Maybe this is because `trunk' is where almost all the work is done and used as a centralized repo where the hackers commit as they progress (instead of using long-lived feature branches.) That is subject to change over time as people gets acquainted with distributed features (or, hopefully, as new hackers join the project.) > And I see that people sometimes uses the branch name as > an adjetive to clarify which one contains the revno: > > Merge from emacs-23 branch, up to r100386. [snip] > Seems pretty clear to me. This is not terribly helpful, as it forces you to clone a number of branches just for reference and jump from one to another, when the mentioned revision may be already merged in your current branch. (Usually I'm interested on seeing the revision in the context of my current work, so I'll have to clone and switch to the other branch, lookup the revision-id there, and use it on my branch for locating the revision.) >> If a series of >> commits on a feature branch mentions one another by revison number, >> after merging them into trunk (or into any other branch) those numbers >> are wrong. > > Isn't that a case of "if it hurts, don't do that"? So we need another rule: if you are working on a branch other than `trunk', use revision ids, else revision numbers. Creppy. >> So, if you wish to refer to another revision on the commit message (or >> anywhere else) please use the revision id, which is unique for every >> commit. > > It's also quite unwieldy. git SHA-1 ids seem a joy by comparison (at > least you can use a prefix of 6-8 characters and be right most of the > time). Yes, bzr's revision ids sucks, but that is no reason for doing the wrong thing. Just in case anyone here has the time and energy, it could be suggested to bzr hackers to implement a SHA-1 revision id in parallel of the currrent monster. Sequential numbering is just wrong on a distributed VCS.