The appearance of distributed version control systems (DVCS) (e.g., Git, Mercurial) has introduced the need for non-numeric change number fields. These systems have a good reason for moving away from the otherwise universally accepted idea that "change numbers" are integers - lacking a central repository to assign the numbers, they have to assign something else that is unique (or at least probabilistically so). Git's revision IDs are SHA-1 checksums, although I have no idea what they are computed over. Mercurial's ChangeSetIDs are also SHA-1 checksums, computed over the combination of the parent ID and the content of the file (Mercurial also has integer revision numbers, but they are local, not global). In fact, SHA-1 checksum values of some kind seem to be the default answer to the question of creating unique change identifiers in DVCSes.

These non-integral (or at least integral greater than 2**31-1) change numbers pose a problem for CCNET. Ticket CCNET-1188 asks for sourcecontrol support for Mercurial and offers a nice, well thought out patch. To deal with the 40-hex-character ChangeSetID (technically a "nodeid"), it subclasses the Modification object and builds a MercurialModification. For the patch, it was the only real option - I'm sure the author didn't want to wreak havoc upon the rest of CCNET. But I don't like the implied idea of variant Modifications, especially since their content is exposed outside CCNET (e.g., the <modificationWriter> task).

I'm thinking of relaxing the definition of a CCNET "change number" to be a "change identifier", and to redeclare it as a string of undefined internal structure (an "opaque value" to the protocol geeks among us). That would change some things in CCNET:

    * The build emails and the web dashboard displays of modifications might be harder to read as the Change Number column could be significantly wider (e.g., 40 chars for SHA-1).

    * The LastChangeNumber would be difficult to define. Today it means "numerically greatest change number", which would be simply wrong for SHA-1. In fact, for anything that isn't an ordered set, it may be impossible to define on a CCNET-wide basis. The good news is that there are very few uses of it except in unit tests (specifically, the AccuRev and Subversion sourcecontrol implementations, and the LastChangeLabeller labeler).

    * The few sourcecontrol systems that attempt to update the source to a specific change number (just AccuRev and Subversion) would have a problem, as they depend on the "numerically greatest" aspect of LastChangeNumber. The good news is that this code is part of those sourcecontrol implementations, and they could determine the numerically greatest change number themselves, since the implementers would know that it was an Int.

    * I'm sure there are programs outside CCNET that read its Modification data. There were some changes proposed to the dashboard recently that would group modifications by change number and collapse them. And the existence of the <modificationWriter> task implies that somebody out there is reading $(artifactDir)\modifcations.xml. The former will probably cope just fine, but its anybody's guess about the latter.