Hello On Sun, Jun 14, 2009 at 11:36 AM, Daniel Hommel<[email protected]> wrote: >> 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?
Are we confusing "build numbers" and "revision identifiers"? The first can be owned by cc.net and can be absolutely any string. The second is obviously owned by the SCM system. Sequential build numbers already exist: this is what the default labeller provides. Sequential revision identifiers simply do not exist in many SCM systems. I think this thread is about approaches to map "build numbers" to "revision identifiers". My understanding is that we are looking for a way to make LastChangeLabeller work with non-Subversion SCM systems. This is the user requirement behind the desire for a "build number" to "revision identifier" mapping that involves only single numbers. There is also an unspoken requirement that build number should be in the format #.#.#.# so it can be used for assembly versions. I think the value in LastChangeLabeller is produced by having a number that maps directly back to the SCM's identifiers. This works with SVN and LastChangeLabller, and some other combinations (MKS, TFS): fourth part of label === Subversion revision number (1.4.4.)3096 === r3096 build number === revision identifier whole label (not numeric! actually a string) === MKS revision identifier 1.5.7.128 === 1.5.7.128 But this does not work with other systems build label !== any single CVS construct (except a tag) build label !== any single VSS concept It could work with Mercurial and Git, if arbitrary strings were acceptable, but they are not because of the need to version assemblies. last part of build label === changeset hash (CCNet 1.4.4 build) bd41cb1b0da1 === bd41cb1b0da1 To hit the sweet spot that Subversion and LastChangeLabeller hit, the build number and revision identifier need to be the same number or map transparently. If they do then the build number can be used with the SCM's toolset without consulting an extra mapping. If the number is created by ccnet and the SCM tools don't recognize it, I don't think it adds significant value. Consider a possible approach for making the build number <==> revision identifier mapping, that would work with LastChangeLabeller for arbitrary SCM systems: 1) cc.net will start with the value 0 2) each time updates are pulled from SCM, the number is increased by the number of changesets pulled from the SCM (Identifying changesets is an open question for several SCMs. One I am working on[1], but changesets do not exist in the current code base.) 3) mapping from the cc.net build number back to the SCM revision identifier is done by counting changesets from the start of the branch (how to do this step depends on the SCM, or may be a manual process) This is nearly identical to an existing mapping for build number <==> revision identifier with default labeller ( http://confluence.public.thoughtworks.org/display/CCNET/Default+Labeller ): 1) cc.net will start with any user-defined value 2) each time updates are pulled from SCM, the number is incremented by 1 3) mapping from the cc.net build number to the SCM revision identifier is done with SCM tags I prefer the second approach because step 3 has tool support. The SCM can accept commands using the tags. The first approach has no tool support for part 3. Unless there is SCM tool support for "nth-revision on branch security" that I do not know about? I really don't know much about git, or using mercurial in a large team. If (and only if) the number maps directly to an SCM identifier, the process can be short-circuited: 1) cc.net uses the SCM identifier 2) cc.net still uses the SCM identifier 3) no mapping between cc.net and SCM -- they are the same! (Or the mapping is very simple. Maybe you need to drop the "1.4.4." part.) Tags in SCM systems exist to solve the problem of mapping arbitrary identifiers to SCM revisions. (build number <==> revision identifier) Many SCM systems have good support for tags. In those SCM systems, tags will be easier to use than a cc.net derived "revision number." (A hybrid of a build number + revision identifier.) I think both Mercurial and git have good tag support. The LastChangeLabeller came about because Subversion has awkward tags: a folder with 1000s of subfolders that can be difficult to browse. Any operation on the tags requires using the full URL to the tag's folder. There is no way to go from a commit to the tags that have been added to it. LastChangeLabeller allows a team to use CI, but avoid tags completely To some degree, I think we are discussing taking a hack to work around Subversion's poor tag support (and build on its strength of a single sequential number) and make that part of "normal" operation. Dave Cameron CruiseControl.NET - http://ccnet.thoughtworks.com [1] We used the changeset identification idea as a dojo problem last Wednesday. One of the regular attendees blogged about it at http://www.markhneedham.com/blog/2009/06/12/coding-dojo-17-refactoring-cruise-control-net/
