I see that Mercurial and Kiln support tags and I've heard that they can be used to correspond to various builds or versions of my software. How does that work and why is it useful?
|
2
|
|
|
|
|
2
|
This example will show how you can use tags within your repository to know what changesets are included in a specific version of the software. We'll explore how tags look within Kiln as well as how they can be useful when identifying whether bug fixes are included within a specific release. Let's say you've been working on your application and you're getting ready to ship. You've implemented a code freeze and want to indicate in some way that this is "version 1.0.0" of your product. Here's what your repository currently looks like:
We want to tag the changeset that contains the commit message "hello world" so that version 1.0.0 is associated with this changeset:
Now when we look at the repository DAG in Kiln, we'll see the version tag, "Frogger-1.0.0" next to the "hello world" changeset. This means that anything in the DAG up to the Frogger-1.0.0 tag, is included in version 1.0.0 of the software. In Kiln, linear changesets below the Frogger-1.0.0 tag are included in version 1.0.0, but no changesets above the tag are included. (Note that adding the tag is itself a changeset that's not included in the tag. Because this changeset isn't a functional change, it's not really an issue).
Why is this useful? Great question! You get an email from a customer reporting a bug:
We fix the bug, indicate the case number in the commit message, and push to Kiln. Now our repository DAG looks like this:
When we look at the case in FogBugz, because we indicated the case number in our commit message, the changeset will show up. It also lets us know what tags our changeset is. Right now, our changeset is only in tip. Since it's not in a named tag, we know that it's not available to the customer yet.
Time goes by and you are ready to release a new version of the software. You tag your latest changeset 1.1.0 and now your DAG looks like the following. Note that the bug fix you made for case 147 is now included in the tag "Frogger-1.1.0":
Our customer emails us back and wants to know if his bug has been fixed. Because we've been using tags in our repository that match our version, I can look at the changeset that's linked within the bug and see what tags it's included in. In the image below, I can see the changeset that has the fix is included in tag Frogger-1.1.0. This corresponds to version 1.1.0 of the app, so I can feel confident in letting the customer know that their bug has been fixed.
Hopefully this gives you an idea of how tags can be used to tie your code base with specific versions of the software. |
|||
|
|
