ccnet-devel Mailing List for CruiseControl.NET

Hi Frederic,

If someone checks changes in to Vault between the time the build
starts, and the time that a label is applied, and the label includes
the newly committed, but not tested, file change, then that is a
problem with CCNet's Vault plugin.

The CVS plugin, for example, always labels the revisions that are
currently in the local working directory, so it doesn't suffer this
problem.

I'm afraid I don't know anything about Vault so I'm not able to
confirm or deny whether the CCNet Vault plugin is behaving correctly
or not - maybe some of the Vault committers on this list can chip in.

Mike

On 6/30/05, Fr=E9d=E9ric Didier <fre...@vc...> wrote:
>=20
>=20
> Hello
>=20
> =20
>=20
> I tried to use Cruise Control for a continuous build of some applications=
.
>=20
> For the moment, I have problem with the "labelling" of compliant sources
> versions on Vault.
>=20
> I noticed that labelling is the last operation done. It is not a kind of
> problem if we launch building one time a day at 00:30, but in a continuou=
s
> build context and many developers, I suppose it will not exactly assume t=
hat
> labelled sources are in exact correspondence with produced sources. Is th=
ere
> some transaction on vault I didn't see between GetLatest and Label ?
>=20
> =20
>=20
> I notice some dysfunctions: in noIncrementOnLabel and autoLabel mode, if
> compile fail, ccnet fail in an exception at the label time (just after
> compile).
>=20
> Then, label is correctly applied on vault, but state file is not up to da=
te,
> and as a consequence next iteration will always fail because it try to ap=
ply
> an already existing label on vault sources.
>=20
> =20
>=20
> The only solution I found is to let my MsBuild script compile and label t=
he
> sources, but the main default of that, is the obligation of using blind
> autoincrementation of version numbers, and the presence of labels on vaul=
t
> that represent "wrong" versions with not corresponding exe.
>=20
> =20
>=20
> Thanks for the helping me
>=20
> =20
>=20
> Best Regards
>=20
> =20
>=20
> --
>=20
> Fr=E9d=E9ric DIDIER
>=20
> Dotnet Developper
>=20
> VCS Timeless France


--=20
mike roberts | http://mikeroberts.thoughtworks.net/ |
http://www.thoughtworks.com/

I am working on labelling, too, and this is alwo waht I will use.
=20
Basically have Nant apply a label, THEN wipe the disc, THEN get, THEN =
build.
=20
On failure, I will kill the label.
=20
Thomas


________________________________

	From: ccn...@li... =
[mailto:ccn...@li...] On Behalf Of Perry =
Ismangil
	Sent: Donnerstag, 30. Juni 2005 11:46
	To: ccn...@li...
	Subject: RE: [Ccnet-devel] help me please
=09
=09
	Hi,
	=20
	I don't have an exact answer for your problem, but in my current =
process I do not use the labeling mechanism from ccnet. Instead I label =
things from my build (nant) script. This way I can label first, then =
retrieve based on that label, and build. If the build is not successful, =
I will delete the label. This way I am assured that a label in my code =
is always a 'successful build' label.
	=20

	--
	Perry Ismangil
	Technical Architect
	Tribal Technology Ltd
	The new name for FD Learning
	St Mary's Court,
	55 St Mary's Road
	Sheffield, S2 4AN
=09
	Tel: 0114 219 6118 Fax: 0114 2816021
	Email: per...@tr...
	Web: www.tribaltechnology.co.uk
=09
	A member of Tribal Group plc
	=
-------------------------------------------------------------------------=
---------------
	This email and any files transmitted with it are confidential and =
intended solely for the use of the individual or entity to whom they are =
addressed. Access, copying, dissemination or re-use of information in it =
by anyone else is unauthorised.  If you have received this message in =
error, please contact me on the above number.

	=20

________________________________

	From: ccn...@li... =
[mailto:ccn...@li...] On Behalf Of =
Fr=E9d=E9ric Didier
	Sent: 30 June 2005 10:40
	To: ccn...@li...
	Subject: [Ccnet-devel] help me please
=09
=09

	Hello

	=20

	I tried to use Cruise Control for a continuous build of some =
applications.

	For the moment, I have problem with the "labelling" of compliant =
sources versions on Vault.

	I noticed that labelling is the last operation done. It is not a kind =
of problem if we launch building one time a day at 00:30, but in a =
continuous build context and many developers, I suppose it will not =
exactly assume that labelled sources are in exact correspondence with =
produced sources. Is there some transaction on vault I didn't see =
between GetLatest and Label ?

	=20

	I notice some dysfunctions: in noIncrementOnLabel and autoLabel mode, =
if compile fail, ccnet fail in an exception at the label time (just =
after compile).

	Then, label is correctly applied on vault, but state file is not up to =
date, and as a consequence next iteration will always fail because it =
try to apply an already existing label on vault sources.

	=20

	The only solution I found is to let my MsBuild script compile and label =
the sources, but the main default of that, is the obligation of using =
blind autoincrementation of version numbers, and the presence of labels =
on vault that represent "wrong" versions with not corresponding exe.

	=20

	Thanks for the helping me

	=20

	Best Regards

	=20

	--

	Fr=E9d=E9ric DIDIER

	Dotnet Developper

	VCS Timeless France

Hi,
=20
I don't have an exact answer for your problem, but in my current process =
I do not use the labeling mechanism from ccnet. Instead I label things =
from my build (nant) script. This way I can label first, then retrieve =
based on that label, and build. If the build is not successful, I will =
delete the label. This way I am assured that a label in my code is =
always a 'successful build' label.
=20

--
Perry Ismangil
Technical Architect
Tribal Technology Ltd
The new name for FD Learning
St Mary's Court,
55 St Mary's Road
Sheffield, S2 4AN

Tel: 0114 219 6118 Fax: 0114 2816021
Email: per...@tr...
Web: www.tribaltechnology.co.uk

A member of Tribal Group plc
-------------------------------------------------------------------------=
---------------
This email and any files transmitted with it are confidential and =
intended solely for the use of the individual or entity to whom they are =
addressed. Access, copying, dissemination or re-use of information in it =
by anyone else is unauthorised.  If you have received this message in =
error, please contact me on the above number.

=20

________________________________

From: ccn...@li... =
[mailto:ccn...@li...] On Behalf Of =
Fr=E9d=E9ric Didier
Sent: 30 June 2005 10:40
To: ccn...@li...
Subject: [Ccnet-devel] help me please



Hello

=20

I tried to use Cruise Control for a continuous build of some =
applications.

For the moment, I have problem with the "labelling" of compliant sources =
versions on Vault.

I noticed that labelling is the last operation done. It is not a kind of =
problem if we launch building one time a day at 00:30, but in a =
continuous build context and many developers, I suppose it will not =
exactly assume that labelled sources are in exact correspondence with =
produced sources. Is there some transaction on vault I didn't see =
between GetLatest and Label ?

=20

I notice some dysfunctions: in noIncrementOnLabel and autoLabel mode, if =
compile fail, ccnet fail in an exception at the label time (just after =
compile).

Then, label is correctly applied on vault, but state file is not up to =
date, and as a consequence next iteration will always fail because it =
try to apply an already existing label on vault sources.

=20

The only solution I found is to let my MsBuild script compile and label =
the sources, but the main default of that, is the obligation of using =
blind autoincrementation of version numbers, and the presence of labels =
on vault that represent "wrong" versions with not corresponding exe.

=20

Thanks for the helping me

=20

Best Regards

=20

--

Fr=E9d=E9ric DIDIER

Dotnet Developper

VCS Timeless France

Hello

=20

I tried to use Cruise Control for a continuous build of some =
applications.

For the moment, I have problem with the "labelling" of compliant sources =
versions on Vault.

I noticed that labelling is the last operation done. It is not a kind of =
problem if we launch building one time a day at 00:30, but in a =
continuous build context and many developers, I suppose it will not =
exactly assume that labelled sources are in exact correspondence with =
produced sources. Is there some transaction on vault I didn't see =
between GetLatest and Label ?

=20

I notice some dysfunctions: in noIncrementOnLabel and autoLabel mode, if =
compile fail, ccnet fail in an exception at the label time (just after =
compile).

Then, label is correctly applied on vault, but state file is not up to =
date, and as a consequence next iteration will always fail because it =
try to apply an already existing label on vault sources.

=20

The only solution I found is to let my MsBuild script compile and label =
the sources, but the main default of that, is the obligation of using =
blind autoincrementation of version numbers, and the presence of labels =
on vault that represent "wrong" versions with not corresponding exe.

=20

Thanks for the helping me

=20

Best Regards

=20

--

Fr=E9d=E9ric DIDIER

Dotnet Developper

VCS Timeless France

Hello,

> the VCS?  Can Modification collection be passed to NAnt from 
> CCNet somehow?  Should I create a custom service that listens 
> to only that project and deploys the latest scripts to a 
> database and triggers a build that runs tests, etc?

Latest CCNet have ModificationWriter task for this.

http://confluence.public.thoughtworks.org/display/CCNET/Modification+Writer+
Task

Let us know, how you like it!

Martin Aliger
 

Hello all,

I have come to a point in automating the build of our projects where I
would like to be able to deploy all of our web services, services, and
web sites to test servers.  However, all of our products talk to a set
of SQL databases that more often than not, require upgrade scripts
(which we keep in our Version Control System).  I was wondering if
anyone has seen or attempted automatically updating a SQL database based
on ONLY the files that have been changed in the VCS?  Can Modification
collection be passed to NAnt from CCNet somehow?  Should I create a
custom service that listens to only that project and deploys the latest
scripts to a database and triggers a build that runs tests, etc?

Any suggestions would be great!  I have code written in NAnt to make
command line calls to execute any given script file (Stored Proc, View,
etc.) against a configurable database.  All I need to do is tie it into
CCNet properly.  I guess I could just run ALL of the upgrade scripts
upon a single file changing, but this just makes me wrench and puke at
the mere thought of it.

Thanks,
Stephen

Owen,

> i) do these changes address issue ccnet-436?=20
> http://jira.public.thoughtworks.org/browse/CCNET-436  .  i assume that
> they do.

Yes, I believe it will.

> ii) what is the purpose of the LocalOnly property?  i need to include
> it in the updated documentation

The purpose initially was for a custom sourcecontrol that I wrote to
read a VS solution file and dynamically create the sourcecontrol for
every project. For example: using ccnet.sln the sourcecontrol would read
it, find the projects, extract the directories (mapping file system
directories to web projects), pass each directory to the sourcecontrol
specified (I used the multi-sourcecontrol task for reference), and
return the combined modifications.  Ok, now for the LocalOnly properties
part in all of this...I wanted to check the solution file for
modifications (since most of the time the solution file sits up a
directory from the projects) but did not want to recurse the whole
directory tree.  Once I added the LocalOnly I couldn't see why not to
make it available to users of the task.  Sorry, long explanation.

> iii) on lines 90/91:
> 				if ((modifications.Length > 0) &&
UseHistory)
> //				if (modifications.Length > 0 ||
AutoGetSource)	// > > do we really
> want to do this?
>
> the top line is the original code, which i've left in for now, and the
> bottom one is what you added.  the original line makes sense to me,
> but i'm a bit confused by the new line.  my understanding is that we
> only want to get the latest source during the period of modification
> detection if we are using the history approach.  if we are not setting
> UseHistory, then we will get modifications from the root using the
> GetSource call.  could you help clarify the motivation for changing
> the condition?

I agree, confusing.  I believe that it was accidentally left in from an
experiment where I was trying to get past the issue of new directories
being added to the CVS repository (BTW I haven't found a solution for
that yet).  You are more than welcome to remove the line completely.=20

> other than that, thanks for the extra unit tests.  it will make it
> much easier to maintain the code.  btw, mike beat me to adding you to
> the ccnet contributors page:
> http://confluence.public.thoughtworks.org/display/CCNET/Project+Team

Thanks!

--Craig=20

On 6/28/05, Owen Rogers <exo...@gm...> wrote:
> great!  thanks craig.  i'll have another look at committing this
tonight.
> cheers,
> owen.
>=20
> On 6/27/05, Campbell, Craig <Cra...@la...> wrote:
> > Owen,
> >
> > Thanks for the instruction.  I have fixed the tests so they use a
Mock
> > ProcessExecutor and understand your need to forge ahead without the
> > patch.  I have included the changed unittest class for inclusion at
your
> > convenience.
> >
> > Thanks,
> > Craig
> >
> > -----Original Message-----
> > From: ccn...@li...
> > [mailto:ccn...@li...] On Behalf Of Owen
> > Rogers
> > Sent: Saturday, June 25, 2005 9:39 AM
> > To: ccn...@li...
> > Subject: [Ccnet-devel] CVS history patch
> >
> > hi craig,
> > thanks for the patch.  i tried it out, but unfortunately i can't get
> > the unit tests to run.  i think that it might be because i have a
> > different directory structure than you -- i think that you are
trying
> > to run the cvs.exe in a folder that i don't have.  anyway, my
> > preference is that we don't shell out to external programs in order
to
> > be able to run the unit test -- it tends to really slow the tests
down
> > and it is a pain to manage.  pretty much all unit tests use mocked
> > versions of the ProcessExecutor and it would be great if the
> > HistoryParser unit tests did also.
> > because i'm trying to get the release out the door, i'm intending to
> > push committing this until the next release.
> > cheers,
> > owen,
> >
> > On 6/16/05, Campbell, Craig <Cra...@la...> wrote:
> > > Owen,
> > >
> > > I would like to submit the attached items for inclusion in the
latest
> > > release.  I have modified the CVS history logic to fix some issues
I
> > > found (see below for more detail).  I also took your advice and
pulled
> > > the logic out into its own class (CvsHistoryCommandParser) with
its
> > own
> > > tests that better test the functionality of the history command
> > > (specifically the parsing of the entries).
> > >
> > > One major change to the history command logic was how the history
> > > entries were parsed to account for spaces in the directory names
and
> > to
> > > not return more than what was requested.
> > >
> > > Thanks,
> > > Craig
> > --
> > Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
> > CruiseControl.NET - http://ccnet.thoughtworks.com
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> > _______________________________________________
> > Ccnet-devel mailing list
> > Ccn...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> >
> > This email, and any files or previous email messages included with
it, may contain confidential and/or privileged material. If you are not
the intended recipient please contact the sender and delete all copies.
> >
> >
> >
> >
>=20
>=20
> --
> Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
> CruiseControl.NET - http://ccnet.thoughtworks.com
>=20


--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

On 6/29/05, Owen Rogers <exo...@gm...> wrote:
> mike,
> i've created a jira for this.  who's going to comit it - you or me?
> http://jira.public.thoughtworks.org/browse/CCNET-465
> cheers,

Please could you? I won't be able to do this before the weekend (pesky
work firewalls, grrr...)

btw, i forgot to say: i think that this is a really cool idea.  i can
see many other innovative labellers being created based on this idea.=20
thanks for the contribution craig!
cheers,
owen.

On 6/29/05, Owen Rogers <exo...@gm...> wrote:
> mike,
> i've created a jira for this.  who's going to comit it - you or me?
> http://jira.public.thoughtworks.org/browse/CCNET-465
> cheers,
> owen.
>=20
> On 6/28/05, Campbell, Craig <Cra...@la...> wrote:
> > Mike,
> >
> > I have already sent Owen my agreement, but if you need it as well, I
> > agree.
> >
> > Thanks,
> > Craig
> >
> > -----Original Message-----
> > From: ccn...@li...
> > [mailto:ccn...@li...] On Behalf Of Mike
> > Roberts
> > Sent: Tuesday, June 28, 2005 9:42 AM
> > To: ccn...@li...
> > Subject: [SPAM] - Re: [Ccnet-devel] Iteration Labeller - Email found in
> > subject
> >
> > Thanks!
> >
> > Please can you look at
> > http://confluence.public.thoughtworks.org/display/CCNET/Contributor+Lic=
e
> > nse+Agreement
> > and the attachment document, and let us know if you agree with the
> > conditions (sorry for the hassle - legal stuff). Once you've done that
> > we'll put your name on
> > http://confluence.public.thoughtworks.org/display/CCNET/Project+Team .
> >
> > Cheers,
> >
> > Mike
> >
> > On 6/28/05, Campbell, Craig <Cra...@la...> wrote:
> > > More than happy to share. :)  It is self-contained with unit tests.
> > >
> > > Thanks,
> > > Craig
> > >
> > > Is is self-contained and unit tested? If so there's no reason we
> > > shouldn't just add it to the main project. Otherwise you might be bes=
t
> > > to put the source up on the CCNet Community Confluence space if you'r=
e
> > > keen to share.
> > >
> > > Mike
> > >
> > > On 6/27/05, Campbell, Craig <Cra...@la...> wrote:
> > > > Just out of curiosity.  We have just implemented an iteration
> > labeler
> > > > which mirrors the DefaultLabeller except that it increments the
> > > > iteration as well as the build number.  The question is, is this of
> > > any
> > > > interest.  If so what is the best location for it (core|contrib)?
> > > >
> > > > <labeller type=3D"iterationlabeller">
> > > >   <prefix>1-0</prefix>
> > > >   <duration>2</duration>
> > > >   <separator>-</separator>
> > > >   <releaseStartDate>January 5, 2005</releaseStartDate>
> > > > </labeller>
> > > >
> > > > Attributes:
> > > > Prefix - same function as default labeller.
> > > > Duration - Iteration length in weeks.
> > > > Separator - The string to use to separate the prefix, iteration, an=
d
> > > > build default is '.'.
> > > > releaseStartDate - the date to start the iteration tracking.
> > > >
> > > > Thanks,
> > > > Craig
> > > >
> > > > This email, and any files or previous email messages included with
> > it,
> > > may contain confidential and/or privileged material. If you are not
> > the
> > > intended recipient please contact the sender and delete all copies.
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > SF.Net email is sponsored by: Discover Easy Linux Migration
> > Strategies
> > > > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > > > informative Webcasts and more! Get everything you need to get up to
> > > > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> > > > _______________________________________________
> > > > Ccnet-devel mailing list
> > > > Ccn...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> > > >
> > >
> > >
> > > --
> > > mike roberts | http://mikeroberts.thoughtworks.net/ |
> > > http://www.thoughtworks.com/
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Discover Easy Linux Migration Strategie=
s
> > > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > > informative Webcasts and more! Get everything you need to get up to
> > > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> > > _______________________________________________
> > > Ccnet-devel mailing list
> > > Ccn...@li...
> > > https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> > >
> > >
> > >
> >
> >
> > --
> > mike roberts | http://mikeroberts.thoughtworks.net/ |
> > http://www.thoughtworks.com/
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> > _______________________________________________
> > Ccnet-devel mailing list
> > Ccn...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> > _______________________________________________
> > Ccnet-devel mailing list
> > Ccn...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> >
>=20
>=20
> --
> Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
> CruiseControl.NET - http://ccnet.thoughtworks.com
>=20


--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

mike,
i've created a jira for this.  who's going to comit it - you or me?
http://jira.public.thoughtworks.org/browse/CCNET-465
cheers,
owen.

On 6/28/05, Campbell, Craig <Cra...@la...> wrote:
> Mike,
>=20
> I have already sent Owen my agreement, but if you need it as well, I
> agree.
>=20
> Thanks,
> Craig
>=20
> -----Original Message-----
> From: ccn...@li...
> [mailto:ccn...@li...] On Behalf Of Mike
> Roberts
> Sent: Tuesday, June 28, 2005 9:42 AM
> To: ccn...@li...
> Subject: [SPAM] - Re: [Ccnet-devel] Iteration Labeller - Email found in
> subject
>=20
> Thanks!
>=20
> Please can you look at
> http://confluence.public.thoughtworks.org/display/CCNET/Contributor+Lice
> nse+Agreement
> and the attachment document, and let us know if you agree with the
> conditions (sorry for the hassle - legal stuff). Once you've done that
> we'll put your name on
> http://confluence.public.thoughtworks.org/display/CCNET/Project+Team .
>=20
> Cheers,
>=20
> Mike
>=20
> On 6/28/05, Campbell, Craig <Cra...@la...> wrote:
> > More than happy to share. :)  It is self-contained with unit tests.
> >
> > Thanks,
> > Craig
> >
> > Is is self-contained and unit tested? If so there's no reason we
> > shouldn't just add it to the main project. Otherwise you might be best
> > to put the source up on the CCNet Community Confluence space if you're
> > keen to share.
> >
> > Mike
> >
> > On 6/27/05, Campbell, Craig <Cra...@la...> wrote:
> > > Just out of curiosity.  We have just implemented an iteration
> labeler
> > > which mirrors the DefaultLabeller except that it increments the
> > > iteration as well as the build number.  The question is, is this of
> > any
> > > interest.  If so what is the best location for it (core|contrib)?
> > >
> > > <labeller type=3D"iterationlabeller">
> > >   <prefix>1-0</prefix>
> > >   <duration>2</duration>
> > >   <separator>-</separator>
> > >   <releaseStartDate>January 5, 2005</releaseStartDate>
> > > </labeller>
> > >
> > > Attributes:
> > > Prefix - same function as default labeller.
> > > Duration - Iteration length in weeks.
> > > Separator - The string to use to separate the prefix, iteration, and
> > > build default is '.'.
> > > releaseStartDate - the date to start the iteration tracking.
> > >
> > > Thanks,
> > > Craig
> > >
> > > This email, and any files or previous email messages included with
> it,
> > may contain confidential and/or privileged material. If you are not
> the
> > intended recipient please contact the sender and delete all copies.
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> > > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > > informative Webcasts and more! Get everything you need to get up to
> > > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> > > _______________________________________________
> > > Ccnet-devel mailing list
> > > Ccn...@li...
> > > https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> > >
> >
> >
> > --
> > mike roberts | http://mikeroberts.thoughtworks.net/ |
> > http://www.thoughtworks.com/
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> > _______________________________________________
> > Ccnet-devel mailing list
> > Ccn...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> >
> >
> >
>=20
>=20
> --
> mike roberts | http://mikeroberts.thoughtworks.net/ |
> http://www.thoughtworks.com/
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>=20


--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

hi craig,
ok, i've committed your changes.  i have a few questions though:
i) do these changes address issue ccnet-436?=20
http://jira.public.thoughtworks.org/browse/CCNET-436  .  i assume that
they do.
ii) what is the purpose of the LocalOnly property?  i need to include
it in the updated documentation
iii) on lines 90/91:
 =09=09=09=09if ((modifications.Length > 0) && UseHistory)
//=09=09=09=09if (modifications.Length > 0 || AutoGetSource)=09// do we rea=
lly
want to do this?

the top line is the original code, which i've left in for now, and the
bottom one is what you added.  the original line makes sense to me,
but i'm a bit confused by the new line.  my understanding is that we
only want to get the latest source during the period of modification
detection if we are using the history approach.  if we are not setting
UseHistory, then we will get modifications from the root using the
GetSource call.  could you help clarify the motivation for changing
the condition?

other than that, thanks for the extra unit tests.  it will make it
much easier to maintain the code.  btw, mike beat me to adding you to
the ccnet contributors page:
http://confluence.public.thoughtworks.org/display/CCNET/Project+Team

cheers,
owen.

On 6/28/05, Owen Rogers <exo...@gm...> wrote:
> great!  thanks craig.  i'll have another look at committing this tonight.
> cheers,
> owen.
>=20
> On 6/27/05, Campbell, Craig <Cra...@la...> wrote:
> > Owen,
> >
> > Thanks for the instruction.  I have fixed the tests so they use a Mock
> > ProcessExecutor and understand your need to forge ahead without the
> > patch.  I have included the changed unittest class for inclusion at you=
r
> > convenience.
> >
> > Thanks,
> > Craig
> >
> > -----Original Message-----
> > From: ccn...@li...
> > [mailto:ccn...@li...] On Behalf Of Owen
> > Rogers
> > Sent: Saturday, June 25, 2005 9:39 AM
> > To: ccn...@li...
> > Subject: [Ccnet-devel] CVS history patch
> >
> > hi craig,
> > thanks for the patch.  i tried it out, but unfortunately i can't get
> > the unit tests to run.  i think that it might be because i have a
> > different directory structure than you -- i think that you are trying
> > to run the cvs.exe in a folder that i don't have.  anyway, my
> > preference is that we don't shell out to external programs in order to
> > be able to run the unit test -- it tends to really slow the tests down
> > and it is a pain to manage.  pretty much all unit tests use mocked
> > versions of the ProcessExecutor and it would be great if the
> > HistoryParser unit tests did also.
> > because i'm trying to get the release out the door, i'm intending to
> > push committing this until the next release.
> > cheers,
> > owen,
> >
> > On 6/16/05, Campbell, Craig <Cra...@la...> wrote:
> > > Owen,
> > >
> > > I would like to submit the attached items for inclusion in the latest
> > > release.  I have modified the CVS history logic to fix some issues I
> > > found (see below for more detail).  I also took your advice and pulle=
d
> > > the logic out into its own class (CvsHistoryCommandParser) with its
> > own
> > > tests that better test the functionality of the history command
> > > (specifically the parsing of the entries).
> > >
> > > One major change to the history command logic was how the history
> > > entries were parsed to account for spaces in the directory names and
> > to
> > > not return more than what was requested.
> > >
> > > Thanks,
> > > Craig
> > --
> > Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
> > CruiseControl.NET - http://ccnet.thoughtworks.com
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> > _______________________________________________
> > Ccnet-devel mailing list
> > Ccn...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> >
> > This email, and any files or previous email messages included with it, =
may contain confidential and/or privileged material. If you are not the int=
ended recipient please contact the sender and delete all copies.
> >
> >
> >
> >
>=20
>=20
> --
> Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
> CruiseControl.NET - http://ccnet.thoughtworks.com
>=20


--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

Mike,

I have already sent Owen my agreement, but if you need it as well, I
agree.

Thanks,
Craig

-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Mike
Roberts
Sent: Tuesday, June 28, 2005 9:42 AM
To: ccn...@li...
Subject: [SPAM] - Re: [Ccnet-devel] Iteration Labeller - Email found in
subject

Thanks!

Please can you look at
http://confluence.public.thoughtworks.org/display/CCNET/Contributor+Lice
nse+Agreement
and the attachment document, and let us know if you agree with the
conditions (sorry for the hassle - legal stuff). Once you've done that
we'll put your name on
http://confluence.public.thoughtworks.org/display/CCNET/Project+Team .

Cheers,

Mike

On 6/28/05, Campbell, Craig <Cra...@la...> wrote:
> More than happy to share. :)  It is self-contained with unit tests.
>=20
> Thanks,
> Craig
>=20
> Is is self-contained and unit tested? If so there's no reason we
> shouldn't just add it to the main project. Otherwise you might be best
> to put the source up on the CCNet Community Confluence space if you're
> keen to share.
>=20
> Mike
>=20
> On 6/27/05, Campbell, Craig <Cra...@la...> wrote:
> > Just out of curiosity.  We have just implemented an iteration
labeler
> > which mirrors the DefaultLabeller except that it increments the
> > iteration as well as the build number.  The question is, is this of
> any
> > interest.  If so what is the best location for it (core|contrib)?
> >
> > <labeller type=3D"iterationlabeller">
> >   <prefix>1-0</prefix>
> >   <duration>2</duration>
> >   <separator>-</separator>
> >   <releaseStartDate>January 5, 2005</releaseStartDate>
> > </labeller>
> >
> > Attributes:
> > Prefix - same function as default labeller.
> > Duration - Iteration length in weeks.
> > Separator - The string to use to separate the prefix, iteration, and
> > build default is '.'.
> > releaseStartDate - the date to start the iteration tracking.
> >
> > Thanks,
> > Craig
> >
> > This email, and any files or previous email messages included with
it,
> may contain confidential and/or privileged material. If you are not
the
> intended recipient please contact the sender and delete all copies.
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> > _______________________________________________
> > Ccnet-devel mailing list
> > Ccn...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> >
>=20
>=20
> --
> mike roberts | http://mikeroberts.thoughtworks.net/ |
> http://www.thoughtworks.com/
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>=20
>=20
>=20


--=20
mike roberts | http://mikeroberts.thoughtworks.net/ |
http://www.thoughtworks.com/


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

Thanks!

Please can you look at
http://confluence.public.thoughtworks.org/display/CCNET/Contributor+License=
+Agreement
and the attachment document, and let us know if you agree with the
conditions (sorry for the hassle - legal stuff). Once you've done that
we'll put your name on
http://confluence.public.thoughtworks.org/display/CCNET/Project+Team .

Cheers,

Mike

On 6/28/05, Campbell, Craig <Cra...@la...> wrote:
> More than happy to share. :)  It is self-contained with unit tests.
>=20
> Thanks,
> Craig
>=20
> Is is self-contained and unit tested? If so there's no reason we
> shouldn't just add it to the main project. Otherwise you might be best
> to put the source up on the CCNet Community Confluence space if you're
> keen to share.
>=20
> Mike
>=20
> On 6/27/05, Campbell, Craig <Cra...@la...> wrote:
> > Just out of curiosity.  We have just implemented an iteration labeler
> > which mirrors the DefaultLabeller except that it increments the
> > iteration as well as the build number.  The question is, is this of
> any
> > interest.  If so what is the best location for it (core|contrib)?
> >
> > <labeller type=3D"iterationlabeller">
> >   <prefix>1-0</prefix>
> >   <duration>2</duration>
> >   <separator>-</separator>
> >   <releaseStartDate>January 5, 2005</releaseStartDate>
> > </labeller>
> >
> > Attributes:
> > Prefix - same function as default labeller.
> > Duration - Iteration length in weeks.
> > Separator - The string to use to separate the prefix, iteration, and
> > build default is '.'.
> > releaseStartDate - the date to start the iteration tracking.
> >
> > Thanks,
> > Craig
> >
> > This email, and any files or previous email messages included with it,
> may contain confidential and/or privileged material. If you are not the
> intended recipient please contact the sender and delete all copies.
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> > _______________________________________________
> > Ccnet-devel mailing list
> > Ccn...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> >
>=20
>=20
> --
> mike roberts | http://mikeroberts.thoughtworks.net/ |
> http://www.thoughtworks.com/
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>=20
>=20
>=20


--=20
mike roberts | http://mikeroberts.thoughtworks.net/ |
http://www.thoughtworks.com/

More than happy to share. :)  It is self-contained with unit tests.

Thanks,
Craig

Is is self-contained and unit tested? If so there's no reason we
shouldn't just add it to the main project. Otherwise you might be best
to put the source up on the CCNet Community Confluence space if you're
keen to share.

Mike

On 6/27/05, Campbell, Craig <Cra...@la...> wrote:
> Just out of curiosity.  We have just implemented an iteration labeler
> which mirrors the DefaultLabeller except that it increments the
> iteration as well as the build number.  The question is, is this of
any
> interest.  If so what is the best location for it (core|contrib)?
>=20
> <labeller type=3D"iterationlabeller">
>   <prefix>1-0</prefix>
>   <duration>2</duration>
>   <separator>-</separator>
>   <releaseStartDate>January 5, 2005</releaseStartDate>
> </labeller>
>=20
> Attributes:
> Prefix - same function as default labeller.
> Duration - Iteration length in weeks.
> Separator - The string to use to separate the prefix, iteration, and
> build default is '.'.
> releaseStartDate - the date to start the iteration tracking.
>=20
> Thanks,
> Craig
>=20
> This email, and any files or previous email messages included with it,
may contain confidential and/or privileged material. If you are not the
intended recipient please contact the sender and delete all copies.
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>=20


--=20
mike roberts | http://mikeroberts.thoughtworks.net/ |
http://www.thoughtworks.com/


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

... then how about writing a CCNet Firefox plugin? :)

Cruise / Java has one now (http://www.md.pp.ru/mozilla/cc/) so you
might want to take inspiration from that.

Mike

--=20
mike roberts | http://mikeroberts.thoughtworks.net/ |
http://www.thoughtworks.com/

great!  thanks craig.  i'll have another look at committing this tonight.
cheers,
owen.

On 6/27/05, Campbell, Craig <Cra...@la...> wrote:
> Owen,
>=20
> Thanks for the instruction.  I have fixed the tests so they use a Mock
> ProcessExecutor and understand your need to forge ahead without the
> patch.  I have included the changed unittest class for inclusion at your
> convenience.
>=20
> Thanks,
> Craig
>=20
> -----Original Message-----
> From: ccn...@li...
> [mailto:ccn...@li...] On Behalf Of Owen
> Rogers
> Sent: Saturday, June 25, 2005 9:39 AM
> To: ccn...@li...
> Subject: [Ccnet-devel] CVS history patch
>=20
> hi craig,
> thanks for the patch.  i tried it out, but unfortunately i can't get
> the unit tests to run.  i think that it might be because i have a
> different directory structure than you -- i think that you are trying
> to run the cvs.exe in a folder that i don't have.  anyway, my
> preference is that we don't shell out to external programs in order to
> be able to run the unit test -- it tends to really slow the tests down
> and it is a pain to manage.  pretty much all unit tests use mocked
> versions of the ProcessExecutor and it would be great if the
> HistoryParser unit tests did also.
> because i'm trying to get the release out the door, i'm intending to
> push committing this until the next release.
> cheers,
> owen,
>=20
> On 6/16/05, Campbell, Craig <Cra...@la...> wrote:
> > Owen,
> >
> > I would like to submit the attached items for inclusion in the latest
> > release.  I have modified the CVS history logic to fix some issues I
> > found (see below for more detail).  I also took your advice and pulled
> > the logic out into its own class (CvsHistoryCommandParser) with its
> own
> > tests that better test the functionality of the history command
> > (specifically the parsing of the entries).
> >
> > One major change to the history command logic was how the history
> > entries were parsed to account for spaces in the directory names and
> to
> > not return more than what was requested.
> >
> > Thanks,
> > Craig
> --
> Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
> CruiseControl.NET - http://ccnet.thoughtworks.com
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>=20
> This email, and any files or previous email messages included with it, ma=
y contain confidential and/or privileged material. If you are not the inten=
ded recipient please contact the sender and delete all copies.
>=20
>=20
>=20
>=20


--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

Is is self-contained and unit tested? If so there's no reason we
shouldn't just add it to the main project. Otherwise you might be best
to put the source up on the CCNet Community Confluence space if you're
keen to share.

Mike

On 6/27/05, Campbell, Craig <Cra...@la...> wrote:
> Just out of curiosity.  We have just implemented an iteration labeler
> which mirrors the DefaultLabeller except that it increments the
> iteration as well as the build number.  The question is, is this of any
> interest.  If so what is the best location for it (core|contrib)?
>=20
> <labeller type=3D"iterationlabeller">
>   <prefix>1-0</prefix>
>   <duration>2</duration>
>   <separator>-</separator>
>   <releaseStartDate>January 5, 2005</releaseStartDate>
> </labeller>
>=20
> Attributes:
> Prefix - same function as default labeller.
> Duration - Iteration length in weeks.
> Separator - The string to use to separate the prefix, iteration, and
> build default is '.'.
> releaseStartDate - the date to start the iteration tracking.
>=20
> Thanks,
> Craig
>=20
> This email, and any files or previous email messages included with it, ma=
y contain confidential and/or privileged material. If you are not the inten=
ded recipient please contact the sender and delete all copies.
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>=20


--=20
mike roberts | http://mikeroberts.thoughtworks.net/ |
http://www.thoughtworks.com/

Just out of curiosity.  We have just implemented an iteration labeler
which mirrors the DefaultLabeller except that it increments the
iteration as well as the build number.  The question is, is this of any
interest.  If so what is the best location for it (core|contrib)?

<labeller type=3D"iterationlabeller">
  <prefix>1-0</prefix>
  <duration>2</duration>
  <separator>-</separator>
  <releaseStartDate>January 5, 2005</releaseStartDate>
</labeller>

Attributes:
Prefix - same function as default labeller.
Duration - Iteration length in weeks.
Separator - The string to use to separate the prefix, iteration, and
build default is '.'.
releaseStartDate - the date to start the iteration tracking.

Thanks,
Craig

This email, and any files or previous email messages included with it, =
may contain confidential and/or privileged material. If you are not the =
intended recipient please contact the sender and delete all copies.

Owen,

Thanks for the instruction.  I have fixed the tests so they use a Mock
ProcessExecutor and understand your need to forge ahead without the
patch.  I have included the changed unittest class for inclusion at your
convenience.

Thanks,
Craig

-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Owen
Rogers
Sent: Saturday, June 25, 2005 9:39 AM
To: ccn...@li...
Subject: [Ccnet-devel] CVS history patch

hi craig,
thanks for the patch.  i tried it out, but unfortunately i can't get
the unit tests to run.  i think that it might be because i have a
different directory structure than you -- i think that you are trying
to run the cvs.exe in a folder that i don't have.  anyway, my
preference is that we don't shell out to external programs in order to
be able to run the unit test -- it tends to really slow the tests down
and it is a pain to manage.  pretty much all unit tests use mocked
versions of the ProcessExecutor and it would be great if the
HistoryParser unit tests did also.
because i'm trying to get the release out the door, i'm intending to
push committing this until the next release.
cheers,
owen,

On 6/16/05, Campbell, Craig <Cra...@la...> wrote:
> Owen,
>=20
> I would like to submit the attached items for inclusion in the latest
> release.  I have modified the CVS history logic to fix some issues I
> found (see below for more detail).  I also took your advice and pulled
> the logic out into its own class (CvsHistoryCommandParser) with its
own
> tests that better test the functionality of the history command
> (specifically the parsing of the entries).
>=20
> One major change to the history command logic was how the history
> entries were parsed to account for spaces in the directory names and
to
> not return more than what was requested.
>=20
> Thanks,
> Craig
--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

This email, and any files or previous email messages included with it, =
may contain confidential and/or privileged material. If you are not the =
intended recipient please contact the sender and delete all copies.

+1 to the current behavior (i.e. I agree with Mike). Ideally, 'Failed' 
builds should only be useful to the development team for as long as it 
takes to get a successful build. In some ways, their stickiness already 
interferes with that -- i.e. they feel a bit too legitimate, and encourage 
people to do things like try to reduce the number of failed builds per 
iteration.

I understand that not everyone uses CCNET the way it was originally 
intended, and that a tool must support its customers, but if the behavior 
is amended in some way, the current behavior really needs to be retained. 
AFAIC there are only successful builds, and information that describes the 
actions taken to achieve that success. Thus, incrementing the build number 
only has meaning for successful builds. I know of several teams who 
practice CI this way.

In short, enhance labelling with options for labelling failed builds 
perhaps, but don't replace it -- it would break a lot of people's 
effective use of the tool.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
omnis cellula e cellula

Hello All,

As the person in charge of QA for our company, I would like to see the
failed builds being labelled in CC.NET, as well as in the attached
source code control system.  This may be very useful information for
investigating the why of a failed build later on and creating statistics
to help developers learn better processes:
- Managing their change-lists for a more consistent check-in process
	-- One check-in per bug fix, though
	-- The building of the binaries should not fail, tests may
however
- Generating reports that prove that following *some* of the FxCop rules
does make sense
- Labelling a failed build and associating it with build artifacts in
CC.NET 	with a *common* naming system (PROJECT.BUILD.*.xml, whatever)
rather 	than the two different log file names that exist now would be
extremely helpful for generating a release-wide statistics reports.

Stephen

-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Michael
Luke
Sent: Monday, June 27, 2005 9:27 AM
To: ccn...@li...
Subject: RE: [Ccnet-devel] label incrementing

As someone who takes the build number and uses it directly in an
AssemblyInfo task I'd much prefer it for the default to remain as
"failed builds won't be labelled".

I'm already dreading what will happen if CCNet gets to build 10000!

Mike

ccn...@li... wrote:
> If I am not mistaken, I thought the ITemporaryLabeler interface was to
> be used for setting temporary labels to the code during the build
> process.  If the build failed, the temporary label would
> remain (in some
> SourceControl classes)
>=20
> I understand the need for failed builds as well.  In the
> company I work
> for, a failed build means the developers who checked in code needed to
> fix whatever is broken.  It would be great to have the option to label
> all builds so developers could get whatever version was
> broken.  We have
> code that changes all the time and it would be easier to fix if the
> label has been applied to the source.
>=20
> I believe we should make the labeler support both and make
> the condition
> by default to keep the code the way it is.  I would be one to
> configure the builds to enable labeling a failed build for our
> purposes.  I would
> like to request the label have the word FAILED in there so we could
> programmatically remove failed labels now and then.
>=20
> James Bolles
>=20
>=20
> -----Original Message-----
> From: ccn...@li...
> [mailto:ccn...@li...] On Behalf Of Graham
> Tackley Sent: Monday, June 27, 2005 7:49 AM
> To: ccn...@li...
> Subject: RE: [Ccnet-devel] label incrementing
>=20
> Agreed (with Mike).
>=20
> The build label is public-facing -- it gets recorded in source control
> systems and often in the executables produced. Failed builds
> are only of
> interest to ccnet, not to anything external.
>=20
> CCNet's model of only updating the build label on successful builds is
> great for reinforcing the mantra that artifacts only exist in the real
> world when they are successfully continuously integrated.  This
> should remain the default.=20
>=20
> +1 for a use of a ccnet internal build id instead.
>=20
> g
>=20
>> -----Original Message-----
>> From: ccn...@li... [mailto:ccnet-devel-
>> ad...@li...] On Behalf Of mik...@gm...
>> Sent: 27 June 2005 1:25 pm To: ccn...@li...
>> Subject: Re: [Ccnet-devel] label incrementing
>>=20
>> I disagree. We actually already don't use the 'build label' as a
>> unique identifier of a build - we use IntegrationResult.StartTime (I
>> think) - as far as I'm concerned that's perfectly reasonable. Build
>> Labels I believe should just be a referential ID used for successful
>> builds, typically seen by users, but a CCNet internal Build ID can be
>> something different, and an implementation detail.
>>=20
>> Of course, if people do want to increment the build label on failed
>> builds, that's fine too, but I think it should be an option and not
>> mandatory.=20
>>=20
>> Mike
>>=20
>> On 6/27/05, Owen Rogers <exo...@gm...> wrote:
>>> currently, by default, ccnet only increments the build label on each
>>> successful build.  this provides the advantage that you know how
>>> many successful builds have occurred; however, it means that a
>>> successful build will share the same label as any of the failed
>>> builds that preceed it.  this creates problems for artifact storage
>>> as failed builds will share the same artifact directory as the
>>>  successful build. in general, i think that you want to retain your
>>> failed build artifacts as well as your successful ones.
>>>=20
>>> in other words, the core problem is that the build label is not a
>>> unique identifier of a build (only of a successful one).
>>>=20
>>> i can't remember why we implemented the labeller to work this way,
>>> and i'm not sure whether or not this is the right behaviour. i
>>> checked the cc-java source and it doesn't look like they do this.
>>>=20
>>> unless anyone can think of a good reason not to do this, i think
>>> that going forward, the build label should always be incremented by
>>> default -- regardless of the success or failure of the previous
>>> build; however, you can always set the incrementOnSuccess property
>>> to false if you only want to increment on successful builds.
>>>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> ******************************************************************
> This email and any files transmitted with it from the ElPaso
> Corporation are confidential and intended solely for the
> use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the
> sender.
> ******************************************************************
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op,ick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel


This Message Scanned for Viruses by McAfee WebShield .

On 6/27/05, Bolles, James E <Jam...@el...> wrote:

> I understand the need for failed builds as well.  In the company I work
> for, a failed build means the developers who checked in code needed to
> fix whatever is broken.=20

So you need a referential way of identifying failed builds? At the
moment, that does exist, but its just a date, and it doesn't say
'failed' (Look at
http://ccnetlive.thoughtworks.com/ccnet/default.aspx?_action_ViewAllBuilds=
=3Dtrue&server=3DCCNetLive%201&project=3DCCNet,
for example) .

Maybe what we could do is add the option to generate referential
identifiers for failed builds, which *may* include incrementing the
build number.

Whatever we do, CCNet internally would still work using
non-referential IDs, but as a user you wouldn't have to see them.

Mike

As someone who takes the build number and uses it directly in an
AssemblyInfo task I'd much prefer it for the default to remain as
"failed builds won't be labelled".

I'm already dreading what will happen if CCNet gets to build 10000!

Mike

ccn...@li... wrote:
> If I am not mistaken, I thought the ITemporaryLabeler interface was to
> be used for setting temporary labels to the code during the build
> process.  If the build failed, the temporary label would
> remain (in some
> SourceControl classes)
>=20
> I understand the need for failed builds as well.  In the
> company I work
> for, a failed build means the developers who checked in code needed to
> fix whatever is broken.  It would be great to have the option to label
> all builds so developers could get whatever version was
> broken.  We have
> code that changes all the time and it would be easier to fix if the
> label has been applied to the source.
>=20
> I believe we should make the labeler support both and make
> the condition
> by default to keep the code the way it is.  I would be one to
> configure the builds to enable labeling a failed build for our
> purposes.  I would
> like to request the label have the word FAILED in there so we could
> programmatically remove failed labels now and then.
>=20
> James Bolles
>=20
>=20
> -----Original Message-----
> From: ccn...@li...
> [mailto:ccn...@li...] On Behalf Of Graham
> Tackley Sent: Monday, June 27, 2005 7:49 AM
> To: ccn...@li...
> Subject: RE: [Ccnet-devel] label incrementing
>=20
> Agreed (with Mike).
>=20
> The build label is public-facing -- it gets recorded in source control
> systems and often in the executables produced. Failed builds
> are only of
> interest to ccnet, not to anything external.
>=20
> CCNet's model of only updating the build label on successful builds is
> great for reinforcing the mantra that artifacts only exist in the real
> world when they are successfully continuously integrated.  This
> should remain the default.=20
>=20
> +1 for a use of a ccnet internal build id instead.
>=20
> g
>=20
>> -----Original Message-----
>> From: ccn...@li... [mailto:ccnet-devel-
>> ad...@li...] On Behalf Of mik...@gm...
>> Sent: 27 June 2005 1:25 pm To: ccn...@li...
>> Subject: Re: [Ccnet-devel] label incrementing
>>=20
>> I disagree. We actually already don't use the 'build label' as a
>> unique identifier of a build - we use IntegrationResult.StartTime (I
>> think) - as far as I'm concerned that's perfectly reasonable. Build
>> Labels I believe should just be a referential ID used for successful
>> builds, typically seen by users, but a CCNet internal Build ID can be
>> something different, and an implementation detail.
>>=20
>> Of course, if people do want to increment the build label on failed
>> builds, that's fine too, but I think it should be an option and not
>> mandatory.=20
>>=20
>> Mike
>>=20
>> On 6/27/05, Owen Rogers <exo...@gm...> wrote:
>>> currently, by default, ccnet only increments the build label on each
>>> successful build.  this provides the advantage that you know how
>>> many successful builds have occurred; however, it means that a
>>> successful build will share the same label as any of the failed
>>> builds that preceed it.  this creates problems for artifact storage
>>> as failed builds will share the same artifact directory as the
>>>  successful build. in general, i think that you want to retain your
>>> failed build artifacts as well as your successful ones.
>>>=20
>>> in other words, the core problem is that the build label is not a
>>> unique identifier of a build (only of a successful one).
>>>=20
>>> i can't remember why we implemented the labeller to work this way,
>>> and i'm not sure whether or not this is the right behaviour. i
>>> checked the cc-java source and it doesn't look like they do this.
>>>=20
>>> unless anyone can think of a good reason not to do this, i think
>>> that going forward, the build label should always be incremented by
>>> default -- regardless of the success or failure of the previous
>>> build; however, you can always set the incrementOnSuccess property
>>> to false if you only want to increment on successful builds.
>>>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> ******************************************************************
> This email and any files transmitted with it from the ElPaso
> Corporation are confidential and intended solely for the
> use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the
> sender.
> ******************************************************************
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel

If I am not mistaken, I thought the ITemporaryLabeler interface was to
be used for setting temporary labels to the code during the build
process.  If the build failed, the temporary label would remain (in some
SourceControl classes)=20

I understand the need for failed builds as well.  In the company I work
for, a failed build means the developers who checked in code needed to
fix whatever is broken.  It would be great to have the option to label
all builds so developers could get whatever version was broken.  We have
code that changes all the time and it would be easier to fix if the
label has been applied to the source.

I believe we should make the labeler support both and make the condition
by default to keep the code the way it is.  I would be one to configure
the builds to enable labeling a failed build for our purposes.  I would
like to request the label have the word FAILED in there so we could
programmatically remove failed labels now and then.

James Bolles=20
=20

-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Graham
Tackley
Sent: Monday, June 27, 2005 7:49 AM
To: ccn...@li...
Subject: RE: [Ccnet-devel] label incrementing

Agreed (with Mike).

The build label is public-facing -- it gets recorded in source control
systems and often in the executables produced. Failed builds are only of
interest to ccnet, not to anything external. =20

CCNet's model of only updating the build label on successful builds is
great for reinforcing the mantra that artifacts only exist in the real
world when they are successfully continuously integrated.  This should
remain the default.

+1 for a use of a ccnet internal build id instead.

g

> -----Original Message-----
> From: ccn...@li... [mailto:ccnet-devel-
> ad...@li...] On Behalf Of mik...@gm...
> Sent: 27 June 2005 1:25 pm
> To: ccn...@li...
> Subject: Re: [Ccnet-devel] label incrementing
>=20
> I disagree. We actually already don't use the 'build label' as a
> unique identifier of a build - we use IntegrationResult.StartTime (I
> think) - as far as I'm concerned that's perfectly reasonable. Build
> Labels I believe should just be a referential ID used for successful
> builds, typically seen by users, but a CCNet internal Build ID can be
> something different, and an implementation detail.
>=20
> Of course, if people do want to increment the build label on failed
> builds, that's fine too, but I think it should be an option and not
> mandatory.
>=20
> Mike
>=20
> On 6/27/05, Owen Rogers <exo...@gm...> wrote:
> > currently, by default, ccnet only increments the build label on each
> > successful build.  this provides the advantage that you know how
many
> > successful builds have occurred; however, it means that a successful
> > build will share the same label as any of the failed builds that
> > preceed it.  this creates problems for artifact storage as failed
> > builds will share the same artifact directory as the successful
build.
> >  in general, i think that you want to retain your failed build
> > artifacts as well as your successful ones.
> >
> > in other words, the core problem is that the build label is not a
> > unique identifier of a build (only of a successful one).
> >
> > i can't remember why we implemented the labeller to work this way,
and
> > i'm not sure whether or not this is the right behaviour.  i checked
> > the cc-java source and it doesn't look like they do this.
> >
> > unless anyone can think of a good reason not to do this, i think
that
> > going forward, the build label should always be incremented by
default
> > -- regardless of the success or failure of the previous build;
> > however, you can always set the incrementOnSuccess property to false
> > if you only want to increment on successful builds.
> >



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
******************************************************************
This email and any files transmitted with it from the ElPaso
Corporation are confidential and intended solely for the
use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the
sender.
******************************************************************

Agreed.  The dashboard is great without the old apps and it is easier to
configure CC.NET when you have many projects. =20

James Bolles

=20

-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Graham
Tackley
Sent: Monday, June 27, 2005 7:54 AM
To: ccn...@li...
Subject: RE: [Ccnet-devel] old web app (was: artifact directory)

>=20
> Also note that this will break the old web app. We need to decide what
> we are doing with the old web app - personally I'm in favour of
> ditching it.
>=20

Agreed.  In fact, the presence of two web apps is plain confusing to
users
installing ccnet.  The dashboard is reliable and well tested enough now
to
ditch the old web app.  It works fine even if there is only one project,
so it's difficult to see why you'd want to use the old web app.  I
haven't
used it on any of the projects I've been involved with for a long time
--
the dashboard works fine.

g


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
******************************************************************
This email and any files transmitted with it from the ElPaso
Corporation are confidential and intended solely for the
use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the
sender.
******************************************************************