From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Release tags Date: Wed, 5 Sep 2012 22:48:13 +1000 Message-ID: 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> <871uiht5nw.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1346849316 15855 80.91.229.3 (5 Sep 2012 12:48:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Sep 2012 12:48:36 +0000 (UTC) Cc: =?ISO-8859-1?Q?=D3scar_Fuentes?= , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 05 14:48:37 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 1T9F24-0003ey-Du for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 14:48:36 +0200 Original-Received: from localhost ([::1]:55607 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9F20-0003ME-W0 for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 08:48:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55409) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9F1t-0003B1-Q8 for emacs-devel@gnu.org; Wed, 05 Sep 2012 08:48:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9F1k-0005Bv-0Z for emacs-devel@gnu.org; Wed, 05 Sep 2012 08:48:25 -0400 Original-Received: from mail-vc0-f169.google.com ([209.85.220.169]:45572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9F1j-0005Bf-Sj for emacs-devel@gnu.org; Wed, 05 Sep 2012 08:48:15 -0400 Original-Received: by vcbfl13 with SMTP id fl13so843412vcb.0 for ; Wed, 05 Sep 2012 05:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=digtgeJ1FN4WbGfxDfl8o6XqLy8EmNOMhovY9v3nbis=; b=VefKkrZDqr9eiNlsAm7qjnDqI5IYp06cwy9lW3feL88vDLtWSM2z0pl7ogQTc13lNK r2xcA0l1/C5M3PcI4X2jx3gE3uaw6faB+2/H1CeN3JT8q7g4hD/voQizxYLOk0/dwSHW W9BXw62fSbEEdQExUSsFdohylu/dPCir01STGeurADVBIoAjCFbZ4bzTgGN2RI7jGBef EFKwrDCLH7CwZpFf7AL6BFfdlkSwSY4PlCVxJNOYo15E+qVyOvhIN5b4BeJkJtGtCbYf zJ9gtBBTbq5y2GiUTSAUSzz9S+4IFfoqAOTWETFQ7vCEMKQ+CEDlhZf1VMvp/Q0eJ7Ds /5bw== Original-Received: by 10.220.221.18 with SMTP id ia18mr2355984vcb.62.1346849295063; Wed, 05 Sep 2012 05:48:15 -0700 (PDT) Original-Received: by 10.58.170.40 with HTTP; Wed, 5 Sep 2012 05:48:13 -0700 (PDT) In-Reply-To: <871uiht5nw.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.220.169 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:153041 Archived-At: On 5 September 2012 15:11, Stephen J. Turnbull wrote: > =D3scar 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 w= as > > 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. > The emacs-24.2 tag was definetly NOT there and as there were comits in the log with timestamps indicating they had occured on the day I was checking, I assume things were up-to-date. What I am gussing has occured is that the emacs-24.2 tag was not added to the emacs-24 branch *before* the merge into trunk and was added to the 24 branch after the merge. This would mean it would be in the emacs-24 branch but not in trunk. If the tag had been created prior to the merge, then I would expect it would show up in trunk? > 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. > Don't believe I'm doing anything unusual - pretty standard stuff really. > 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, fo= r > > 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). > I find dealing with bzr more effort and somewhat more confusing than any other system I use. I can't explain why and I'm not pushing for a change in what is used for emacs - for whatever reason, I don't find bzr at all intuitive or natural. It is also used by only two projects I deal witih and consequently, does not get enough use for me to remember much more than the basics. I have to constantly go back to the manual to work out how to do something I did only a few weeks back. Unless/until I find more things I'm interested in using based around bzr, this is unlikely to change. > 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. Not a great alterantive unfortunately. I've actually tried that approach a while back. The problem is in deciding when something is stable/good enough to tage as such. Too often I found I'd tagged something as supposedly stable and just a little while later, run into something that cripples usability. I do find tags useful sometimes for other forms of tracking, but not for identifying good stable versions (at least no more useful than using the commit log). After seeing Glenn's message, I updated and the emacs-24.2 tag is now there= . thanks Glenn. I apologise for this causing as much noise and speculation as it did - it wasn't what I expected. Tim --=20 Tim Cross