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: Release tags Date: Wed, 05 Sep 2012 14:11:47 +0900 Message-ID: <871uiht5nw.fsf@uwakimon.sk.tsukuba.ac.jp> References: <04A8931A-A044-4F8A-86FD-7AA70DA2B5E3@mit.edu> <87d32awhc7.fsf@gnu.org> <87wr0aldw0.fsf@gmail.com> <83pq62ec1i.fsf@gnu.org> <87fw6x505b.fsf@gnu.org> <87mx15lr1k.fsf@wanadoo.es> <87y5kpydsr.fsf@gnu.org> <87ipbtlk7v.fsf@wanadoo.es> <874nndkxj2.fsf@wanadoo.es> <87392xtbei.fsf@uwakimon.sk.tsukuba.ac.jp> <87zk55jfi3.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1346821918 17752 80.91.229.3 (5 Sep 2012 05:11:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Sep 2012 05:11:58 +0000 (UTC) Cc: Tim Cross , 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 Wed Sep 05 07:11:59 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T97uA-0002Dj-Lm for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 07:11:58 +0200 Original-Received: from localhost ([::1]:52354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T97u7-0001mn-Gi for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 01:11:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T97u4-0001md-4D for emacs-devel@gnu.org; Wed, 05 Sep 2012 01:11:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T97u2-0005CY-Vh for emacs-devel@gnu.org; Wed, 05 Sep 2012 01:11:52 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:46001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T97u2-00057w-Eq for emacs-devel@gnu.org; Wed, 05 Sep 2012 01:11:50 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id CF2A0970885; Wed, 5 Sep 2012 14:11:47 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 861411A32DC; Wed, 5 Sep 2012 14:11:47 +0900 (JST) In-Reply-To: <87zk55jfi3.fsf@wanadoo.es> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153035 Archived-At: =C3=93scar Fuentes writes: > No, he says that he has an up-to-date checkout of `trunk', which > necessarily contains the revision tagged as `emacs-24.2', because it was > merged into `trunk' almost 2 weeks ago. He also mentions that he knows > the revision number of the merge. His problem is that the tag (not the > revision) is missing from his private repo. Unless he's done something that someone as bzr-averse as he seems to be would be very unlikely to do (namely, "bzr tag --delete emacs-24.2"), that's not his problem, that's a bzr bug. Tags should be copied. If that tag actually was on trunk at the time of the OP, my bet is that for some reason his checkout wasn't actually up-to-date. Both user error and common bzr bugs can account for that situation easily, so I prefer that assumption. > Dealing with multiple branches on bzr is a bit of an inconvenience, for > several reasons. One of them is mentioned by the OP: you end having > multiple working copies around, or having to learn and remember tricks > for reusing the same working copy. They're not tricks, they're standard bzr workflow for anybody needing to use branches, which is pretty much everybody following trunk. It's not that hard to learn to use "bzr switch" in a lightweight checkout. Granted that that's suboptimal (at least to drinkers of git-flavored Kool-Aid), I'm still curious why he considers lightweight checkouts unacceptable (if he does). One good alternative for him (as you mentioned earlier) would be to tag his private copy every time he gets a usable build. I expect that would pollute upstream if he ever pushed, though.