Hello, this is no reason to not introduce the both new properties (if we want them). Because we leave the old "LastChangeNumber" alive, add a [Obsolete] attribute and route it internal to the new property "LastSCMChangeRevisionNumber". In 1.6 we can finally remove it.
I don't see any reason to not refactor code. Daniel Leszek Ciesielski schrieb: > 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 >>> >>>
