Hi this approach sounds ok, but thinking it over, I would do something else. Let me explain : Dna wants to introduce a new property to make it possible for the labellers to work with Git and the like and since all current labellers need a number, and git returns sha1 strings, this is a no-go.
but WHY do we need a new property ???? we could easily place the output of $ git rev-list HEAD | wc -l into the existing LastChangeNumber so in fact the 1230 is not needed, purely speaking for the labelers. Another reason I would not do it : the existence of 3rd party labellers, they will all have to be changed ! remember the netrefeflector having a wrong version in the initial 1.4.4 release ! this caused all existing plugins to become unusable with the 1.4.4 release, which we fixed by recompiling 1.4.4 with a correctly versioned netreflector, resulting into the 1.4.4 SP1 release. So if this adding of 2 properties is strictly for the labellers, I would not do it. If possible keep the LastChangeNumber as an integer, and fill it as it was, and for git and the like fill it with $ git rev-list HEAD | wc -l We can introduce a second property LastSCMChangeIdentifier for holding the ID's, but keep the existing LastChangeNumber as an integer so that existing labelers still work (maybe a recompile, but that's all). what do you guys think of this ? summarized : ° keep the existing LastChangeNumber, ° add a LastSCMChangeIdentifier for the SHA1 hashes with kind regards Ruben Willems On Thu, Jun 11, 2009 at 1:25 PM, Daniel Nauck<[email protected]> wrote: > > Hello, > > in the last days Craig fixed issue CCNET-1230[1] to change the > LastChangeNumber property from int to an string to support git and hg's > sha1 hashes. > > Its now impossible to create a numeric label with those source control > systems, e.g. with the LastChange- and AssemblyVersionLabeller > because they provide an SHA-1 hash. This is also the case for every > other SCM that do not have a numeric revision number as commit identifier. > > So the current property "LastChangeNumber" is now much more missleading > then before. > > A possible solution: > > - change "LastChangeNumber" to "LastSCMChangeIdentifier" > > It contains the unique identifier of the last used commit of an SCM. > E.g. the svn revision number or the git sha1 hash, etc. > > - add "LastSCMChangeRevisionNumber" > > It contains a numeric revision number of the changes/commits of an SCM. > E.g. the svn revision number or the count of commits of the current > branch in Mercurical and Git. > > > Now a Labeller implementation could choose one of the 2 provided > properties to create a nice label that depends on the SCM. > > What do you think? > > > How we can get the number of changes for git? > $ git rev-list HEAD | wc -l > > How we can get the number of changes for hg? > Daniel Hommel mentioned that hg has for the local repository a numeric > revision, so we can use that. > > How we can get the number of changes for Subversion? > Using the svn revision number .. so in this case its the same for > "LastSCMChangeIdentifier" and "LastSCMChangeRevisionNumber". > > Other SCM's? > I've never used one of them, so please if you find some time help me to > get the possibilities of each SCM we support to get a unique identifier > and a revision number. > > > Daniel > > > [1] http://jira.public.thoughtworks.org/browse/CCNET-1230 >
