Dave, Yes - each project has its own workingDirectory and artifactDirectory. Each of the projects have their own application code to compile, but they share a few libraries. Perhaps that's what is causing the lock contention - I'll look closer. I'll test trying to svn update the projects simultaneously from outside CC.net, too, and see if I still get the same lock issue - that's a good idea.
Regarding parallel builds - early on when I was first setting up cc.net, I had each project build on its own cycle and queue, and they would often end up overlapping and build concurrently. I didn't take any official timings, but it didn't seem to cause much overhead for each build (which I was surprised to see). I ended up building all of the projects sequentially in a single queue because it was easier for me to guarantee all the projects had the same CCNetLabel - which was more important at the time, then getting all the projects to build faster. Now that I am more familiar with CC.Net, I'm revisiting the goal of building all projects concurrently for faster total build time. Our build server has two processors, so we should be able to get some benefits from parallelization. I guess I can run some tests with the source control block commented out, to remove the lock issue, and see how much overhead it takes to build them all at the same time - to see if it's worth continuing down this path thanks for the response Michaeal On Nov 28, 11:23 pm, David Cameron <[email protected]> wrote: > Hi Michael > > The update operation that the source control blocks need to do shouldn't > cause a lock. Is each project using a separate working directory from the > other projects? If two regular clients try to do a checkout at the same time > without having cc.net involved, do you get the same problem? What is the > error message from subversion? > > I understand that if I put all the projects in the same queue, they > > > will build sequentially, so this won't happen. But, each project takes > > a while to build, and it would be nice to build them concurrently, for > > faster total build time. > > This depends a lot on your particular circumstances, but parallel builds may > not give you faster total build time. If the builds are happening on the > same server and drive they will compete for disk access. The competition > generates overhead that means the total build time will actually be longer. > Still, your bottleneck may be somewhere else, so it is worth a try in your > environment. > > Dave Cameron -http://intwoplacesatonce.com > CruiseControl.NET -http://ccnet.thoughtworks.com
