Equivalent to svn tags?

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I would first point you to:

http://bazaar-vcs.org/SharedRepositoryLayouts

Which describes ways that you can lay out your Bazaar branches in a shared
repository.

But for what you are asking for, there are 2 things I would do.

1) Create a local shared repository, since you'll have a few branches, and you
don't want a complete copy of history for each one.

bzr init-repo --trees project

2) If you want, create a "in-progress" location that you then create branches
from. If you already have your stuff in Bazaar, it is:

bzr branch ORIGINAL project/trunk

3) When you get close to a release, you can create a separate branch for it if
you want

cd project
bzr branch trunk branch-0.3.0

4) If you are doing development solely for the 0.3.0 release, do it in
"branch-0.3.0", (such as setting the version properties, etc.) If you are doing
general development, you can do it in 'trunk'. Though you are free to merge
back and forth between branch-0.3.0 and trunk.

5) When you make an official release of the code, I would

cd branch-0.3.0
bzr commit -m "Releasing 0.3.0"
bzr tag release-0.3.0

You could either use --unchanged, or this could be a change with the last
cleanups for the release

cd trunk
bzr merge ../branch-0.3.0
# Revert any 0.3.0 specific changes, like the version properties
bzr commit -m "Merging branch-0.3.0 into trunk"

This will also pull in the 'release-0.3.0' tag into the 'trunk' branch.

This means that when you do:
cd trunk
bzr log

You can see "tags: release-0.3.0" on the official revision that you released.
And it means that doing

bzr branch http://matthews/project/trunk -r tag:release-0.3.0 release-0.3.0

will always give me the official release of your project.


At least, that is how I would do it.

John
=:->


Matthew Tylee Atkinson wrote:
> 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,
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHHo1yJdeBCYSNAAMRAnbeAKCWG/Pr4I9ko4r4Ef+TY8TpvxMJGACfcqHu
t2Vrv+aFYTyYVB9ByzD+zjc=
=lPLr
-----END PGP SIGNATURE-----