We had similar issues - though we use VSS (via VSSConnect), rather than CVS - we have a lot of projects and the overhead on the SCC server is just crazy (no real fault of CCNET asuch).
We have a single build project which updates a local folder - using queue locking to ensure that it doesn't overlap with any other builds. This runs every few minutes and all the other build projects trigger from checking the filesystem. It's not 100% ideal, but it works a lot better than having lots of projects battling for SCCP resources and/or aggregating projects (we prefer to keep the modules fully spearated and report on them separately in CCTRAY/Dashboard). Perhaps if this is becoming a common issue the right thing to do would be to look towards implementing some sort of SCC-Proxy in CCNET itself? Cheers, -- Matt Chatterley Mattched IT Ltd http://www.mattchedit.com Skype: mattchedit UK Registered Company: 05861949 2009/12/16 Parrish, Ken <[email protected]> > We have a similar scenario--a repository and build server with over 100 > separate buildable components and branches. > > Our approach is to use Nant to do the heavy lifting and orchestrate the > builds. We have our Nant scripts organized in a hierarchical directory tree > so that we can build any branch of the tree with a single command. > > Using this infrastructure, we then set up 8 - 10 projects in > CruiseControl.NET. Doing so makes managing the load on the source code > control server (Subversion in our case) much easier, and allows better > control over concurrency issues with multiple builds running simultaneously > on our build server. As well, controlling file system and Subversion > locking contention has been easier (but still not a simple task). > > In general, our system is designed so as to minimize the size and > complexity of the CruiseControl.NET configuration file and off load the > configuration and build management to Nant (and the actual building to > MSBuild). Nant is much better suited to these tasks, is extensible and far > more easily centralized. > > Hope this helps. > > Ken Parrish > Gomez, Inc. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Leszek Ciesielski > Sent: Tuesday, December 15, 2009 3:30 PM > To: [email protected] > Subject: Re: [ccnet-user] Throttling CVS whilst allowing simultaneous > builds > > Did you try grouping projects into several queues, one per processor? > > On Tue, Dec 15, 2009 at 5:38 PM, Jon Rimmer <[email protected]> wrote: > > Hi, > > > > I have a CruiseControl.NET server with quite a large number of > > projects, around 170, all pulling from the same CVS server. Initially, > > each project had a separate queue, but this was resulting in a large > > number of concurrent CVS instances, which seemed to be overloading the > > server and resulting in failed builds. To address the problem, I moved > > all the projects onto a single queue and greatly increased the > > interval between continuous integration checks/builds. This has > > resolved the failed builds, but I now have the problem that, because > > they are all on the same queue, all the projects are blocking each > > other, even when they are not accessing CVS. Ideally, I would like to > > be able to throttle CVS connections, whilst still allowing projects to > > build simultaneously. Can anybody suggest an approach that would allow > > this? > > > > Jon > > >
