Re: Release tags

[Tim Cross <theophilusx@gmail.com>]

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