From: Tim Cross <theophilusx@gmail.com>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: "Óscar Fuentes" <ofv@wanadoo.es>, emacs-devel@gnu.org
Subject: Re: Release tags
Date: Wed, 5 Sep 2012 22:48:13 +1000 [thread overview]
Message-ID: <CAC=50j-mq8JcGaD4dd4oCDZWn=mDX03Dxx8LaW0J746qhm1OZQ@mail.gmail.com> (raw)
In-Reply-To: <871uiht5nw.fsf@uwakimon.sk.tsukuba.ac.jp>
On 5 September 2012 15:11, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Óscar 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.
>
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, 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).
>
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
--
Tim Cross
next prev parent reply other threads:[~2012-09-05 12:48 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-28 16:48 Release tags chad
2012-08-29 2:40 ` Chong Yidong
2012-09-04 0:40 ` Tim Cross
2012-09-04 2:25 ` Óscar Fuentes
2012-09-04 2:29 ` William Stevenson
2012-09-04 2:50 ` Eli Zaretskii
2012-09-04 14:32 ` Jason Rumney
2012-09-04 15:57 ` Óscar Fuentes
2012-09-04 16:04 ` Jason Rumney
2012-09-04 17:47 ` Andreas Schwab
2012-09-05 14:55 ` Jason Rumney
2012-09-05 15:18 ` Andreas Schwab
2012-09-05 15:33 ` Óscar Fuentes
2012-09-07 13:22 ` Jason Rumney
2012-09-07 14:35 ` Eli Zaretskii
2012-09-07 15:27 ` Stefan Monnier
2012-09-04 18:24 ` Óscar Fuentes
2012-09-04 22:43 ` Tim Cross
2012-09-05 1:53 ` Stephen J. Turnbull
2012-09-05 2:34 ` Óscar Fuentes
2012-09-05 3:07 ` Stephen J. Turnbull
2012-09-05 3:49 ` Óscar Fuentes
2012-09-05 5:11 ` Stephen J. Turnbull
2012-09-05 6:34 ` Jambunathan K
2012-09-05 12:48 ` Tim Cross [this message]
2012-09-05 16:25 ` Eli Zaretskii
2012-09-05 16:23 ` Eli Zaretskii
2012-09-05 16:21 ` Eli Zaretskii
2012-09-05 17:32 ` Stephen J. Turnbull
2012-09-05 17:42 ` Eli Zaretskii
2012-09-05 14:32 ` Stefan Monnier
2012-09-04 16:57 ` Eli Zaretskii
2012-09-04 16:53 ` Eli Zaretskii
2012-09-05 7:16 ` Glenn Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC=50j-mq8JcGaD4dd4oCDZWn=mDX03Dxx8LaW0J746qhm1OZQ@mail.gmail.com' \
--to=theophilusx@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=ofv@wanadoo.es \
--cc=stephen@xemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.