Up until recently, Subversion has been my SCM tool of choice and I have used it on almost all projects. However like many other people, I have been drawn to using Git. There are plenty of good articles available describing the benefits Git can bring (Nick Quaranto provides a nice summary of Git tutorials and articles) and as such I will not repeat them all here. However in my case, the move to Git has bought up a question relating to version numbering of applications.

My previous SVN-based development/deployment workflow worked in the following way:

1. Development of features/bug fixes, commit to SVN repo
2. Deploy script via Fabric script (see my previous post on Fabric for more details):
   1. Export current trunk to production server
   2. Set up production config/environment
   3. Calculate version number for new the release:
      1. Get current SVN revision number
      2. Append to manually defined major and minor versions (e.g. 1.2.<revision>)
   4. Insert the new version number into the app configuration
   5. Add new tag (copy of the current trunk) to the SVN repo with the new version number (e.g. tags/1.2.567)

Most of this can be translated over to Git without much issue. However, the problem point is the generation of the version number from the revision (the point shown in bold). Since Git uses hashes rather than version numbers, this would result in a version number like 1.2.7b96a4daa37e9ad64f934443038e8aa40114a621. Not at all acceptable. A solution to the length (and inherent non-readableness) to this is available built-in since Git is also able to produce and operate on short (abbreviated) hashes. So the version number above would become 1.2.7b96a4d. Managable. However this still has several problems - being a hash rather than a number, it does not increment - rather it jumps around erratically. This makes it impossible to tell given two version numbers with no major/minor increments which is the newer. However it does once again tie a given version to a point within the repository history - something I find to be quite useful.

At this point I have no good answer to this problem. I don't know if this solution is adequate or whether there is a better way, although if I come up with nothing better I will most likely adopt this solution. Grayson Hansard solves the same problem by counting the number of commits thereby producing a revision number, and Wincent Colaiuta is undecided. However, this seems perhaps a bit of a hack too far and as others have mentioned in the comments, a bit brittle given some situations. I think perhaps I need to give this more thought and any comments (positive, negative or suggestive) would be appreciated.