Re: Was mysql-5.1.69 re-tagged in bzr?

> 5.1$ bzr tags | grep mysql-5.1.69
> mysql-5.1.69         3997
> mysql-5.1.69-retag   3960
>
> Can someone explain the actual meaning of these two tags? At revno
> 3997, configure.in says 5.1.70, so I assume it is the
> mysql-5.1.69-retag which corresponds to the actual 5.1.69 release
> sources, is it correct?

Yes, mysql-5.1.69-retag is the real tag the release was done from. A
release engineer did a mistake and tagged "latest" not in the releae
branch but in trunk. In effect he set the release tag on a changeset
that is more recent than what was released.

> If yes, was there a particular reason to create a second tag with a
> non-canonical name instead of recreating the first tag at the correct
> location? Would it be possible to get a heads-up on this mailing list
> if such tagging occurs again?

The reason is that while it might sound like a simple change, I have
found it not to be that simple. Bazaar is claimed to handle a move of
a tag as any other changeset and then should handle conflicting tags
during merge.

But in my experience it doesn't work well. The release tags are
propagated to lots of developer branches that then later are merged
back to main. I have frequently got Bazaar warnings that the branch I
work with have two identical tags on different changets.

If someone knows how to handle this in a safe way, it would be great.
Unfortunately I don't.

One solution to this problem would be to have separate branches for
each release on Launchpad and not depend on tags. The best would of
course be if mistakes like this did not happen. But it could happen
again of course.

I let others comment on how to communicate things like this, I don't
know what the best way is,

kent

-- 
Kent Boortz, Release Staff engineer
Oracle, The MySQL Team
Mobile: +46 76 77 69 049

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals