Ruben Willems <[email protected]> writes: > ° All 3rd party code is already broken due the change of > LastChangeNumber to string > ° the name itself is not that good (SHA-1 data is not a number) > ° Steps needed to fix : > * lets add a new propertiy "LastSCMChangeIdentifier" as string > * route this internally to LastChangeNumber > * mark LastChangeNumber as obsolete > * turn LastChangeNumber back to int > * change all code to use the new property > > This makes it backwords compatible for existing labellers
Sounds good to me. > Support Git/Mercurial item : > ° lets add another property, that fake a numeric value so any > labeller could use (name :LastSCMChangeRevisionNumber) > ° we're able to build a valid numeric label for versioning (based on > a svn rev or a commit count in a branch) > and it should be commented that this revision can be a duplicate > on several dvcs when you check more then one branch/head > but that is in 99% not the case My opinion on the fake numeric revisions that can be used for the labellers is that it works in enough cases to implement it. Certainly it can lead to bad results (assemlies built on different branches with the same number or so) but i think you can ALWAYS misconfigure your system... So +1 for me. regards, Daniel > Any thoughts ? > > > with kind regards > Ruben Willems > > > On Sun, Jun 14, 2009 at 10:00 PM, Ruben Willems > <[email protected]>wrote: > > > Hi all > > > > just to make an overview, and there are no mis-understandings : > > ° every source control of ccnet implements ISourceControl, where > > the main interesting part are > > Modification[] GetModifications(IIntegrationResult from, > > IIntegrationResult to); > > void LabelSourceControl(IIntegrationResult result); > > > > ° the Modification class has these as main points : > > public string Type = "unknown"; > > public string FileName; > > public string FolderName; > > public DateTime ModifiedTime; > > public string UserName; > > public string ChangeNumber; > > public string Version = ""; > > public string Comment; > > > > where version is the file version, and changeNumber is the > > SCM's unique id of the involved commit (eg.: svn revision number) > > and this ChangeNumber used to be an int, and is now changed to > > string to support Git/Mercurial > > there is a static function on this class that will return the > > latest ChangeNumber of an array of Modifications by comparing the > > ModifiedTime > > > > > > The only labellers that pose problems with Git/Mercurial are the > > ones that use this 'ChangeNumber'. As far as I know, only svn and > > perforce are the ones currently providing a global unique > > number(not string) for each commit. > > > > ° labelers all implement ILabeller which has only 1 item: > > string Generate(IIntegrationResult integrationResult); > > > > --> so a labeller can generate any kind of label with the > > information provided of an integration result > > and the only labellers CCNet currently have that use this > > 'ChangeNumber' are AssemblyVersionLabeller and LastChangeLabeller. > > > > LastChange labeler is unlikely to provide a problem, because it > > already provides a label prefix. > > So AssemblyVersionLabeller is the only one that will have a problem, > > because it will need integers. > > Now I do not see a way to convert a SHA-1 hash into a integer > > correctly, so I would say add a validation/check to the > > AssemblyVersionLabeller and all is ok. > > > > Bottom line : I do not see a need to add other properties. > > > > I first saw a DVCS more like following : every 'node' is in fact a > > kind of branch, so consider it as svn on steroids. > > And a CI server as CCNet should only monitor the 'main' branch, as > > it has no point in integrating all nodes. > > But this view appearantly does not cover all angles, so I need to > > learn the concept of git/mercurial more. > > > > But Dave made some very good points, introducing a second property > > will only be usefull for the AssemblyVersionLabeller, > > and only be valid if CCNet monitors a certain branch, and like > > Leszlek pointed out, if you monitor 2 'branches' with CCNet, > > you can have 2 builds with version 1.0.0.0 that have a total > > different code base not good. > > but I think this is in the nature of a DVCS. > > > > Should it indeed be needed later on, we can easily provide the > > needed properties, > > but removing properties is a bad idea, because that will break a > > lot of 3rd party code. > > So let's not make a hasting decision, and think this over again. > > > > > > with kind regards > > Ruben Willems > > > > > > On Sun, Jun 14, 2009 at 6:53 AM, David Cameron <[email protected]> > > wrote: > > > >> > >> I think I found the point where I started to misunderstand or > >> disagree with this discussion. > >> > >> On Thu, Jun 11, 2009 at 9:25 PM, Daniel > >> Nauck<[email protected]> wrote: > >> > 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. > >> > >> I think the solution should be to change AssemblyVersionLabeller to > >> stop assuming numeric revision identifiers. By default, it should > >> increment itself, as DefaultLabeller does. If desired a > >> LastChangeAssemblyVersionLabeller could be made available that > >> works with those version control systems that do provide a number. > >> LastChangeLabeller currently only works with those systems that > >> provide sequential revision numbers. I don't believe this needs to > >> be changed. > >> > >> Builds are not the same things as revisions. Forcing them to share > >> identifiers seems... odd. Although convenient, when simple to do. > >> > >> Dave > >> > > > >
