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
>
