ccnet-devel Mailing List for CruiseControl.NET

> With this in mind, and the fact that using labels to uniquely identify
> builds would make things simpler in CCNet, I'm proposing we switch to
> a 'increment build label on failure' model. Later on we could
> introduce configurable alternative build identifer strategies and
> label increment strategies, but as a first step I'd like to consider
> this option.

Hi!

increment on failure could become the default, with a simple flag to disabl=
e
this behavior (until we define more elaborated strategies).

Thibaut
--
[blog] http://www.dotnetguru2.org/tbarrere

> From: ccn...@li...=20
> [mailto:ccn...@li...] On Behalf Of=20
> Mike Roberts
> Sent: Friday, February 24, 2006 6:13 PM
> Subject: [Ccnet-user] incrementing build numbers for failed builds
>=20
> I've been thinking about this more, especially in the context=20
> of supporting build artifacts, and I think I'm swinging more=20
> to Owen's point of view. Failed builds do often have value=20
> (for example, examining their 'log' artifact to see what went=20
> wrong), and sometimes we may even use more concrete artifacts=20
> from a 'failed' build. For instance, maybe there's a test=20
> failing, but even with such a failing test you could still=20
> use the new version of an application.

I forgot : I totally agree that it would be an important step
to recognize the value of "partially failed" builds.

It may be TDD heresy, but it seems to me that sometimes there
is value in committing a known failing test to the tree, if only
as a reminder that something needs to be fixed.

Cheers,
--Jonathan

> From: ccn...@li...=20
> [mailto:ccn...@li...] On Behalf Of=20
> Mike Roberts
> Sent: Friday, February 24, 2006 6:13 PM
> To: ccn...@li...;=20
> ccn...@li...
> Subject: [Ccnet-user] incrementing build numbers for failed builds
>=20
> With this in mind, and the fact that using labels to uniquely=20
> identify builds would make things simpler in CCNet, I'm=20
> proposing we switch to a 'increment build label on failure'=20
> model. Later on we could introduce configurable alternative=20
> build identifer strategies and label increment strategies,=20
> but as a first step I'd like to consider this option.
>=20
> Does anyone have any opinion either way?

Mike,

I can offer a data point that may or may not be related :
because of the nice way CCNet presents source control history
in the dashboard, and because we are using VSS which has
no decent interface to browse the history, we have
come to sort of rely on the CCNet dashboard for our history
needs, as in : what happened yesterday on the tree ?

It would be convenient for us if failed builds were numbered,
because it would give us a poor man's version of changesets which
VSS does not offer, even for changes that break the build.
But I'm sure this is not a heavy argument in favor of
numbering failed builds.

Cheers,
--Jonathan

On Friday, February 24, 2006 @ 12:09 PM Owen Rogers did scribble:
> On 24/02/06, Mike Roberts <mik...@gm...> wrote:
> > On 24/02/06, Owen Rogers <exo...@gm...> wrote:
> > > now that sourceforge supports subversion, who thinks that=20
> we should=20
> > > migrate to an svn repository?
> >
> > I would like to, ideally keeping history and dropping any junk we=20
> > don't use any more. Are SF offering a specific way to migrate over=20
> > from CVS and keep history?
>=20
> http://sourceforge.net/docs/E09#import

Although I don't have commit rights (and you are probably of sound mind
not given me any ;)) I would prefer subversion over cvs.  Going through
similar experience's recently (and still trying to get some things
sorted) here are some things that I would point out with regards to
migrating.

1) Think about repository layouts before hand.  What I mean by this is
how you are going to do you branch / tags structure.  The svnbook lists
2 main methods which are basically having either a single /tags,
/branches, /trunk or having the separate ones for each project (what I
try to do but the last big cvs -> svn migration I saw done here was the
single approach and it doesn't seem to look as nice to me).

2) Having a quick look at the options sourceforge provide I would say do
the migration yourself if you can and give them a dump from the SVN
repository.  This way you can get everything migrated over in the
structure you like before getting it setup on sourceforge again.

3) Do you need to use Sourceforge (personally I don't like it).  If you
want to move over to subversion would something like tigris.org be
better (seeing as the subversion guys use it)?  Might be too much of a
pain though with the mailing list side of things.

I'm sure there are other things but they could be discussed later if you
go for it.

Steve

Hi all,

Right now CCNet only increments build labels for failed builds. One of
the side-effects of this is that internally CCNet uniquely identifies
individual builds by something not particularly human readable (a
date/time stamp)

I was having a chat with Owen about this a few weeks back, and Owen
was trying to convince me that we should start incrementing build
labels even for *failed* builds and start identifying builds just by
their label. I disagreed with him at the time saying something along
the lines that failed builds aren't any use, so why increment their
version?

I've been thinking about this more, especially in the context of
supporting build artifacts, and I think I'm swinging more to Owen's
point of view. Failed builds do often have value (for example,
examining their 'log' artifact to see what went wrong), and sometimes
we may even use more concrete artifacts from a 'failed' build. For
instance, maybe there's a test failing, but even with such a failing
test you could still use the new version of an application.

With this in mind, and the fact that using labels to uniquely identify
builds would make things simpler in CCNet, I'm proposing we switch to
a 'increment build label on failure' model. Later on we could
introduce configurable alternative build identifer strategies and
label increment strategies, but as a first step I'd like to consider
this option.

Does anyone have any opinion either way?

Cheers,

Mike

--
mike roberts | http://www.mikebroberts.com/

On 24/02/06, Mike Roberts <mik...@gm...> wrote:
> On 24/02/06, Owen Rogers <exo...@gm...> wrote:
> > now that sourceforge supports subversion, who thinks that we should
> > migrate to an svn repository?
>
> I would like to, ideally keeping history and dropping any junk we
> don't use any more. Are SF offering a specific way to migrate over
> from CVS and keep history?

http://sourceforge.net/docs/E09#import

cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

On 24/02/06, Owen Rogers <exo...@gm...> wrote:
> now that sourceforge supports subversion, who thinks that we should
> migrate to an svn repository?

I would like to, ideally keeping history and dropping any junk we
don't use any more. Are SF offering a specific way to migrate over
from CVS and keep history?

Mike

Hi

if I understood well the branch parameter is only taken into account when
checking for modifications (Surround.GetModifications), but not when the
source is actually retrieved (Surround.GetSource).

I've made a quick patch to also use the branch when GetSource is called.
Although it seems to work, Yan could you have a look at it ?

http://jira.public.thoughtworks.org/browse/CCNET-657


kind regards

Thibaut Barr=E8re
--
[blog] http://www.dotnetguru2.org/tbarrere

Testing, for some reason, all email coming from CCNet's developer lists
are being blocked because of an invalid encoding type.

*raises his hand*




*raises the other hand*

--
Ian=20

> -----Original Message-----
> From: ccn...@li...=20
> [mailto:ccn...@li...] On Behalf Of=20
> Owen Rogers
> Sent: Thursday, February 23, 2006 11:05 PM
> To: ccn...@li...
> Subject: [Ccnet-devel] switch to subversion??
>=20
> now that sourceforge supports subversion, who thinks that we=20
> should migrate to an svn repository?
> cheers,
> owen.
> --
> Owen Rogers | http://dotnetjunkies.com/weblog/exortech |=20
> CruiseControl.NET - http://ccnet.thoughtworks.com
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language that extends applications into web and=20
> mobile media. Attend the live webcast and join the prime=20
> developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel

+1

________________________________

From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Foster,
Richard - PAL
Sent: February 24, 2006 8:53 AM
To: ccn...@li...
Subject: RE: [Ccnet-devel] switch to subversion??

=20

+1 on the yes side.

=20

If multiple votes are allowed +10 :-)

=20

Regards,

Richard

=20

________________________________

From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Andrew
Stopford
Sent: Friday, February 24, 2006 03:42
To: ccn...@li...
Subject: Re: [Ccnet-devel] switch to subversion??

I think thats a good move. The switch to use svn on the dogfood ccnet
server will be very smooth, using ccnet\svn in oss and commerical
projects without a problem.

=20

Andy

=20

On 2/24/06, Owen Rogers <exo...@gm...> wrote:=20

now that sourceforge supports subversion, who thinks that we should
migrate to an svn repository?
cheers,=20
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com=20


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast=20
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
<http://sel.as-us.falkag.net/sel?cmdlnk&kid%110944&bid$1720&dat%121642>=20
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

=20

+1 on the yes side.
=20
If multiple votes are allowed +10 :-)
=20
Regards,
Richard

________________________________

From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Andrew
Stopford
Sent: Friday, February 24, 2006 03:42
To: ccn...@li...
Subject: Re: [Ccnet-devel] switch to subversion??


I think thats a good move. The switch to use svn on the dogfood ccnet
server will be very smooth, using ccnet\svn in oss and commerical
projects without a problem.
=20
Andy

=20
On 2/24/06, Owen Rogers <exo...@gm...> wrote:=20

	now that sourceforge supports subversion, who thinks that we
should
	migrate to an svn repository?
	cheers,=20
	owen.
	--
	Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
	CruiseControl.NET - http://ccnet.thoughtworks.com=20
=09
=09
	-------------------------------------------------------
	This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
	that extends applications into web and mobile media. Attend the
live webcast=20
	and join the prime developer group breaking into this new coding
territory!
=09
http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642=20
	_______________________________________________
	Ccnet-devel mailing list
	Ccn...@li...
	https://lists.sourceforge.net/lists/listinfo/ccnet-devel
=09

> > In short, I would rather call that "server locale" the "vss=20
> executable=20
> > locale", though I am not entirely satisfied by this naming either...
>=20
> what about repository locale or repository installation=20
> locale?  i can't remember what vss calls it when you install=20
> the software.  i remember that you have the option to install=20
> the client tools or to install <i think that the call it the=20
> server -- but i can't remember for sure>.  to me "vss=20

The setup option you are referring to is "Create VSS database". It
creates
a repository, but it does not install any additional software. There are
a
bunch of confusing setup options such as, IIRC, "Create network setup"
but
that just relates to creating a shared directory for the distribution of
the VSS client software itself. There _is_ no VSS server software. Just
imagine CVS without its pserver implementation.

> executable locale" makes it uncertain as to which executable=20
> is being referred to (ie. it could be referring to my local=20
> ss.exe install).

That is my whole point :-), it *is* dependent on your local (where I
assume
you define 'local' as 'on the CC.NET server') ss.exe (actually, some
here
have observed that it depends on the presence of a localized DLL
alongside
SS.EXE) !

Does my suggestion make more sense given this fact ?

Cheers,
--Jonathan

I don't mind

On 2/24/06, Perry Ismangil <ism...@gm...> wrote:
>
> On 2/24/06, Owen Rogers <exo...@gm...> wrote:
> >
> > now that sourceforge supports subversion, who thinks that we should
> > migrate to an svn repository?
> >
>
> +1
>
> --
> Perry Ismangil

On 2/24/06, Owen Rogers <exo...@gm...> wrote:
>
> now that sourceforge supports subversion, who thinks that we should
> migrate to an svn repository?
>

+1

--
Perry Ismangil

+1

On 24/02/06, Owen Rogers <exo...@gm...> wrote:
>
> now that sourceforge supports subversion, who thinks that we should
> migrate to an svn repository?
> cheers,
> owen.
>

I think thats a good move. The switch to use svn on the dogfood ccnet serve=
r
will be very smooth, using ccnet\svn in oss and commerical projects without
a problem.

Andy


On 2/24/06, Owen Rogers <exo...@gm...> wrote:
>
> now that sourceforge supports subversion, who thinks that we should
> migrate to an svn repository?
> cheers,
> owen.
> --
> Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
> CruiseControl.NET - http://ccnet.thoughtworks.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>

Yes yes yes yes! =20

=20

-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Owen =
Rogers
Sent: Thursday, February 23, 2006 9:05 PM
To: ccn...@li...
Subject: [Ccnet-devel] switch to subversion??

now that sourceforge supports subversion, who thinks that we should =
migrate
to an svn repository?
cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech | =
CruiseControl.NET -
http://ccnet.thoughtworks.com


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting =
language
that extends applications into web and mobile media. Attend the live =
webcast
and join the prime developer group breaking into this new coding =
territory!
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.0.0/267 - Release Date: 2/22/2006
=20

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.0.0/267 - Release Date: 2/22/2006
=20

now that sourceforge supports subversion, who thinks that we should
migrate to an svn repository?
cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

(moved to ccnet-devel)

hi jonathan,

On 23/02/06, Jonathan Perret <Jon...@au...> wrote:
> Thank you Owen. I'm sorry if my comment above came out as impatient;

not at all.

> However I do have a minor nitpick regarding the changes you committed to
> VssLocale.cs.

please nitpick away.  code readability on an open source project is key.

> In short, I would rather call that "server locale" the "vss executable
> locale", though I am not
> entirely satisfied by this naming either...

what about repository locale or repository installation locale?  i
can't remember what vss calls it when you install the software.  i
remember that you have the option to install the client tools or to
install <i think that the call it the server -- but i can't remember
for sure>.  to me "vss executable locale" makes it uncertain as to
which executable is being referred to (ie. it could be referring to my
local ss.exe install).

cheers,
owen.

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

Hi All

I know this is not a CCNEt problem, but has anybody ever encountered this :
System.BadImageFormatException : An attempt was made to load a program with
an incorrect format.

This occurs when running the tests with NCover, running the tests with NUni=
t
alone works.
NCover 1.3.3    Nunit 2.2

Other projects do not give this problem, so it must be somehting special
with this one.
Fuslogvw does not show any missing assemblies or so (no errors at all).

at the site of NCover there is a topic about it
http://www.ncover.org/COMMUNITY/ShowPost.aspx?PostID=3D171

I do depend on other assemblies, of which I do not have the source :-((
but I do not want to NCover these (they do not have .pdb files anyway).


Does somebody have an idea on how to get NCover work in this project?
using the new NCover is not really an option, as it depends on .net 2.0


with kind regards
Ruben Willems

hi david,

On 21/02/06, Strickland,David <dst...@mn...> wrote:
>         At the moment I created a new EXE containing a Class Implementing
> ICruiseServerFactory. The constructor code for this is the same as
> CruiseFactoryServer except when initializing the CachingConfigurationServ=
ice
> I pass in a new implementation of IConfigurationService. This custom
> IConfiguration Uses VSS as it's source instead of a physical file.

this sounds like a reasonable approach.  the dependency injection
approach of ccnet is designed to support just this kind of
substitution.  the cruiseserverfactory is basically like a top-level
container that wires up all the server dependencies.  we could just as
well use a pico container-style configuration file to provide
pluggability of different configurationservices.

this is the first time that we've had this request.  please let us
know how your experiment goes.

btw, an additional option would be to build a custom ccnet project
type that could probe a vs.net sln file for sourcecontrol and
compilation information.  something a la maven for ccnet would go a
long way towards simplifying the ccnet.config file.

>         Provided the contracts for ICruiseServerFactory and
> IConfigurationService remain then there should not be an issue when a new
> version of CCNet is released.

we don't have any plans to change these interfaces in the near term.=20
however as they are not published, we don't really make any guarantee
about their stability.

hth,
owen.

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

hi david,

On 22/02/06, Strickland,David <dst...@mn...> wrote:
> Not sure
> ThoughtWorks.CruiseControl.Core.Config.DefaultConfigurationFileSaver.Save=
()
> might be obsolete but figured I would Fyi that it looks like it is not
> functioning in 1.0.

thanks for raising this.  the DefaultConfigurationFileSaver.Save()
method was added to support the configuration management ui that mike
created in the webdashboard.  the idea was to provide a web interface
for managing the configuration file.  the Save() method would save the
configured projects constructed by this ui.  this was several months
back and, while i believe that it did work with limited behaviour,
mike disabled the functionality until it could be completed.

as for the TimeoutSerialiser, this was added near the end of the 1.0
release and i don't believe that its serialisation functionality has
really been tested.  so the combination of these two factors makes it
unsurprising that we have a problem here.  it probably wouldn't be too
hard to fix the TimeoutSerialiser to more intelligently handle
nulls(?).

cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

Not sure
ThoughtWorks.CruiseControl.Core.Config.DefaultConfigurationFileSaver.Save()
might be obsolete but figured I would Fyi that it looks like it is not
functioning in 1.0. 

The Specific error occurs in TimeoutSerializer.cs line 15 where it tries to
convert target into Timeout

			Timeout to = target as Timeout;

The resulting [to] object is null so when [to.Write] is called a System
exception is returned. With the message "Object reference not set to an
instance of an object." 

The information contained in this message is confidential, protected from disclosure and may be legally privileged.  If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful.  If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format.  Thank you.

On 22/02/06, Stephen Tunney <st...@re...> wrote:
> I believe it is just the service.  The webpage is appearing with that
> error message about the Remoting connection being actively refused.

thanks stephen.  it should be back up now.

apologies to all: i've been too busy with other projects to do much on
ccnet lately.  i appreciate everyone's continued help and support with
the project :)
cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com