David Cameron <[email protected]> wrote: Hi Dave
> > 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. By the time writing this i forgot that MKS also has the same type of revisions on the project level. They call it checkpoint. It is like having RCS revisions for your project and each revision contains a defined set of RCS revivions of files. They call it member revisions.... (brain hurts) > 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. The question is what do we need to have the labellers work with different types of SCM. We need increasing "project revision" numbers (integers) for the labellers. And we need to track modifications on files to know when we have to trigger a build (the current implementation counts modifications of files, not "commits" or "changesets"?). As far as i understand we need a global identifier for each changeset (whatever it looks like ... string?) to track what actual "revision" a change to the project is in the underlying SCM and a increasing number of "revisions" (integer) that can be used for the labellers (the count of commits on the current branch?) that can be mapped to the "project revision"... > 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. I completely agree that it can be misleading. The sequential build numbers are only useful for the "branch" you're monitoring. But that is another problem to me... With DVCS you still tend to have a central repository and if this is the "branch" you build in your CC.NET project the sequential revision numbers still have a meaning as long as they can be mapped to a global changeset identifier (a hashsum or int or whatever). If this is a convention we can follow it looks like we can solve this problem to me. > 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. In my opinion what we're trying to figure out is if there is a way to solve this problem if we define a convention for how to use all available SCM with CC.NET. The easiest solution would be to say "DVCS do not have sequential build numbers and therefore the labelers that depend on sequential numbers do not work". Another solution would be to say "sequential build numbers depend on the SCM you are using and might be local to a branch - at least they can be mapped to a global revision identifier". What is your opinion on this? regards, Daniel > Dave Cameron > CruiseControl.NET - http://ccnet.thoughtworks.com
