SVN uses the term "lock" in multiple ways. This looks like you're getting a "locked" working copy because 2 SVN processes are trying to update it simultaneously.
One possible solution would be to create a project just to update the common working copy with a null task (and possibly project triggers to make your other 4 projects build). Another possibility would be to disable "Auto Get Source" in the project block and update the common are in the build script for each of the 4 projects. Otherwise, creating separate working copies or using externals will probably be you best bet. Good Luck, Tom On Nov 29, 6:36 pm, Michael <[email protected]> wrote: > Dave, > The shared library is not significantly big so checking out four > separate copies, one for each project, is possible but does make the > build a little more complicated. I am not doing this now - everything > is in a single checkout of the svn repository. I can look into this > option, but would like to explore other ideas first - like perhaps I'm > not setting up my source control block properly. > > I'm not familiar with the "svn:external" option. Could you explain > what benefit this offers? > > To answer your question, the lock is client-side, and all four > projects are only doing an update (read only) - none are committing at > the time. I'm running CC.Net 1.4.4.83. Here's the exact error message > I'm getting > > ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control > operation failed: svn: Working copy 'C:\Development\SVN\FW\trunk > \Common' locked svn: run 'svn cleanup' to remove locks (type 'svn help > cleanup' for details) . Process command: svn update "C:\Development\SVN > \FW\trunk\Common" --username xxxx --password xxxx --non-interactive -- > no-auth-cache > at > ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute > (ProcessInfo processInfo) > at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Svn.GetSource > (IIntegrationResult result) > at > ThoughtWorks.CruiseControl.Core.Sourcecontrol.MultiSourceControl.GetSource > (IIntegrationResult result) > at > ThoughtWorks.CruiseControl.Core.Sourcecontrol.FilteredSourceControl.GetSource > (IIntegrationResult result) > at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Build > (IIntegrationResult result) at > ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate > (IntegrationRequest request) > > The source control block I'm using is the following. I made the block > a preprocessor define element and replace the var.dir.products.xxx > variables with the path and name for each of the four projects, in > their respective <scope> tags. > > <sourceControlProvider type="multi"> > <sourceControls> > <svn> > <trunkUrl>$(var.dir.products.svn)/$(product.name)/trunk/ > sw</trunkUrl> > <workingDirectory>$(var.dir.products.local)\$(product.name) > \trunk\sw</workingDirectory> > <cleanUp>true</cleanUp> > </svn> > <svn> > <trunkUrl>$(var.dir.common.svn)</trunkUrl> > <workingDirectory>$(var.dir.common.local)</ > workingDirectory> > <cleanUp>true</cleanUp> > </svn> > </sourceControls> > </sourceControlProvider> > > Am I perhaps mis-configuring the source control block? The <cleanUp> > tag never really seemed to do anything, that I could tell, anyway > > Thanks for your help with this > > Michael > > On Nov 29, 12:32 pm, David Cameron <[email protected]> wrote: > > > > > inline... > > > On Mon, Nov 30, 2009 at 4:33 AM, Michael <[email protected]> wrote: > > > Regarding building in parallel: > > > I have four separate projects, which when run sequentially in a single > > > queue take about 5-6minutes to build, each. So the total build time is > > > roughly 20-25 minutes. > > > I commented out the source control block, to eliminate the svn lock > > > error for now, and let each project build in its own queue, so they > > > will build concurrently. There was some overhead induced - each > > > project takes about 7 minutes now. But, the total build time for all > > > projects is now 7-8 minutes, versus the original 20-25 minutes - which > > > is significant when a developer is waiting to see the build results. > > > Interesting to know that there can be benefits to running them in parallel! > > > > So, I revisited the svn lock issue. All four projects monitor changes > > > in their respective application level source directories - which are > > > completely independent. But, they also monitor changes to a common > > > library directory - which is what causes the svn lock error. I'm not > > > sure how to get around this. Each application project needs to monitor > > > changes to both locations to trigger. > > > Unless the library directory is truly massive, checking out four different > > working copies of it is an easy fix. Unless you are doing this already and > > I've misunderstood? Another alternative may be to use an svn:external so > > that each project appears to have it's own copy of the libraries in the > > tree. I'm not too sure though if this will resolve the issue. > > > I am confused by one thing: is this lock a server-side phenomenon or > > client-side? There should only be a server-side lock if one of the builds is > > committing changes to the server -- possibly as a result of a tag. If there > > are only reads happening, then locks should only possibly occur on the > > client side. What are the last svn operations visible in the ccnet.log file? > > > Dave Cameron -http://intwoplacesatonce.com > > CruiseControl.NET -http://ccnet.thoughtworks.com- Hide quoted text - > > - Show quoted text -
