Hi Daniel On Thu, Jun 11, 2009 at 10:40 PM, Daniel Hommel<[email protected]> wrote: > For example 1.5.7.128 is the 7th > branch of the 5th branch of the mainline and the revision number is > 128. So it's just stripping the branch part...
This is mostly a good description of CVS revision numbers. There is one more thing. The revision numbers are per-file. Each individual file has its own number. The number only increments when that file changes. That makes the revision number mostly useless for any kind of repository wide tracking. I believe VSS has the same limitation. As well as Subversion, I think at least TFS is a recent SCM system with sequential numbers. Actually, I think this is why revision number based labelers are a recent (past few years) addition: they did not work with previous SCM systems. A labeller based on the sequential Mercurial numbers could be useful. It could also be very misleading. Sequential version numbers will be different in each developer's repository. I believe GIT could have the same problem: within a branch, the sequence of commits is not necessarily fixed, but could be different in different repositories. So, an "official" number must be compared to the "official" repository. Comparing a build number to someone's local working copy would probably cause confusion. Having an official, central repository also works against the distributed, decentralized nature of the tool. There is a nice convergence with Subversion. Because it has a single repository wide revision number, that revision number is quite useful for labeling. For other SCM systems, I think the techniques used with CVS make more sense: use build numbers as tags in the SCM system. I would not want to produce a feature that is misleading in a large number of cases. For those that use Subversion, TFS or similar systems, the labeler is probably quite useful. For those using other tools, it's not a good fit. LastChangeNumber is now a bad name. LastChangeIdentifier might be better? For things, like the labeller, that count on it being a number the code could check the value with IsNumeric or something similar. An exception and a WARN or ERROR level log to explain that those components can only be used with numeric ChangeIdentifiers should help users understand the limitations. Dave Cameron CruiseControl.NET - http://ccnet.thoughtworks.com
