Re: Release tags

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

Tim Cross writes:

[Please trim irrelevant stuff you didn't write.]

 > I cannot see any emacs-24.2 tag in the main trunk. I suspect (but
 > don't know for sure) that this is because the tag was not made in the
 > emacs-24 branch before it was merged back into trunk.

Right.  What could and IMO should be done (ie, I do it when I'm RM :-)
is to tag the branch point.  That is the last "known good" point on
the trunk (given the Emacs release process).

 > Obviously, I could just check out the emacs-24 branch. However, I was
 > hoping to avoid having to either switch branches

Why?  You're doing essentially the same thing anyway if you check out
a tag.  It's not a branch switch, but you've got the wrong code base
for making changes to.  ("Wrong" in the sense that you run a risk of
unnecessary conflicts when merging your changes.)

I'll grant that the bzr implementation of this gives me hives, but
from the user point of view a shared repo (efficient storage of
revisions common to the branches of interest) plus a lightweight
checkout gives you the same effect as colocated branches for this
purpose, at the slight cost of setting up a shared repo and learning
an extra command IIRC.

 > An earlier post in this thread identifies the revision number where
 > the emacs-24.2 version was merged back into the dev trunk, so I can
 > achieve what I want using that revision number.

No, you can't, if "known good revision" is what you want.  Any
instability introduced *in the trunk* since emacs-24.2 branched from
the trunk is still in the trunk.  You do not get a "known good"
revision.  You only get fixes to emacs-24.2 since the branch, but
these should be pretty small, and won't address "new" instability.

Steve