views:

708

answers:

3

I started using bazaar after a long camping in the svn field. I had previous experience with cvs as well, and I used tags occasionally.

With svn, once you release a version, you perform a svn copy of your trunk into tags, for example svn copy trunk tags/1.2.0 . In bazaar I created the same repository structure, but the absence of a bzr copy option and the presence of bzr tag made me ponder.

The fact is that I find tags either hard to use, or useless. If I use tags, I basically have my trunk as the only directory, and when I reach a milestone, I tag it. I then continue to develop and tag again when a new milestone is reached. This complicates the following tasks:

  • comparing a new version against an old version recursively (with the svn-like approach : diff --brief -r)
  • bugfixing an old version, and create new version with its patchversion increased (with the svn-like approach: svn copy 2.0.0 2.0.1, then add the fix to 2.0.1 and commit it)
  • getting the version you want without having to check it out (if you check out the whole tree in svn-like, you have all the versions and branches, and you do it only once)

As a result, I use the same svn repo structure in bzr, and I perform a physical copy of the trunk every time. This means that I don't see any real use of the bzr tag command in this arrangement. why should I tag the whole repo revision with a version number, if it contains all of them for every revision?

Could anyone please point me out what I am doing wrong in using and understanding tags for a bzr repo?


Edit

So as far as I see the concept is to have different bzr branches (independent branches, coming from the trunk via bzr branch) for each release. It's like svn, just that you don't put the root directory in the repository. I still don't really see any particular reason for tags, apart of the fact that, if you have say foo-1.0.0 foo-1.0.1 foo-2.0.0 foo-2.1.0 trunk

and assuming I always tagged releases before branching, trunk will have tags for all of them, while foo-2.0.0 will have foo-1.0.0 among its tags, but not foo-1.0.1 because that was branched from foo-1.0.0.

I still don't really see the need for having and using tags. My tag is implicit in the directory name I choose for that branch. I am not really interested in a particular release number, I'm just interested that it's into a specific directory.

+6  A: 

Well, basically, you shouldn't try and copy the SVN directory structure. I have no idea why SVN has it that way, but basically tags are just a marker at a point in time in your bzr repository. When you want to diff against a tag, it can be done like

bzr diff -r tag:TAG_NAME

So whenever you're making a release, just tag it and be on your way. Nothing special like moving something to a specific folder or anything.

I'd recommend you to start using separate branches instead of tags for things you'd like to get back to, say the 2.0.x line of your code, so you'd have a branch for 2.0.x and then tags like 2.0.0 and 2.0.1 in it.

Also, check out http://bazaar-vcs.org/Specs/Tagging

mikl
+4  A: 

What are tags in bzr?

Tags are just an easy to remember handle for a particular revision. Rather than attempting to remember [email protected], or revno 19721, you can refer to your tag:

bzr export -r tag:foo-1.0.0.0 release-foo-1.0.0.0.tar.gz trunk/

How might I manage releases in bzr?

It sounds as if you are treating your releases as separate lines of development (aka: branches), so I would recommend tagging your trunk, so you know where you branched from and creating separate release branches:

bzr tag -r 1234 -d trunk/ foo-1.0.0.0 
bzr branch -r 1234 trunk/ release-1.x

When you do your bugfixes for 1.x releases, you do them in the release-1.x branch, tagging each point release:

bzr tag -r 1255 -d release-1.x/ foo-1.0.0.1
bzr export -r tag:foo-1.0.0.1 release-foo-1.0.0.1.tar.gz release-1.x/

Your directory structure might look something like this:

fooproj/
  release-1.x/
  release-2.x/
  trunk/
vezult
Yes, but I see no point in easily remembering a specific revision, if I have no reason to need it. revisions are incremental, but the only particular fact they have is that they are ordered in time. Ordering in release is different, as I can release 2.0.1 well after 3.0.0 is out.
Stefano Borini
Your tags almost look like GUID's. :)
Luke
Yeah, they cold have just been 1.0, 2.0, etc. I got carried away with significant version segments, and I just like using foo whenever I get the chance, so I threw it in. ;o)
vezult
+1  A: 

Tags in svn is more like svn branches. You have described the workflow that mapped well to bzr branches. Tags allows you have one branch with pointers to your releases, so anyone can get exactly released version from trunk:

bzr branch trunk foo-1.0 -r tag:1.0

bialix