This project is read-only.

Scenario 1 - Automatic Revision Number

The Problem

All the .Net assemblies have an AssemblyVersion and an AssemblyFileVersion that are composed of 2 to 4 digits that represents - by convention - the major, minor, build and revision components of a Version identifier. 1

The build and revision numbers can be auto generated by using the special notation "1.0.*" but in this case the generated numbers are not related to the used source control and to a real revision number. A common way to resolve this issue is to generate the assembly revision information during the build process based on the current revision number of the source control.

In Mercurial, each changeset has a unique identifier based on SHA-1 (the Changeset ID) and not on an incremented numeric value as it could be with Team Foundation or Subversion. This is because Mercurial is a Distributed revision controland with this kind of source control there is no way to share unique and incremented numeric identifiers between all the users. 2 3

The Requirements

  • There is a unique and central Mercurial repository
  • The build process is managed by a computer synchronized directly with the central repository.

In fact, the "standard" development environments comply with those requirements.

Enterprise context Simple OS project Classic project
company.png opensource.png classic.png
A special server is dedicated to build. This server is synchronized with the central repository. The creator is generally responsible of the final signing & release process. One project = One developer, remind you something ? :)


Note: in the case of a "Simple OS project", to comply with the second requirement, the "Creator" should have a special "release" folder that not use for development and that is directly linked to the central repository.

The Scenario

Mercurial provides for each changet a revision number that is not unique for a developer but that is unique on the central repository. As a result, if the workspace used for the build is synchronized with the central repository without being used for development, the revision number of the workspace will be the same than the central repository and there is no risk of collision between two releases. 2

The scenario will be to update the build process of a project to:
  • Provide a property with the base version (the first three components)
  • Retrieve the revision number from the workspace of the project
  • Compute the Version of the project
  • Generate a code source file with both AssemblyVersion and AssemblyFileVersion attributes initialized

The Objectives

  • Create a MSBuild task that provides the revision number of a Mercurial workspace.
  • Create a MSBuild project that demonstrates this scenario.

External sources

[1] MSDN - System.Version class http://msdn.microsoft.com/en-us/library/system.version.aspx
A detailled explanation on the four components of the revision number

[2] Wikipedia - Distributed revision control http://en.wikipedia.org/wiki/Distributed_revision_control
What is the concept under the Mercurial Source Control

[3] Mercurial - Understanding Mercurial http://mercurial.selenic.com/wiki/UnderstandingMercurial
Details about the Changeset ID and revision number in Mercurial.

Last edited Feb 9, 2010 at 7:58 PM by Faz, version 9

Comments

No comments yet.