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
