BarneyBlog

A while back, I posted an entry about using Subversion and just got a comment on it a day or two ago with a question about tags.  Tags are absolutely essential in CVS, but in Subversion, they're a bit less required.  Still very useful, however.

In a nutshell, a tag is a named handle on a given set of files at a given set of revisions.  A tag lets you, at any future time, extract that set of files in one fell swoop.  The typical scenario is doing releases.  When you get ready for a release, you create a tag for the source that is being released.  Then if you ever need to look at the source for that release again, you can easily pull it back out.

With Subversion (unlike CVS),  there isn't a difference between a tag and a branch. A tag is simply a branch that has never been committed to.  A very typical use case is to create a tag when you do a release, and then when you need to make a fix to that release (independant of the main trunk of development), you create a branch at the release tag.  You make your fixes on that branch, and then merge them back into the trunk for inclusion in future releases of the product.

In my previous post, I'd alluded to using a tag and an externals definition together to ensure that inter-project dependancies were managed via Subversion rather than manually.  In that particular case, you create a tag on the dependancy for the version you want to use, and then set up an svn:externals definition in the parent project that points at the tag.  Then everyone that checks out the parent project will be assured of having the same version of the project's dependancies.  Even better, changing the location of the tag in the future will automatically update everyone's working copies next time then run svn update, which makes dependancy upgrades a snap.

And keep in mind, Subversion can handle binary files as well as text files, so I'd highly recommnd storing EVERYTHING in your repository, be it your development tools (Eclipse), external libraries (any JARs or DLLs your app might need), server configuration files (web server, DB server), bootstrap scripts, etc.  Aside from hardware and system software, creating a new environment to run your application shouldn't require anything that's not stored in version control.