Tom, This brings up another question of mine - more on CI strategy and policies. I'm still new to CI, so please forgive me if my question has a well known answer.
I actually already do have a separate project which just monitors all of the source code for changes, performs an svn update followed by just a labeller task. The publisher in this project then force builds the other 4 application projects. This approach allows me to create a single label for all 4 projects to use - to guarantee they all get the same label and are bundled together in our application suite. In actuality, the working copy of the application code has already been updated by the time the 4 application projects kickoff - but what I found is that the CCNet build reports for the 4 application projects do not list the relevant source code modifications that effectively triggered the build. Only the separate source code monitor project lists the svn changes in its build report. This makes it a difficult to track down the possible cause of a failed build. A user has to go through the application project's build logs to find the exact error, and then go to the source monitor project to find out what files where actually changed that could have caused the error. It created a lot of back and forth So, to resolve this, I have a redundant source control block in the 4 application projects, really just to pick up the svn log messages so they are included in the project build reports. Is there a more convenient way to do this? Perhaps with a merge task? This would resolve all my issues. thanks Michael On Nov 30, 10:28 am, Tom Owens <[email protected]> wrote: > 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 -
