Hi all
just had a quick chat with Dna, and he has some points.
A small recap of the chat :
° 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
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
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
>>
>
>
