ccnet-devel Mailing List for CruiseControl.NET

Hey Mike,

How did you get around the need to have a new virtual directory for
building web services/applications from a new branch?  I have found that
to be a bit of a pain in the butt, and something I always forget to
change when branching such projects.  This is, of course a NAnt issue at
the core, but is there a way to configure and pass that information in
from the CCNet project configuration leve?

Cheers,
Stephen

-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Mike
Roberts
Sent: Friday, September 30, 2005 11:23 AM
To: ccn...@li...
Subject: Re: [Ccnet-devel] Upgrading Versioning for a project

Hi Stephen,

What you suggest would definitely be useful since all this in theory
is 'standard' process. It would all be quite a lot of work though to
support every Source Control system.

In case you're interested, here's what I did for CCNet:

1 - created the branch
2 - Checked out the branch to a new working directory on CCNetLive
3 - updated the ccnet.config file (its checked into CVS so that was
simple) by cloning the old project
4 - updated the nsis files
5 - updated the state files

(1) Was actually pretty simple but is very much SCM specific
(2) Is something that longer term I would like to see CCNet do anyway
(i.e. when you add a new project, automatically do initial checkout)
(3) Was a matter of cloning the trunk project and updating a couple of
details for the branch, and updating the trunk for a new version.
(4) Is an artifact of using NSIS (I haven't found a way of using the
versions in the DLLs) . If you notice there are no changes to the
build script at all, and this is due to being very careful about
relative directories and getting versioning info from CCNet
properties.
(5) Is a hack at the moment - we need to make this changable through the
UI

Actually, it wasn't much effort at all. With some features like
project cloning, automatic initial checkout and UI-managable version
numbers it would have taken just a couple of minutes. I think
integrating CCNet with SCM branch procedures won't happen for a while,
but we can definitely think about making it easier to create 'sibling'
projects.

Mike

On 9/30/05, Stephen Tunney <st...@re...> wrote:
>
>
>
> Hello All,
>
>
>
> I have a somewhat simple question that has several solutions required.
And
> it has all been spawned by Mike's recent email about branching CCNet
to
> 1.0.0.X, as well as the main trunk being upgraded to 1.1.0.X.
>
>
>
> I was wondering if anyone has created a script to automate at least
part of
> this process.
>
> *         State files need to be updated for new version information
>
> *         Build Scripts may need to be updated
>
> *         Branching needs to be performed
>
> *         In some cases, new client specifications *should* be created
for
> the released versions of the products
>
> *         CCNet projects need to be copied from the original and
updated so
> that the released version has it's own project
>
> *         ...  (I know there's more that I'm not even thinking of at
the
> moment)
>
>
>
> Anyhow, does anyone have any ideas on this?  I would think that this
would
> be an awesome addition to CCNet because, well, branching is a
cornerstone
> methodology in a "good" SCM process.  I know that this would be a
> far-reaching change as well if this were to be integrated directly
into
> CCNet as well.
>
>
>
> Anyone think that this can be done with a reasonable amount of effort
inside
> of CCNet instead of an external Utility?
>
>
>
> Thanks for reading J
>
> Stephen Tunney
>
> SQA Lead
>
> Resume Mirror Inc.


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


This Message Scanned for Viruses by McAfee WebShield .

Owen,

I agree, but it's going to take me a little bit to come up with some 
contrived examples of change output.  I'll work on creating a dummy 
repository for this maybe later today or next week.

Harold

Owen Rogers wrote:
> hi harold,
> 
> On 27/09/05, Harold L Hunt <hu...@st...> wrote:
> 
>>The two attached files add support for BitKeeper to CC.Net.  They should
>>be dropped in:
> 
> 
> thanks for the patch!  looks good.  however, before i can commit it,
> we need to create some unit tests for the provider.  we have
> established a standard for the project that all code needs high unit
> test coverage before we can commit it.  this is what allows us to
> support and update code from a variety of contributors without having
> to worry about full regression tests for each release -- which is
> tricky both for the effort it would entail and to have coverage for
> the number of systems that we integrate with.
> 
> now, i can write the unit tests; however, to do so, i will need some
> things from you:
> - examples of valid bitkeeper command lines for all operations to be
> performed by the provider (ie. commands for getting source, detecting
> modifications, and labelling)
> - examples of the modification output returned by bitkeeper that are
> parsed by the history parser.  ideally, these examples should contain
> added, modified and deleted files -- and any other boundary conditions
> that you can think of that would be worthwhile testing.
> 
> sorry to be a stickler about this.
> cheers,
> owen.
> 
> --
> Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
> CruiseControl.NET - http://ccnet.thoughtworks.com
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
> 

SGkgU3RlcGhlbiwKCldoYXQgeW91IHN1Z2dlc3Qgd291bGQgZGVmaW5pdGVseSBiZSB1c2VmdWwg
c2luY2UgYWxsIHRoaXMgaW4gdGhlb3J5CmlzICdzdGFuZGFyZCcgcHJvY2Vzcy4gSXQgd291bGQg
YWxsIGJlIHF1aXRlIGEgbG90IG9mIHdvcmsgdGhvdWdoIHRvCnN1cHBvcnQgZXZlcnkgU291cmNl
IENvbnRyb2wgc3lzdGVtLgoKSW4gY2FzZSB5b3UncmUgaW50ZXJlc3RlZCwgaGVyZSdzIHdoYXQg
SSBkaWQgZm9yIENDTmV0OgoKMSAtIGNyZWF0ZWQgdGhlIGJyYW5jaAoyIC0gQ2hlY2tlZCBvdXQg
dGhlIGJyYW5jaCB0byBhIG5ldyB3b3JraW5nIGRpcmVjdG9yeSBvbiBDQ05ldExpdmUKMyAtIHVw
ZGF0ZWQgdGhlIGNjbmV0LmNvbmZpZyBmaWxlIChpdHMgY2hlY2tlZCBpbnRvIENWUyBzbyB0aGF0
IHdhcwpzaW1wbGUpIGJ5IGNsb25pbmcgdGhlIG9sZCBwcm9qZWN0CjQgLSB1cGRhdGVkIHRoZSBu
c2lzIGZpbGVzCjUgLSB1cGRhdGVkIHRoZSBzdGF0ZSBmaWxlcwoKKDEpIFdhcyBhY3R1YWxseSBw
cmV0dHkgc2ltcGxlIGJ1dCBpcyB2ZXJ5IG11Y2ggU0NNIHNwZWNpZmljCigyKSBJcyBzb21ldGhp
bmcgdGhhdCBsb25nZXIgdGVybSBJIHdvdWxkIGxpa2UgdG8gc2VlIENDTmV0IGRvIGFueXdheQoo
aS5lLiB3aGVuIHlvdSBhZGQgYSBuZXcgcHJvamVjdCwgYXV0b21hdGljYWxseSBkbyBpbml0aWFs
IGNoZWNrb3V0KQooMykgV2FzIGEgbWF0dGVyIG9mIGNsb25pbmcgdGhlIHRydW5rIHByb2plY3Qg
YW5kIHVwZGF0aW5nIGEgY291cGxlIG9mCmRldGFpbHMgZm9yIHRoZSBicmFuY2gsIGFuZCB1cGRh
dGluZyB0aGUgdHJ1bmsgZm9yIGEgbmV3IHZlcnNpb24uCig0KSBJcyBhbiBhcnRpZmFjdCBvZiB1
c2luZyBOU0lTIChJIGhhdmVuJ3QgZm91bmQgYSB3YXkgb2YgdXNpbmcgdGhlCnZlcnNpb25zIGlu
IHRoZSBETExzKSAuIElmIHlvdSBub3RpY2UgdGhlcmUgYXJlIG5vIGNoYW5nZXMgdG8gdGhlCmJ1
aWxkIHNjcmlwdCBhdCBhbGwsIGFuZCB0aGlzIGlzIGR1ZSB0byBiZWluZyB2ZXJ5IGNhcmVmdWwg
YWJvdXQKcmVsYXRpdmUgZGlyZWN0b3JpZXMgYW5kIGdldHRpbmcgdmVyc2lvbmluZyBpbmZvIGZy
b20gQ0NOZXQKcHJvcGVydGllcy4KKDUpIElzIGEgaGFjayBhdCB0aGUgbW9tZW50IC0gd2UgbmVl
ZCB0byBtYWtlIHRoaXMgY2hhbmdhYmxlIHRocm91Z2ggdGhlIFVJCgpBY3R1YWxseSwgaXQgd2Fz
bid0IG11Y2ggZWZmb3J0IGF0IGFsbC4gV2l0aCBzb21lIGZlYXR1cmVzIGxpa2UKcHJvamVjdCBj
bG9uaW5nLCBhdXRvbWF0aWMgaW5pdGlhbCBjaGVja291dCBhbmQgVUktbWFuYWdhYmxlIHZlcnNp
b24KbnVtYmVycyBpdCB3b3VsZCBoYXZlIHRha2VuIGp1c3QgYSBjb3VwbGUgb2YgbWludXRlcy4g
SSB0aGluawppbnRlZ3JhdGluZyBDQ05ldCB3aXRoIFNDTSBicmFuY2ggcHJvY2VkdXJlcyB3b24n
dCBoYXBwZW4gZm9yIGEgd2hpbGUsCmJ1dCB3ZSBjYW4gZGVmaW5pdGVseSB0aGluayBhYm91dCBt
YWtpbmcgaXQgZWFzaWVyIHRvIGNyZWF0ZSAnc2libGluZycKcHJvamVjdHMuCgpNaWtlCgpPbiA5
LzMwLzA1LCBTdGVwaGVuIFR1bm5leSA8c3R1bm5leUByZXN1bWVtaXJyb3IuY29tPiB3cm90ZToK
Pgo+Cj4KPiBIZWxsbyBBbGwsCj4KPgo+Cj4gSSBoYXZlIGEgc29tZXdoYXQgc2ltcGxlIHF1ZXN0
aW9uIHRoYXQgaGFzIHNldmVyYWwgc29sdXRpb25zIHJlcXVpcmVkLiAgQW5kCj4gaXQgaGFzIGFs
bCBiZWVuIHNwYXduZWQgYnkgTWlrZSdzIHJlY2VudCBlbWFpbCBhYm91dCBicmFuY2hpbmcgQ0NO
ZXQgdG8KPiAxLjAuMC5YLCBhcyB3ZWxsIGFzIHRoZSBtYWluIHRydW5rIGJlaW5nIHVwZ3JhZGVk
IHRvIDEuMS4wLlguCj4KPgo+Cj4gSSB3YXMgd29uZGVyaW5nIGlmIGFueW9uZSBoYXMgY3JlYXRl
ZCBhIHNjcmlwdCB0byBhdXRvbWF0ZSBhdCBsZWFzdCBwYXJ0IG9mCj4gdGhpcyBwcm9jZXNzLgo+
Cj4gtyAgICAgICAgIFN0YXRlIGZpbGVzIG5lZWQgdG8gYmUgdXBkYXRlZCBmb3IgbmV3IHZlcnNp
b24gaW5mb3JtYXRpb24KPgo+ILcgICAgICAgICBCdWlsZCBTY3JpcHRzIG1heSBuZWVkIHRvIGJl
IHVwZGF0ZWQKPgo+ILcgICAgICAgICBCcmFuY2hpbmcgbmVlZHMgdG8gYmUgcGVyZm9ybWVkCj4K
PiC3ICAgICAgICAgSW4gc29tZSBjYXNlcywgbmV3IGNsaWVudCBzcGVjaWZpY2F0aW9ucyAqc2hv
dWxkKiBiZSBjcmVhdGVkIGZvcgo+IHRoZSByZWxlYXNlZCB2ZXJzaW9ucyBvZiB0aGUgcHJvZHVj
dHMKPgo+ILcgICAgICAgICBDQ05ldCBwcm9qZWN0cyBuZWVkIHRvIGJlIGNvcGllZCBmcm9tIHRo
ZSBvcmlnaW5hbCBhbmQgdXBkYXRlZCBzbwo+IHRoYXQgdGhlIHJlbGVhc2VkIHZlcnNpb24gaGFz
IGl0J3Mgb3duIHByb2plY3QKPgo+ILcgICAgICAgICCFICAoSSBrbm93IHRoZXJlJ3MgbW9yZSB0
aGF0IEknbSBub3QgZXZlbiB0aGlua2luZyBvZiBhdCB0aGUKPiBtb21lbnQpCj4KPgo+Cj4gQW55
aG93LCBkb2VzIGFueW9uZSBoYXZlIGFueSBpZGVhcyBvbiB0aGlzPyAgSSB3b3VsZCB0aGluayB0
aGF0IHRoaXMgd291bGQKPiBiZSBhbiBhd2Vzb21lIGFkZGl0aW9uIHRvIENDTmV0IGJlY2F1c2Us
IHdlbGwsIGJyYW5jaGluZyBpcyBhIGNvcm5lcnN0b25lCj4gbWV0aG9kb2xvZ3kgaW4gYSAiZ29v
ZCIgU0NNIHByb2Nlc3MuICBJIGtub3cgdGhhdCB0aGlzIHdvdWxkIGJlIGEKPiBmYXItcmVhY2hp
bmcgY2hhbmdlIGFzIHdlbGwgaWYgdGhpcyB3ZXJlIHRvIGJlIGludGVncmF0ZWQgZGlyZWN0bHkg
aW50bwo+IENDTmV0IGFzIHdlbGwuCj4KPgo+Cj4gQW55b25lIHRoaW5rIHRoYXQgdGhpcyBjYW4g
YmUgZG9uZSB3aXRoIGEgcmVhc29uYWJsZSBhbW91bnQgb2YgZWZmb3J0IGluc2lkZQo+IG9mIEND
TmV0IGluc3RlYWQgb2YgYW4gZXh0ZXJuYWwgVXRpbGl0eT8KPgo+Cj4KPiBUaGFua3MgZm9yIHJl
YWRpbmcgSgo+Cj4gU3RlcGhlbiBUdW5uZXkKPgo+IFNRQSBMZWFkCj4KPiBSZXN1bWUgTWlycm9y
IEluYy4KCgotLQptaWtlIHJvYmVydHMgfCBodHRwOi8vbWlrZXJvYmVydHMudGhvdWdodHdvcmtz
Lm5ldC8gfApodHRwOi8vd3d3LnRob3VnaHR3b3Jrcy5jb20vCg==

Hello All,

=20

I have a somewhat simple question that has several solutions required.
And it has all been spawned by Mike's recent email about branching CCNet
to 1.0.0.X, as well as the main trunk being upgraded to 1.1.0.X.

=20

I was wondering if anyone has created a script to automate at least part
of this process.

*         State files need to be updated for new version information

*         Build Scripts may need to be updated

*         Branching needs to be performed

*         In some cases, new client specifications *should* be created
for the released versions of the products

*         CCNet projects need to be copied from the original and updated
so that the released version has it's own project

*         ...  (I know there's more that I'm not even thinking of at the
moment)

=20

Anyhow, does anyone have any ideas on this?  I would think that this
would be an awesome addition to CCNet because, well, branching is a
cornerstone methodology in a "good" SCM process.  I know that this would
be a far-reaching change as well if this were to be integrated directly
into CCNet as well.

=20

Anyone think that this can be done with a reasonable amount of effort
inside of CCNet instead of an external Utility?

=20

Thanks for reading :-)

Stephen Tunney

SQA Lead

Resume Mirror Inc.

hi tim,

On 30/09/05, Tim Haughton <tim...@gm...> wrote:
> We've hit a weird bug in our epic effort to get synergy to play nice. I'm
> not sure where this is, but it *must* be a bug.

you're right, it does look like a parsing bug in the regular
expression matching for the SynergyParser.  when building the
modifications, it looks like the parser is getting the wrong change
number.  if you change your server's trace level to debug, you should
be able to capture the output that ccnet parses into modifications.=20
if you could send that out to the list then we can get to the bottom
of this regex weirdness.
cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

Hi all,

This an update to let you know of branching / versioning changes to
CCNet. This is important if you are providing patches to CCNet or
using the builds available from CCNetLive.

The main CCNet module in CVS is now branched for the 1.0.x series of
releases . This branch is called RB_1_0 (where RB stands for Release
Branch) .

Builds on CCNetLive available at
http://ccnetlive.thoughtworks.com/CCNet%2Dbuilds/ are now available
for both the branch (1.0.0.x) and trunk (1.1.0.x) Until we say
otherwise, the 1.1 series of builds should be considered unstable. If
you are using CCNet in production, you should err towards using the
1.0 series of builds.

CCNetLive itself now has separate projects for the 1.1 and 1.0 codelines.

Any changes that are required for the 1.0 series will be applied to
the branch and then merged to the trunk. In the normal run of things,
changes will not be merged from the trunk to the branch.

This is all being documented at
http://confluence.public.thoughtworks.org/display/CCNET/SCM+Policy

Mike

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

hi harold,
i've created a new issue on jira track to the application of the
bitkeeper patches:
http://jira.public.thoughtworks.org/browse/CCNET-572
feel free to add your comments.
cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

We've hit a weird bug in our epic effort to get synergy to play nice. I'm
not sure where this is, but it *must* be a bug.
 We can get CCNet to pick up changes, and successfully reconfigure and
build. We do however have a problem when it comes to labelling:
   [CruiseControl Server:Debug]:
[CruiseControl Server:Debug]: Command Interface @ NOTTDAC6P7G0J:3049:
192.168.102.144 <http://192.168.102.144> (current session)
[CruiseControl Server:Debug]: Database:
\\nottingham13\ccmdata\foo<file://nottingham13/ccmdata/foo>
[CruiseControl Server:Debug]:
[CruiseControl Server:Debug]: Current project:
'ngw_de0157~milligan_integrate'
[milligan:Debug]: Attempting to start process [C:\Program Files\Telelogic\C=
M
Synergy 6.3\bin\ccm.exe] in working directory
[w:\ngw_de0157\ngw_de0157~millig
an_integrate\ngw_de0157] with arguments [task /modify /description
"Integrated Successfully with CruiseControl.NET project 'milligan' build '3=
'
on 30/09/20
05 13:46:10"
"58,59,60,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,157,78,79,80"]
[CruiseControl Server:Debug]: Warning: Could not identify task 157
[CruiseControl Server:Debug]: Changed the description of task 58
[CruiseControl Server:Debug]: Changed the description of task 59
[CruiseControl Server:Debug]: Changed the description of task 60
[CruiseControl Server:Debug]: Changed the description of task 62
[CruiseControl Server:Debug]: Changed the description of task 63
[CruiseControl Server:Debug]: Changed the description of task 64
[CruiseControl Server:Debug]: Changed the description of task 65
[CruiseControl Server:Debug]: Changed the description of task 66
[CruiseControl Server:Debug]: Changed the description of task 67
[CruiseControl Server:Debug]: Changed the description of task 68
[CruiseControl Server:Debug]: Changed the description of task 69
[CruiseControl Server:Debug]: Changed the description of task 70
[CruiseControl Server:Debug]: Changed the description of task 71
[CruiseControl Server:Debug]: Changed the description of task 72
[CruiseControl Server:Debug]: Changed the description of task 73
[CruiseControl Server:Debug]: Changed the description of task 74
[CruiseControl Server:Debug]: Changed the description of task 75
[CruiseControl Server:Debug]: Changed the description of task 76
[CruiseControl Server:Debug]: Changed the description of task 78
[CruiseControl Server:Debug]: Changed the description of task 79
[CruiseControl Server:Debug]: Changed the description of task 80
[milligan:Warning]: Synergy wrote output to stderr: Warning: Could not
identify task 157
 [milligan:Error]: Exception: Exception occurred while labelling source
control provider.
----------
ThoughtWorks.CruiseControl.Core.CruiseControlException: Exception occurred
while labelling source control provider. --->
ThoughtWorks.CruiseControl.Core.Cr<http://ThoughtWorks.CruiseControl.Core.C=
r>
uiseControlException: Synergy source control operation failed.
Command: "C:\Program Files\Telelogic\CM Synergy 6.3\bin\ccm.exe" task
/modify /description "Integrated Successfully with CruiseControl.NET projec=
t
'milliga
n' build '3' on 30/09/2005 13:46:10"
"58,59,60,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,157,78,79,80"
Error Code: 1
Errors:
Warning: Could not identify task 157
 Changed the description of task 58
Changed the description of task 59
Changed the description of task 60
Changed the description of task 62
Changed the description of task 63
Changed the description of task 64
Changed the description of task 65
Changed the description of task 66
Changed the description of task 67
Changed the description of task 68
Changed the description of task 69
Changed the description of task 70
Changed the description of task 71
Changed the description of task 72
Changed the description of task 73
Changed the description of task 74
Changed the description of task 75
Changed the description of task 76
Changed the description of task 78
Changed the description of task 79
Changed the description of task 80
  at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.Telelogic.SynergyCommand.Exec=
ute(ProcessInfo
processInfo, Boolean failOnError)
at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.Telelogic.SynergyCommand.Exec=
ute(ProcessInfo
processInfo)
at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.Telelogic.Synergy.LabelSource=
Control(IIntegrationResult
result)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.LabelSourceControl(IIn=
tegrationResult
result)
--- End of inner exception stack trace ---
----------
 [milligan:Info]: Integration complete: 30/09/2005 14:06:29
   Now, it's throwing an exception because it can't find task 157.
Unsurprising since it's a new test database and the tasks don't go above 80
yet. Task 157. Now look at the project name:
 [CruiseControl Server:Debug]: Current project:
'ngw_de0157~milligan_integrate'
 It's too weird to be a coincidence. If we list the objects in the shared
folder, we see all the tasks that should be there, including task 77, but
not including task 157. Task 77 is being replaced by this suspiciously name=
d
Task 157. Those familiar with Synergy might know that you can't create task=
s
out of sequence. This seems like a candidate for a parsing bug somewhere. I
won't have time to look at it for again for a short while, but someone migh=
t
know where to start looking.
 Any suggestions?
 Regards,
 Tim Haughton

Graham Tackley wrote:

> CCTray is being a very poor windows citizen and writes its settings 
> file to the same directory as the executable -- this was to because 
> that's what old cctray did.  But it's pretty poor and easy to fix.
>
> Agree that it should write to the users profile instead, I'll add a 
> jira for this later when I'm on a faster internet connection.....

CCNET-569 created.

> g
>

hi steve,
i have a few more questions:
- the urltrigger seems to return true indicating that the url has
changed and that an integration should occur if there was some
exception connecting to the url.  is this really what we want to do?
- in the httpwrapper, in the Execute method we iterate over the http
headers to check for the existence of the "Last-Modified" header.=20
however, regardless of whether it exists or not we still return
HttpWrapperStatus.ContentReturned which will cause an integration to
be triggered.  maybe we don't need to worry too much about this as the
request.IfModifiedSince will cause an exception if the uri hasn't been
modified.  still, i'm finding it a bit confusing.
- do we need to use request.IfModifiedSince?  i personally don't like
the fact that it throws an exception if the uri has not been modified
since the specified time.  could we just check the last modified
header instead to see if the uri has been modified?

cheers,
owen.

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

hi steve,

On 29/09/05, ste...@th... <ste...@th...> wrote:
> Not at all, that was the main reason I wanted to get something to you to
> get some feedback.

great!  i'm glad you feel that way.

> The problem I have with this is more layers.  How do you intend to mock
> out the HttpWebResponse? This was why I split it like I did in the first
> place.  If you have to write a wrapper around the HttpWebResponse then
> this could add more complexity.  It is really a trade off between
> testability and usability I guess.

i agree.  and i'm struggling to come up with the best way to separate
concerns myself.  it would be much easier if ms implemented more
interfaces for its core classes.

> I was wondering that myself, but wanted to get something to you sooner
> to look at as I'm on vacation next week after which I will probably have
> forgotten most of this (due to playing too much World of Warcraft ;)).

thanks for that!  well, i'll try and get a preliminary changed version
checked in tonight for you to peruse, if you get the chance.
cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

Owen,

> i've started to go through the code and it looks good.  i=20
> have a few questions/comments if you don't mind.

Not at all, that was the main reason I wanted to get something to you to
get some feedback.

> httpwrapper:
> - i tried running the unit tests for the httpwrapper and 
> of them failed due to a timeout issue.  i'm also really=20
> concerned about how long the tests take to run.  it will also=20
> be a source of annoyance trying to run the ccnet unit tests=20
> if i'm disconnected and these tests keep failing.  so, IHMO,=20
> i think that it is ok not to test the httpwrapper *so long=20
> as* it is really only a thin wrapper around the=20
> httprequest/response objects.  however, to get there, i think=20
> that it might be important to move some of the logic back=20
> into the url trigger.  what do you think?

In a way this was always going to be an issue with unit testing this
piece.  See below for the HttpWebReponse answer for some extra details.

> - do the httprequest and httpresponse variables need to be=20
> members on the class?  they are only used within the scope of=20
> the Execute method and they are not reused across calls. =20
> also, if we make them into local variables, then you don't=20
> have to worry about making the class implement IDisposable.

That is fine.  When I first started to write this I did it slightly
differently and this is probably why they were private members.

> - i'm not super comfortable with the httpwrapper class=20
> logging and swallowing exceptions.  i would also rather have=20
> that decision reside in the trigger where it can be more=20
> easily testable.  what if the httpwrapper simply returned a=20
> HttpWebResponse or a wrapper around it?=20
> this keeps the httpwrapper very generic and moves the last=20
> modified header logic into the trigger where it belongs.

The problem I have with this is more layers.  How do you intend to mock
out the HttpWebResponse? This was why I split it like I did in the first
place.  If you have to write a wrapper around the HttpWebResponse then
this could add more complexity.  It is really a trade off between
testability and usability I guess.

> urltrigger:
> - i've taken the liberty of converting the properties into=20
> public fields.  i know it's more of a philosophical argument,=20
> but i've gotten in the habit of converting simple properties=20
> into fields as it really reduces the amount of code and=20
> improves readibility.  i can always go and transparently=20
> convert the field into a property at some point later if i need it.

This was based on the IntervalTrigger so I just tried to keep in inline
with that ;)

> - the CheckUrlForChange method seems to be both validating=20
> the url and executing the http request.  it seems to me that=20
> we could integrate the url validating into the setter for the=20
> Url property.  as far as i can tell, this is the only point=20
> that the property is modified.  this provides the advantage=20
> of alerting the user that the url is invalid right as the=20
> server starts up, instead of at the point where the trigger fires.

I was wondering that myself, but wanted to get something to you sooner
to look at as I'm on vacation next week after which I will probably have
forgotten most of this (due to playing too much World of Warcraft ;)). =20

Steve

hi steve,
i've started to go through the code and it looks good.  i have a few
questions/comments if you don't mind.

httpwrapper:
- i tried running the unit tests for the httpwrapper and one of them
failed due to a timeout issue.  i'm also really concerned about how
long the tests take to run.  it will also be a source of annoyance
trying to run the ccnet unit tests if i'm disconnected and these tests
keep failing.  so, IHMO, i think that it is ok not to test the
httpwrapper *so long as* it is really only a thin wrapper around the
httprequest/response objects.  however, to get there, i think that it
might be important to move some of the logic back into the url
trigger.  what do you think?
- do the httprequest and httpresponse variables need to be members on
the class?  they are only used within the scope of the Execute method
and they are not reused across calls.  also, if we make them into
local variables, then you don't have to worry about making the class
implement IDisposable.
- i'm not super comfortable with the httpwrapper class logging and
swallowing exceptions.  i would also rather have that decision reside
in the trigger where it can be more easily testable.  what if the
httpwrapper simply returned a HttpWebResponse or a wrapper around it?=20
this keeps the httpwrapper very generic and moves the last modified
header logic into the trigger where it belongs.

urltrigger:
- i've taken the liberty of converting the properties into public
fields.  i know it's more of a philosophical argument, but i've gotten
in the habit of converting simple properties into fields as it really
reduces the amount of code and improves readibility.  i can always go
and transparently convert the field into a property at some point
later if i need it.
- the CheckUrlForChange method seems to be both validating the url and
executing the http request.  it seems to me that we could integrate
the url validating into the setter for the Url property.  as far as i
can tell, this is the only point that the property is modified.  this
provides the advantage of alerting the user that the url is invalid
right as the server starts up, instead of at the point where the
trigger fires.

please let me know your thoughts on these suggested changes.
cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

Mike wrote:

>Which reminds me, where is the config for CCTray stored currently?
>Maybe that should also be stored in the user profile if it isn't
>already. It could probably share the same config file as the add-in
>(?)
>
>  
>
CCTray is being a very poor windows citizen and writes its settings file 
to the same directory as the executable -- this was to because that's 
what old cctray did.  But it's pretty poor and easy to fix.

Agree that it should write to the users profile instead, I'll add a jira 
for this later when I'm on a faster internet connection.....

>Certainly, I'd like to move more to a situation where we are being
>'better windows citizens', and not having mutable files under the
>CCNet Installation directory.
>
>  
>
g

hi harold,

On 27/09/05, Harold L Hunt <hu...@st...> wrote:
> The two attached files add support for BitKeeper to CC.Net.  They should
> be dropped in:

thanks for the patch!  looks good.  however, before i can commit it,
we need to create some unit tests for the provider.  we have
established a standard for the project that all code needs high unit
test coverage before we can commit it.  this is what allows us to
support and update code from a variety of contributors without having
to worry about full regression tests for each release -- which is
tricky both for the effort it would entail and to have coverage for
the number of systems that we integrate with.

now, i can write the unit tests; however, to do so, i will need some
things from you:
- examples of valid bitkeeper command lines for all operations to be
performed by the provider (ie. commands for getting source, detecting
modifications, and labelling)
- examples of the modification output returned by bitkeeper that are
parsed by the history parser.  ideally, these examples should contain
added, modified and deleted files -- and any other boundary conditions
that you can think of that would be worthwhile testing.

sorry to be a stickler about this.
cheers,
owen.

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

hi steve,

On 28/09/05, ste...@th... <ste...@th...> wrote:
> Here is the first draft of the UrlTrigger stuff talked about last week.

thanks for the patch!  i haven't had the chance to look at it yet, but
i hope to get to it tomorrow.  i've created a new issue on jira to
track this issue:
http://jira.public.thoughtworks.org/browse/CCNET-566

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

thanks andy!  i can now work on processing your contribution.  once
it's done, you should see you name up on the contributors page (remind
me if i forget).
http://confluence.public.thoughtworks.org/display/CCNET/Project+Team
cheers,
owen.

On 28/09/05, Andy Johnstone <ajo...@ca...> wrote:
> I am fine with the contribution agreement.
>
> My email is ajo...@ca...
>
>
> Thanks
> Andy
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>


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

great!  thanks steve.
cheers,
owen.

On 28/09/05, ste...@th... <ste...@th...> wrote:
> My company are fine with the Contributor License Agreement as of 28th
> September 2005, as found at
> http://confluence.public.thoughtworks.org/download/attachments/1178/CC.N
> ET+Contributor+License+Agreement.doc?version=3D1
>
> Steve
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>


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

Hi=20Steve,

Glad=20to=20see=20this=20can=20be=20added!=20

I=20modified=20my=20local=20copy=20to=20add=20a=20modificationDelaySeconds=
=20property=20(as
the=20previously=20discussed=20simplest=20solution=20to=20the=20problem)=20=
and=20this=20is
working=20fine=20for=20me.

My=20changes=20(aside=20from=20the=20property,=20which=20you=20can=20imagi=
ne)=20make=20the
logic=20in=20ShouldRunIntegration=20look=20a=20bit=20like=20this:

if=20(!CheckUrlForChange())
{
=20=20if(DateTime.Now=20>
lastChangesTime.AddSeconds(modificationDelaySeconds))
=20=20{
=20=20=20=20Log.Debug("CheckUrlForChange()=20returned=20false");
=20=20=20=20//=20Fake=20an=20integration=20complete=20to=20wait=20another=20=
interval
=20=20=20=20IntegrationCompleted();=20
=20=20=20=20Log.Info("Integration=20Complete:=20"=20+=20lastIntegrationCom=
pleteTime);
=20=20=20=20return=20BuildCondition.NoBuild;
=20=20}
=20=20else
=20=20=20=20Log.Info("URL=20Trigger:=20Still=20inside=20modificationDelayS=
econds");
}
else
{
=20=20//=20If=20we=20saw=20real=20changes=20we=20update=20lastChangesTime.=

=20=20lastChangesTime=20=3D=20DateTime.Now;
}

I'm=20sure=20e-mail=20wrapping=20will=20mess=20this=20up!

I=20still=20think=20there=20must=20be=20a=20cleaner=20solution,=20but=20as=
=20I=20said,=20this=20does
the=20job=20for=20me.

Simon.

________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20MessageLabs.

Owen (et al),

Here is the first draft of the UrlTrigger stuff talked about last week.
This is the original version that doesn't implement any of the
modificationDelay discussions that were talked about (this can be added
once we have things sorted).

The first 2 files are HttpWrapper.cs and HttpWrapperStatus.cs.  These
belongs in project\core\util
The next file is the unit tests for the HttpWrapper.  This belongs in
projects\core\UnitTests\Core\Util
The next file is the trigger itself, UrlTrigger.cs and this belongs in
project\core\Triggers
The final file is the trigger unit test file and this belongs in
project\core\UnitTests\Core\Triggers

What I'm really looking for at the moment is any comments on what I've
done.  I need to do some testing with this version before we finally
commmit things.

Here is a bit of documentation I had previously on this.  It will need
some work though ( I need to dig up the svn scripts we have as well ).

------------------------------------------------------------------------
---------------------------------------------------------
You need to edit you CVSROOT/loginfo file to get the post commit action
to work.  On one of our projects we have the following:

----------------------------------------------------------
ALL     /usr/bin/cvs-ccnet-notify allmodules
^MODULENAME\(/\|$\)  /usr/bin/cvs-ccnet-notify MODULENAME
----------------------------------------------------------

Which basically means for any modules that change update run the
cvs-ccnet-notify script telling it to update the file allmodules.  The
second line allows you to be a bit more granular by checking for
specific modules.

The final part is the cvs-ccnet-notify script which is:

---------------------------
#!/bin/sh
cat > /wwwroot/scm/$1
chmod a+rw /wwwroot/scm/$1
---------------------------

The path you need to set to be a folder somewhere on you webserver.
What should happen is that the filename passed as the parameter to the
script ends up containing the contents of the commit log message.  You
will obviously need to sort out the proper permissions for the web
folder.

To use the trigger you need the following in your ccnet.config file:

  <triggers>
    <urlTrigger seconds=3D"60" buildCondition=3D"IfModificationExists"
url=3D"http://hostname/scm/modulename" />
  </triggers>

And that should be it.

Things to remember / check:
1) You can manually check that the post commit scripts are running by
checking that the file is being updated on the webserver (one of the
advantages of pushing the log message into the file).
2) When CCNET starts up it should print the URL being used.=20
3) Everytime it checks the URL you should get a message saying that URL
Trigger is checking the following URL.  If the URL changes it should
then move onto a checking modifications and query CVS.
4) On first startup it will always check CVS as it doesn't have any
history on the URL so treats it as a change.
------------------------------------------------------------------------
---------------------------------------------------------

Steve

My company are fine with the Contributor License Agreement as of 28th
September 2005, as found at
http://confluence.public.thoughtworks.org/download/attachments/1178/CC.N
ET+Contributor+License+Agreement.doc?version=3D1

Steve

I am fine with the contribution agreement.

My email is ajo...@ca...=20


Thanks
Andy

Oh yeah, and add the files to the core project's sourcecontrol 
directory, with the attached patch.

Harold

Harold L Hunt wrote:
> The two attached files add support for BitKeeper to CC.Net.  They should 
> be dropped in:
> 
> ccnet/project/core/sourcecontrol/
> 
> 
> No other files were changed to add the BitKeeper support.
> 
> 
> There are instructions for the BitKeeper support here:
> 
> http://confluence.public.thoughtworks.org/display/CCNET/BitKeeper+Source+Control+Block 
> 
> 
> 
> As noted in the instructions, only bkd and local filesystem access have 
> been tested at this time; I specifically know that BK hangs 
> intermittently when running 'bk changes -R -v' when using MinGW's 
> ssh.exe, which is why ssh access is not yet supported in this version.
> 
> For best results, but sure to use BitKeeper 3.2.6, as 3.2.5 and earlier 
> had some intermittent file locking problems on Windows (particularly on 
> Windows 2000) that occasionally cause BK to get stuck with CC.Net; 3.2.6 
> fixed all of these issues and I've not had any problems with the CC.Net 
> integration since.
> 
> Harold
> 
> 
> ------------------------------------------------------------------------
> 
> using System;
> using System.Collections;
> using System.IO;
> using System.Globalization;
> using System.Text.RegularExpressions;
> 
> namespace ThoughtWorks.CruiseControl.Core.Sourcecontrol
> {
> 	public class BitKeeperHistoryParser : IHistoryParser
> 	{
> 		/// <summary>
> 		/// This is the keyword that precedes a change set in the bk log information.
> 		/// </summary>
> 		private static readonly string BK_CHANGESET_LINE = "ChangeSet";
> 
> 		private string _currentLine;
> 		private string _workingFileName;
> 
> 		public void Init()
> 		{
> 			_currentLine = string.Empty;
> 			_workingFileName = string.Empty;
> 		}
> 
> 		public Modification[] Parse(TextReader bkLog, DateTime from, DateTime to)
> 		{
> 			// Read to the first ChangeSet. The first entry in the log
> 			// information will begin with this line. If no ChangeSet file
> 			// lines are found then there is nothing to do.
> 			_currentLine = ReadToNotPast(bkLog, BK_CHANGESET_LINE, null);
> 			ArrayList mods = new ArrayList();
> 
> 			while (_currentLine != null)
> 			{
> 				// Parse the ChangeSet entry and read till next ChangeSet
> 				Modification mod = ParseEntry(bkLog);
> 
> 				// Add all the modifications to the local list.
> 				mods.Add(mod);
> 
> 				// Read to the next non-blank line.
> 				_currentLine = bkLog.ReadLine();
> 			}
> 
> 			return (Modification[]) mods.ToArray(typeof (Modification));
> 		}
> 
> 		internal Modification ParseEntry(TextReader bkLog)
> 		{
> 			// Example: "ChangeSet\n1.201 05/09/08 14:52:49 hunth@spankyham. +1 -0\nComments"
> 			Regex re = new Regex(@"(?<version>[\d.]+)\s+(?<datetime>\d{2,4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2})\s+(?<username>\S+).*", RegexOptions.Compiled);
> 
> 			Modification mod = new Modification();
> 
> 			// Get file name information
> 			char[] trims = new char[2];
> 			trims[0] = ' ';
> 			trims[1] = '\t';
> 			_currentLine = _currentLine.TrimStart(trims);
> 			mod.FileName = ParseFileName(_currentLine);
> 			mod.FolderName = ParseFolderName(_currentLine);
> 
> 			// Get the next line with change info
> 			_currentLine = bkLog.ReadLine();
> 
> 			Match match = re.Match(_currentLine);
> 			if (!match.Success)
> 				throw new Exception("foo");
> 
> 			mod.ModifiedTime = ParseDate(match.Result("${datetime}"));
> 			mod.Type = "Modified";
> 			mod.UserName = match.Result("${username}");
> 			mod.Version = match.Result("${version}");;
> 
> 			// Read all lines of the comment and flatten them
> 			mod.Comment = ParseComment(bkLog);
> 
> 			return mod;
> 		}
> 
> 		internal string ReadToNotPast(TextReader reader, string startsWith, string notPast)
> 		{
> 			_currentLine = reader.ReadLine();
> 			while (_currentLine != null && !_currentLine.StartsWith(startsWith))
> 			{
> 				if ((notPast != null) && _currentLine.StartsWith(notPast))
> 				{
> 					return null;
> 				}
> 				_currentLine = reader.ReadLine();
> 			}
> 			return _currentLine;
> 		}
> 
> 		private DateTime ParseDate(string date)
> 		{
> 			// BK is funny - we can't guarantee that the year will be two or four digits,
> 			// so we have to check how many digits we got and deal with it
> 
> 			string format;
> 			int firstSep = date.IndexOf("/");
> 			if (firstSep == 4)
> 				format = "yyyy'/'MM'/'dd HH:mm:ss";
> 			else
> 				format = "yy'/'MM'/'dd HH:mm:ss";
> 
> 			return DateTime.ParseExact(date, format, DateTimeFormatInfo.InvariantInfo);
> 		}
> 
> 		internal string ParseComment(TextReader bkLog)
> 		{
> 			// All the text from now to the next blank line constitues the comment
> 			string message = string.Empty;
> 			char[] trimChars = new char[1];
> 			bool multiLine = false;
> 
> 			trimChars[0] = ' ';
> 
> 			_currentLine = bkLog.ReadLine().TrimStart(trimChars);
> 			while (_currentLine != null && _currentLine.Length != 0)
> 			{
> 				if (multiLine)
> 				{
> 					message += System.Environment.NewLine;
> 				}
> 				else
> 				{
> 					multiLine = true;
> 				}
> 				message += _currentLine;
> 
> 				// Go to the next line.
> 				_currentLine = bkLog.ReadLine();
> 			}
> 			return message;
> 		}
> 
> 		internal string ParseFileName(string workingFileName)
> 		{
> 			int lastSlashIndex = workingFileName.LastIndexOf("/");
> 			return workingFileName.Substring(lastSlashIndex + 1);
> 		}
> 
> 		internal string ParseFolderName(string workingFileName)
> 		{
> 			int lastSlashIndex = workingFileName.LastIndexOf("/");
> 			string folderName = string.Empty;
> 			if (lastSlashIndex != -1)
> 			{
> 				folderName = workingFileName.Substring(0, lastSlashIndex);
> 			}
> 			return folderName;
> 		}
> 
> 		internal string ParseType(string stateKeyword, bool isAdded)
> 		{
> 			// TODO: ParseType
> 			return "modified";
> 		}
> 
> 		internal bool IsAdded(string[] tokens)
> 		{
> 			// if no lines keyword then file is added
> 			bool hasLinesKeyword = tokens.Length > 13 && tokens[13].StartsWith("lines:");
> 			return !hasLinesKeyword;
> 		}
> 	}
> }
> 
> 
> ------------------------------------------------------------------------
> 
> using System;
> using System.Collections;
> using System.Globalization;
> using System.IO;
> using Exortech.NetReflector;
> using ThoughtWorks.CruiseControl.Core.Util;
> 
> namespace ThoughtWorks.CruiseControl.Core.Sourcecontrol
> {
> 	[ReflectorType("bitkeeper")]
> 	public class BitKeeper : ProcessSourceControl
> 	{
> 		public const string DefaultExecutable = @"C:\Program Files\BitKeeper\bk.exe";
> 
> 		public BitKeeper(ProcessExecutor executor, IHistoryParser parser) : base(parser, executor)
> 		{}
> 
> 		public BitKeeper() : base(new BitKeeperHistoryParser())
> 		{}
> 
> 		/// <summary>
> 		/// Absolute, DOS-style, path to bk.exe
> 		/// </summary>
> 		[ReflectorProperty("executable", Required=false)]
> 		public string Executable = DefaultExecutable;
> 
> 		/// <summary>
> 		/// Absolute, DOS-style, path to permanent BK repository
> 		/// </summary>
> 		[ReflectorProperty("workingDirectory", Required=true)]
> 		public string WorkingDirectory = string.Empty;
> 
> #if HOME_DIRECTORY
> 		/// <summary>
> 		/// The directory that contains the ".ssh" directory
> 		/// </summary>
> 		[ReflectorProperty("homeDirectory", Required=false)]
> 		public string HomeDirectory = string.Empty;
> #endif
> 
> 		/// <summary>
> 		/// Add BK tag on successful build
> 		/// </summary>
> 		[ReflectorProperty("tagOnSuccess", Required = false)]
> 		public bool TagOnSuccess = false;
> 
> 		/// <summary>
> 		/// Automatically pull latest source into permanent BK repository
> 		/// </summary>
> 		[ReflectorProperty("autoGetSource", Required = false)]
> 		public bool AutoGetSource = false;
> 
> 		/// <summary>
> 		/// Include history of each file, rather than just ChangeSets
> 		/// </summary>
> 		[ReflectorProperty("fileHistory", Required = false)]
> 		public bool FileHistory = false;
> 
> 		/// <summary>
> 		/// Make a clone of the permanent BK repository into the designated path
> 		/// The, DOS-style, path can be relative to WorkingDirectory or absolute
> 		/// </summary>
> 		[ReflectorProperty("cloneTo", Required = false)]
> 		public string CloneTo = string.Empty;
> 
> 		public override Modification[] GetModifications(IIntegrationResult from, IIntegrationResult to)
> 		{
> 			ProcessResult result = Execute(NewHistoryProcessInfo());
> 
> 			Modification[] modifications = ParseModifications(result, from.StartTime, to.StartTime);
> 			
> 			return modifications;
> 		}
> 
> 		public override void LabelSourceControl(IIntegrationResult result)
> 		{
> 			if (TagOnSuccess && result.Succeeded)
> 			{
> 				Execute(NewLabelProcessInfo(result));
> 				Execute(NewPushProcessInfo());
> 			}
> 		}
> 
> 		public override void GetSource(IIntegrationResult result)
> 		{
> 			if (AutoGetSource)
> 			{
> 				ProcessInfo info = NewProcessInfo(BuildGetSourceArguments());
> 				Log.Info(string.Format("Getting source from BitKeeper: {0} {1}", info.FileName, info.Arguments));
> 				Execute(info);
> 
> 				if (CloneTo != string.Empty)
> 				{
> 					string clonePath = CloneTo;
> 
> 					// Prepend working directory if path was not absolute
> 					if (!Path.IsPathRooted(clonePath))
> 						clonePath = Path.Combine(WorkingDirectory, CloneTo);
> 					clonePath = Path.GetFullPath(clonePath);
> 
> 					// Delete old destination
> 					DirectoryInfo di = new DirectoryInfo(clonePath);
> 					try
> 					{
> 						if (di.Exists)
> 							new Util.IoService().DeleteIncludingReadOnlyObjects(clonePath);
> 					}
> 					catch {}
> 
> 					ProcessInfo ctInfo = NewProcessInfo(BuildCloneToArguments());
> 					Log.Info(string.Format("Cloning source to: {0}", clonePath));
> 					Execute(ctInfo);
> 				}
> 			}
> 		}
> 
> 		private ProcessInfo NewLabelProcessInfo(IIntegrationResult result)
> 		{
> 			return NewProcessInfo(BuildTagProcessArgs(result.Label));
> 		}
> 
> 		private string BuildTagProcessArgs(string label)
> 		{
> 			ProcessArgumentBuilder buffer = new ProcessArgumentBuilder();
> 			buffer.AppendArgument("tag");
> 			buffer.AppendArgument(label);
> 			return buffer.ToString();
> 		}
> 
> 		private ProcessInfo NewPushProcessInfo()
> 		{
> 			return NewProcessInfo(BuildPushProcessArgs());
> 		}
> 
> 		private string BuildPushProcessArgs()
> 		{
> 			ProcessArgumentBuilder buffer = new ProcessArgumentBuilder();
> 			buffer.AppendArgument("push");
> 			return buffer.ToString();
> 		}
> 
> 		private ProcessInfo NewHistoryProcessInfo()
> 		{
> 			return NewProcessInfo(BuildHistoryProcessArgs());
> 		}
> 
> 		private string BuildHistoryProcessArgs()
> 		{
> 			ProcessArgumentBuilder buffer = new ProcessArgumentBuilder();
> 			buffer.AppendArgument("changes");
> 			buffer.AppendArgument("-R");
> 			if (FileHistory)
> 				buffer.AppendArgument("-v");
> 			return buffer.ToString();
> 		}
> 
> 		private string BuildGetSourceArguments()
> 		{
> 			ProcessArgumentBuilder buffer = new ProcessArgumentBuilder();
> 			buffer.Append("pull");
> 			return buffer.ToString();
> 		}
> 
> 		private string BuildCloneToArguments()
> 		{
> 			ProcessArgumentBuilder buffer = new ProcessArgumentBuilder();
> 			buffer.AppendArgument("clone");
> 			buffer.AppendArgument(".");
> 			buffer.AppendArgument(CloneTo);
> 			return buffer.ToString();
> 		}
> 
> 		private string SurroundInQuotesIfContainsSpace(string value)
> 		{
> 			if (! StringUtil.IsBlank(value) && value.IndexOf(' ') >= 0)
> 				return string.Format(@"""{0}""", value);
> 			return value;
> 		}
> 
> 		private ProcessInfo NewProcessInfo(string args)
> 		{
> 			ProcessInfo pi = new ProcessInfo(Executable, args, WorkingDirectory);
> 
> 			// Needed to disable the pager for bk commands, which causes infinite hangs
> 			pi.EnvironmentVariables.Add("PAGER", "cat");
> 
> #if HOME_DIRECTORY
> 			// Set HOME directory so that ssh can find its files
> 			if (this.HomeDirectory != string.Empty)
> 				pi.EnvironmentVariables.Add("HOME", this.HomeDirectory);
> #endif
> 
> 			return pi;
> 		}
> 	}
> }

The two attached files add support for BitKeeper to CC.Net.  They should 
be dropped in:

ccnet/project/core/sourcecontrol/


No other files were changed to add the BitKeeper support.


There are instructions for the BitKeeper support here:

http://confluence.public.thoughtworks.org/display/CCNET/BitKeeper+Source+Control+Block


As noted in the instructions, only bkd and local filesystem access have 
been tested at this time; I specifically know that BK hangs 
intermittently when running 'bk changes -R -v' when using MinGW's 
ssh.exe, which is why ssh access is not yet supported in this version.

For best results, but sure to use BitKeeper 3.2.6, as 3.2.5 and earlier 
had some intermittent file locking problems on Windows (particularly on 
Windows 2000) that occasionally cause BK to get stuck with CC.Net; 3.2.6 
fixed all of these issues and I've not had any problems with the CC.Net 
integration since.

Harold

On 27/09/05, Harold L Hunt <hu...@st...> wrote:
> Thanks for setting me up!
>
> I created an initial BitKeeper Source Control Block page:
>
> http://confluence.public.thoughtworks.org/display/CCNET/BitKeeper+Source+=
Control+Block
>
> As soon as anonymous CVS is working again I'll send my patch.

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