Equivalent to svn tags?

Matthew Tylee Atkinson mta at agrip.org.uk
Wed Oct 24 00:11:08 BST 2007


I'm new to bzr -- having just taken the plunge and tried it out because
I've registered a project on Launchpad.  I found the bzr-svn plugin so
friendly to the way we work at the moment that I thought I should really
take a serious look at using bzr for the whole thing (I mean, if DRCS is
really this easy, maybe it's worth migrating to :-)).

I have a question, to which I /think/ I know the answer.  However, as I
am new to DRCS in general and bzr specifically, I thought I should
present the question and my reasoning as to the answer so that you could
let me know if it is the type of workflow that is intended with systems
like bzr.

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.

In fact, that probably means that I should simply start a 0.3 branch and
make point releases simply by copying the 0.3 branch into a 0.3.x
tarball at times when development on that branch is stable.  If that
were the case, though, I think that it would be harder to register
definitive releases on Launchpad (like 0.3.5) and track down bugs.  So,
maybe I should still make branches with names like 0.3, then 0.3.x, and
then just end up with a lot of branches lying around over time (so when
0.3.5 is released, 0.3.[0-4] would just be left dormant).

Does this sound like a sane workflow to you?  It sounds fairly logical
to me and, I expect, gives the advantage that others can choose more
precisely which release or series they wish to target their work at.  I
gather from the docs that it's possible that if many desirable
improvements are made in the 0.3->0.3.0->0.3.x series these can be
merged back to the trunk with perhaps only a little work.

I was concerned at the apparently complexity of DRCS systems but bzr
seems to ``just work'' as it claims and I'm really looking forward to
using it more in the future -- thanks to the devs!

best regards,


-- 
Matthew Tylee Atkinson <mta at agrip.org.uk>



More information about the bazaar mailing list