Release tags

Release tags

[chad]

Is there a tag I can use to identify the 24.2 release codebase?

I see some EMACS_PRETEST_24_xxx tags and emacs-24.1, but nothing
for 24.2.

Thanks,
*Chad

Re: Release tags

[Chong Yidong]

chad <yandros@MIT.EDU> writes:

> Is there a tag I can use to identify the 24.2 release codebase?
>
> I see some EMACS_PRETEST_24_xxx tags and emacs-24.1, but nothing
> for 24.2.

I forgot to make the tag.  It should be there now (emacs-24.2).

Re: Release tags

[Tim Cross]

I cannot see a tag for emacs-24.2. Updated today and see log messages
for commits dated for 3 Sept, so I appear to be up-to-date. CAn see
tag for emacs-24.1, but nothing for emacs 24.2. Is this in another
branch?

Tim

On 29 August 2012 12:40, Chong Yidong <cyd@gnu.org> wrote:
> chad <yandros@MIT.EDU> writes:
>
>> Is there a tag I can use to identify the 24.2 release codebase?
>>
>> I see some EMACS_PRETEST_24_xxx tags and emacs-24.1, but nothing
>> for 24.2.
>
> I forgot to make the tag.  It should be there now (emacs-24.2).
>



-- 
Tim Cross

Re: Release tags

[Óscar Fuentes]

[text reordered for clarity; please don't top-post]

> On 29 August 2012 12:40, Chong Yidong <cyd@gnu.org> wrote:
>> I forgot to make the tag.  It should be there now (emacs-24.2).

Tim Cross <theophilusx@gmail.com> writes:

> I cannot see a tag for emacs-24.2. Updated today and see log messages
> for commits dated for 3 Sept, so I appear to be up-to-date. CAn see
> tag for emacs-24.1, but nothing for emacs 24.2. Is this in another
> branch?

I see the tag on the git mirror repo, so it must be on the bzr repo as
well.

Re: Release tags

[William Stevenson]

Tim Cross <theophilusx@gmail.com> writes:

> I cannot see a tag for emacs-24.2. Updated today and see log messages
> for commits dated for 3 Sept, so I appear to be up-to-date. CAn see
> tag for emacs-24.1, but nothing for emacs 24.2. Is this in another
> branch?

I see one in branch emacs-24:
emacs-24.2           108121

Re: Release tags

[Eli Zaretskii]

> From: William Stevenson <yhvh2000@gmail.com>
> Date: Tue, 04 Sep 2012 03:29:03 +0100
> 
> Tim Cross <theophilusx@gmail.com> writes:
> 
> > I cannot see a tag for emacs-24.2. Updated today and see log messages
> > for commits dated for 3 Sept, so I appear to be up-to-date. CAn see
> > tag for emacs-24.1, but nothing for emacs 24.2. Is this in another
> > branch?
> 
> I see one in branch emacs-24:
> emacs-24.2           108121

It should have been on the trunk as well, though, because:

  109804: Glenn Morris 2012-08-28 [merge] Merge from emacs-24; up to r108124

Or maybe this will land upon the next merge from emacs-24.

Re: Release tags

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> It should have been on the trunk as well, though, because:
>
>   109804: Glenn Morris 2012-08-28 [merge] Merge from emacs-24; up to r108124
>
> Or maybe this will land upon the next merge from emacs-24.

Tags are pulled in by a merge from another branch in bzr?  Seems
like a confusing misfeature to me if true.

Re: Release tags

[Óscar Fuentes]

Jason Rumney <jasonr@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> It should have been on the trunk as well, though, because:
>>
>>   109804: Glenn Morris 2012-08-28 [merge] Merge from emacs-24; up to r108124
>>
>> Or maybe this will land upon the next merge from emacs-24.
>
> Tags are pulled in by a merge from another branch in bzr?  Seems
> like a confusing misfeature to me if true.

A tag is associated to a revision (actually, it is a name you give to a
revision.) A revision can enter the history of any branch (via merge),
therefore its associated tag(s) will appear on the logs of those
branches.

Re: Release tags

[Jason Rumney]

Óscar Fuentes <ofv@wanadoo.es> writes:

> A tag is associated to a revision (actually, it is a name you give to a
> revision.) A revision can enter the history of any branch (via merge),
> therefore its associated tag(s) will appear on the logs of those
> branches.

No use of a tag that I have ever seen was for a revision. It was for the
state of the source tree at that point in time. Release tags especially.

If there are multiple Emacs 24.2 tags in the repository, how is one
supposed to know which is the real Emacs 24.2?

Re: Release tags

[Andreas Schwab]

Jason Rumney <jasonr@gnu.org> writes:

> No use of a tag that I have ever seen was for a revision. It was for the
> state of the source tree at that point in time.

A revision _is_ a state of the tree at one point in time.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Release tags

[Jason Rumney]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> No use of a tag that I have ever seen was for a revision. It was for the
>> state of the source tree at that point in time.
>
> A revision _is_ a state of the tree at one point in time.

Except when you merge that revision onto another branch, some here
seemed to be saying the tag would be merged with it, which makes no
sense to me, because after the merge what gets checked in should be a
different revision (even though the patch from the previous revision to
the new one is the same between branches, the content of the tree is
different).

Re: Release tags

[Andreas Schwab]

Jason Rumney <jasonr@gnu.org> writes:

> Except when you merge that revision onto another branch, some here
> seemed to be saying the tag would be merged with it, which makes no
> sense to me, because after the merge what gets checked in should be a
> different revision

No, the merged revisions don't change.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Release tags

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> Except when you merge that revision onto another branch, some here
>> seemed to be saying the tag would be merged with it, which makes no
>> sense to me, because after the merge what gets checked in should be a
>> different revision
>
> No, the merged revisions don't change.

Jason, try executing `bzr qlog' from your trunk branch checkout and
click on the small circles that contains a + symbol (those are merge
revisions.) You will see that a merge revision joins a series of
revisions from the original branch (trunk, in this case) with a series
of revisions coming from another branch. All revisions are there.

Re: Release tags

[Jason Rumney]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Jason, try executing `bzr qlog' from your trunk branch checkout and
> click on the small circles that contains a + symbol (those are merge
> revisions.) You will see that a merge revision joins a series of
> revisions from the original branch (trunk, in this case) with a series
> of revisions coming from another branch. All revisions are there.

bzr: ERROR: unknown command "qlog"

I think what you are trying to explain is that bzr's history is
full of confusing non-linear parallel universes.  24.2 never existed on
the trunk as far as history of this universe goes - it was made on a
branch.  But DVCS adherents want the possibility of an alternate
universe where 24.2 is on the history of the trunk. The benefit of this
non-linearity is not at all clear to me.

Re: Release tags

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: Fri, 07 Sep 2012 21:22:26 +0800
> Cc: Andreas Schwab <schwab@linux-m68k.org>, emacs-devel@gnu.org
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > Jason, try executing `bzr qlog' from your trunk branch checkout and
> > click on the small circles that contains a + symbol (those are merge
> > revisions.) You will see that a merge revision joins a series of
> > revisions from the original branch (trunk, in this case) with a series
> > of revisions coming from another branch. All revisions are there.
> 
> bzr: ERROR: unknown command "qlog"

You most probably don't have the Qbzr plugin installed.

> 24.2 never existed on the trunk as far as history of this universe
> goes - it was made on a branch.

I think you are mixing the tree and the version meta-data.  All the
versions on the branch "exist" on the trunk as well, in the sense that
their history is in the trunk meta-data, and, if one wants, one can
make the working tree of the trunk to be exactly as one of the branch
revisions.

Re: Release tags

[Stefan Monnier]

> branch.  But DVCS adherents want the possibility of an alternate
> universe where 24.2 is on the history of the trunk. The benefit of this

I think there's just a simple misunderstanding of what tags are.
Bazaar's tags are just mapping from names to revids.  They're stored in
a branch because that seemed like a good idea.  Bzr propagates it
between branches whenever it gets a chance, pretty much.  So the tags in
a branch can refer to revids in different branches, some of which may
have nothing to do whatsoever with the current branch.  There can also
be a tag that points to a revid that doesn't exist, or that existed but
has been retracted, ...

I think Bzr's tags were not very well though out (e.g. you can't remove
a tag, because of how Bzr likes to eagerly and blindly spread them,
which causes them to come right back unless you remove them from
everywhere at the same time).  But the important point is that they do
not say anything reliable about the history of the current branch on
which you find them.


        Stefan

Re: Release tags

[Óscar Fuentes]

Jason Rumney <jasonr@gnu.org> writes:

> No use of a tag that I have ever seen was for a revision. It was for the
> state of the source tree at that point in time. Release tags especially.
>
> If there are multiple Emacs 24.2 tags in the repository, how is one
> supposed to know which is the real Emacs 24.2?

Any of them will do, because the revision (and hence the tag) determines
the complete state of the source tree.

Plus the complete VC history that precedes that revision. So if the
emacs-24 branch were magically lost, it could be partially recovered (VC
history included) from any other branch that contains a merged revision
that comes from emacs-24. (Partially means "except the revisions
committed after the emacs-24 revision you have at hand.")

Re: Release tags

[Tim Cross]

On 5 September 2012 04:24, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>
>> No use of a tag that I have ever seen was for a revision. It was for the
>> state of the source tree at that point in time. Release tags especially.
>>
>> If there are multiple Emacs 24.2 tags in the repository, how is one
>> supposed to know which is the real Emacs 24.2?
>
> Any of them will do, because the revision (and hence the tag) determines
> the complete state of the source tree.
>
> Plus the complete VC history that precedes that revision. So if the
> emacs-24 branch were magically lost, it could be partially recovered (VC
> history included) from any other branch that contains a merged revision
> that comes from emacs-24. (Partially means "except the revisions
> committed after the emacs-24 revision you have at hand.")
>
>

Just to clarify and get things back on track.

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. I suspect that
the next merge from the emacs-24 branch will bring the tag into trunk.
I don't see any problem with that.

The reason I wanted the tag is that most of the time I run off the
head of the main trunk. However, sometimes, if the trunk has some
instabiity which is causing me problems, it is useful to have a known
'good state' in the trunk which allows me to check it out in a
convenient way. The tag provides that convenience - I don't have to
look back through the revisions to work out which difficult to
remember revison number corresponds to the last stable release version

Obviously, I could just check out the emacs-24 branch. However, I was
hoping to avoid having to either switch branches or have two separate
working trees - I find it more convenient to just maintain one tree.

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. The tag is a
convenience, but not essential.

Tim


-- 
Tim Cross

Re: Release tags

[Stephen J. Turnbull]

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

Re: Release tags

[Óscar Fuentes]

Tim Cross <theophilusx@gmail.com> writes:

[snip]

> 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. The tag is a
> convenience, but not essential.

If you know the revision that corresponds to the emacs-24.2 tag
upstream, why don't you tag your private branch yourself?

You can create tags in your private checkouts as you please, although I
would not use a name that you know exists elsewhere, just in case.

BTW, in this case you are not interested on the merge revision that
incorporated the emacs-24 VC history intro `trunk', but on the revision
that comes from the emacs-24 branch and was tagged as `emacs-24.2'.

Re: Release tags

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > If you know the revision that corresponds to the emacs-24.2 tag
 > upstream, why don't you tag your private branch yourself?

Because he doesn't have that revision to tag.  If he did, he'd have
the tag, too.  So he would need to branch emacs-24.2, and he doesn't
want to do that (I'm not sure why, so I asked, we'll see what he
says).

Re: Release tags

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Óscar Fuentes writes:
>
>  > If you know the revision that corresponds to the emacs-24.2 tag
>  > upstream, why don't you tag your private branch yourself?
>
> Because he doesn't have that revision to tag.  If he did, he'd have
> the tag, too.

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.

>  So he would need to branch emacs-24.2, and he doesn't
> want to do that (I'm not sure why, so I asked, we'll see what he
> says).

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. As the OP plans to use the emacs-24.2
stable point only in the rare cases when `trunk' is in a unusable state,
his reluctance is understandable.

Re: Release tags

[Stephen J. Turnbull]

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

Re: Release tags

[Jambunathan K]

I am not sure whether the OP is using git repo of Emacs.

I remember using

    git fetch --tags origin

to refresh tags.  Cannot recollect the exact scenario when I had to do
this.

,---- From git help fetch
|  -t, --tags
|      Most of the tags are fetched automatically as branch heads are
|      downloaded, but tags that do not point at objects reachable from
|      the branch heads that are being tracked will not be fetched by this
|      mechanism. This flag lets all tags and their associated objects be
|      downloaded. The default behavior for a remote may be specified with
|      the remote.<name>.tagopt setting. See git-config(1).
`----

Just guessing here. 
-- 

Re: Release tags

[Tim Cross]

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

Re: Release tags

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 05 Sep 2012 14:11:47 +0900
> Cc: Tim Cross <theophilusx@gmail.com>, emacs-devel@gnu.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.

"bzr tag --delete" will remove the tag only until the next "bzr up",
because the tag will be merged again at that time.

Re: Release tags

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 05 Sep 2012 05:49:24 +0200
> Cc: Tim Cross <theophilusx@gmail.com>, emacs-devel@gnu.org
> 
> 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.

With bzr 2.5, you _can_ use co-located branches.  But I won't
recommend that with Emacs, because the branch and the trunk diverged
so much at this point that you'd need a full bootstrap every time you
switch.  Which just about eliminates the advantage of co-located
branches.

Re: Release tags

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 05 Sep 2012 12:07:49 +0900
> Cc: Tim Cross <theophilusx@gmail.com>, emacs-devel@gnu.org
> 
> Óscar Fuentes writes:
> 
>  > If you know the revision that corresponds to the emacs-24.2 tag
>  > upstream, why don't you tag your private branch yourself?
> 
> Because he doesn't have that revision to tag.  If he did, he'd have
> the tag, too.

Not true: the revision was merged to the trunk before the tag was set
on the branch.  So he does have the revision, but not the tag (or,
rather, he did, since Glenn just merged again, and the tag landed on
the trunk).

Re: Release tags

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Not true: the revision was merged to the trunk before the tag was set
 > on the branch.

Oh.  That shouldn't happen ....

Re: Release tags

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: ofv@wanadoo.es,
>     theophilusx@gmail.com,
>     emacs-devel@gnu.org
> Date: Thu, 06 Sep 2012 02:32:48 +0900
> 
> Eli Zaretskii writes:
> 
>  > Not true: the revision was merged to the trunk before the tag was set
>  > on the branch.
> 
> Oh.  That shouldn't happen ....

Evidently, it does.  Probably related to how tags are implemented in
bzr.

Re: Release tags

[Stefan Monnier]

> If you know the revision that corresponds to the emacs-24.2 tag
> upstream, why don't you tag your private branch yourself?

Here's an easier recipe:

   bzr merge .../emacs-24
   bzr revert

that should bring in all the tags from the emacs-24 branch, just like th
next merge from emacs-24 will, but without you having to deal with
resolving the conflicts.


        Stefan

Re: Release tags

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 04 Sep 2012 17:57:11 +0200
> 
> >> Or maybe this will land upon the next merge from emacs-24.
> >
> > Tags are pulled in by a merge from another branch in bzr?  Seems
> > like a confusing misfeature to me if true.
> 
> A tag is associated to a revision (actually, it is a name you give to a
> revision.) A revision can enter the history of any branch (via merge),
> therefore its associated tag(s) will appear on the logs of those
> branches.

And citing from bzr docs (assuming you believe them ;-):

  Tags give human-meaningful names to revisions. Commands that take a
  -r (–revision) option can be given -rtag:X, where X is any
  previously created tag.

  Tags are stored in the branch. Tags are copied from one branch to
  another along when you branch, push, pull or merge.

Re: Release tags

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Cc: William Stevenson <yhvh2000@gmail.com>,  emacs-devel@gnu.org
> Date: Tue, 04 Sep 2012 22:32:32 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It should have been on the trunk as well, though, because:
> >
> >   109804: Glenn Morris 2012-08-28 [merge] Merge from emacs-24; up to r108124
> >
> > Or maybe this will land upon the next merge from emacs-24.
> 
> Tags are pulled in by a merge from another branch in bzr?

I assumed so, but the truth is I don't know.  I just see that the tag
for 24.1 is present in both the branch and the trunk, so I assumed it
got to the trunk via a merge.

Re: Release tags

[Glenn Morris]

Eli Zaretskii wrote:

> Or maybe this will land upon the next merge from emacs-24.

Right. I merged it just now in an effort to curtail all this speculation.

bzr tags | grep -F 24.2
emacs-24.2           107781.1.340