Equivalent to svn tags?

Jamu Kakar jkakar at kakar.ca
Wed Oct 24 01:08:05 BST 2007


Hi Matthew,

Matthew Tylee Atkinson wrote:
 > My (current ;-)) question is this: what is the equivalent of svn tags in
 > bzr?  I gather that one would make a new branch when a release series is
 > started (say 0.3.0, branched from trunk) and then develop on that to
 > make, for example, 0.3.1, 0.3.2 and so on.
 >
 > However, using this approach would mean that commits to 0.3.0 before it
 > becomes 0.3.1 would cause the 0.3.0 branch to eventually contain some
 > code that was not included in the actual 0.3.0 release.  I'd really like
 > to make tags that preserve a record of releases for prosperity; not just
 > allow us to make new lines of development.  I suppose the answer to that
 > is that I should really make a tarball of the 0.3.0 branch at the moment
 > it is started, to keep /that/ as the copy for posterity and then
 > continue developing the branch and branch 0.3.1 (taking a copy tarball
 > of that, too) as and when required.

It's actually easier than this because of Bazaar's smart merging
behaviour.  Here's what we do on a project I work on:

We have a trunk branch which represents the most current stable
version of the code.  When it's time to implement a feature, let's say
"Bug #123: We need a login page", I create a branch for that feature:

bzr branch trunk login-ui

I work in the login-ui branch until I'm satisfied that my changes
satisfy the needs of the feature.  At this point I notify my
colleagues that I have this branch which fixes bug #123.  They review
it, I make the requested changes, and when everyone is happy I merge
it to trunk.  This is how trunk is "stable"; only complete chunks of
work land in trunk.  All the intermediate work before the feature is
ready happens in the branch.

Now, let's say we've got a few features landed in trunk and it's time
to do a release, say 0.3.0 to use your example.  I could create an
0.3.0 branch, but doing so would result in quite a few branches after
I've made a number of releases, which I would prefer to avoid having
to maintain.  Instead of having a release-specific branch we have a
branch called "production".  So, making a release is basically:

cd production
bzr merge ../trunk
./test
bzr commit -m "Merged trunk."
bzr tag 0.3.0

Now the production branch has a tag that represents the revision for
0.3.0.  Someone then comes along and reports bug #124.  Despite being
careful with tests and review, a bug has slipped through in my
login-ui branch.  The fix is easy and I want to get it out ASAP.  At
this point I:

bzr branch production login-ui-fix

I then implement the fix in login-ui-fix, get it reviewed, and when
everyone is happy I merge login-ui-fix into the production branch:

cd production
bzr merge ../login-ui-fix
./test
bzr commit -m "Merged login-ui-fix (#124)."
bzr tag 0.3.1

Great, now the fix has been landed in the production branch and
whatever deployment process is required can be performed to get it out
to my users.  I want to make sure my production and trunk branches
don't diverge.  At this point I:

cd trunk
bzr merge ../production
./test
bzr commit -m "Merged production."

Now the fix is in trunk and everyone is happy.  In practice we also
have a staging branch that we merge trunk to sometime before merging
staging to production, but the basic process is the same.  I guess
this doesn't really answer your question about how to work with
release series in Launchpad.  I don't really know the answer to that,
but hopefully someone else will.

Hope this helps,
J.



More information about the bazaar mailing list