From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Please don't use revision numbers on commit messages (and elsewhere). Date: Fri, 1 Apr 2011 02:28:45 +0200 Message-ID: References: <877hbfvwyo.fsf@wanadoo.es> <87tyeivni1.fsf@wanadoo.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1301617786 22017 80.91.229.12 (1 Apr 2011 00:29:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2011 00:29:46 +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 Fri Apr 01 02:29:42 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 1Q5SF8-0006tC-7S for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2011 02:29:42 +0200 Original-Received: from localhost ([127.0.0.1]:37093 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5SF4-0004eT-CR for ged-emacs-devel@m.gmane.org; Thu, 31 Mar 2011 20:29:34 -0400 Original-Received: from [140.186.70.92] (port=46130 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5SEz-0004eK-OR for emacs-devel@gnu.org; Thu, 31 Mar 2011 20:29:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5SEw-0003xe-1K for emacs-devel@gnu.org; Thu, 31 Mar 2011 20:29:27 -0400 Original-Received: from mail-gy0-f169.google.com ([209.85.160.169]:62036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5SEv-0003xZ-T6 for emacs-devel@gnu.org; Thu, 31 Mar 2011 20:29:26 -0400 Original-Received: by gyd8 with SMTP id 8so1455514gyd.0 for ; Thu, 31 Mar 2011 17:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Jn5gRY5OWqciYJewwsqNNYiTXt0Jj+tfPRe6tt+PHCY=; b=bJrQiVAqaf+Rd6SBHqjGJ2sDqSP6IoUFvYm0pSFOvxXsUNhbZIZt2kdLOIF/H/Hdfr 6QzzbzxnKGcsIwBcf/MKBK4sp550uxTWxVbyqqUZoQ6/Ku/7fCbP6yNMNIGIIeAm6olb BVBWvBEqpTdqWm+cjA5W+5KdkThia1hUoXzqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=bLWClAtSjcITxkuJ3Do/fkvt20sY3mMcMeDsJ+aoGUob/V1bjbB68o3W8r+XtrVnw5 9WherSJmFooTdkDZq0VxmbuPeFriTSFKKKQQlshhHgYAF7dVrSnE7ufpcf3vOtyeHHz0 v6LFvIO6c/pmJxmAa0n0FKj32pTQcVUlC10hQ= Original-Received: by 10.236.28.129 with SMTP id g1mr2795694yha.84.1301617765138; Thu, 31 Mar 2011 17:29:25 -0700 (PDT) Original-Received: by 10.147.182.17 with HTTP; Thu, 31 Mar 2011 17:28:45 -0700 (PDT) In-Reply-To: <87tyeivni1.fsf@wanadoo.es> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.160.169 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:137962 Archived-At: On Fri, Apr 1, 2011 at 02:11, =C3=93scar Fuentes wrote: > 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. Yes, and I'm saying that, so far, it seems quite clear from the context which branch a revno refers to. > Across *any* branches, > including the "random" ones (whatever your definition of "random branch" > is.) My comment about "random branches" is an answer to your "(and this only after setting some options, as Emacs did.)". We're developing Emacs; it's irrelevant whether other projects do or do not set these options. > 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.) I don't foresee that super-distributed future that you imagine for Emacs. And if it does come to pass, it's everyone's responsibility to clearly label their revnos. After all, if you have a branch cloned from trunk, and you do development on it, and you do refer to revids in the changelogs, these revids won't be meaningful for the trunk's users either unless the branch is merged to the trunk. If you just send a patch, revids will be as meaningless as revnos would be. > 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. The Emacs project does not usually maintain a large number of active branches. And, with a shared repo, "cloning a number of branches" isn't that problematic, space- or time-wise. > (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.) It's hard to envision you cloning emacs-23 to locate a revision, then removing it from the disk, then cloning it again to locate the next revision... Also, that example is currently quite artificial, because they aren't that many revnos in the ChangeLogs right now (I know, I checked the logs) and they overwhelming refer to the trunk. So you're describing a future, hypothetical problem. > So we need another rule: if you are working on a branch other than > `trunk', use revision ids, else revision numbers. Creppy. No. Use always revision numbers and trust the users to be smart. > Yes, bzr's revision ids sucks, but that is no reason for doing the wrong > thing. Neither it is an incentive to do the "right thing". =C2=A0 =C2=A0 Juanma