Ruben raises some very good points. 3rd party tools do exist...
On Thu, Jun 11, 2009 at 8:57 PM, Ruben Willems<[email protected]> wrote: > > 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 >> >
