Re: Release tags

["Stephen J. Turnbull" <stephen@xemacs.org>]

Ó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.

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.