I would recommend using a modificationWriter task in the Task block of the common project and modificationReader tasks in the Prebuild block of the triggered projects.
-Tom On Dec 1, 1:07 am, Michael <[email protected]> wrote: > 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-Hidequoted text - > > > > - Show quoted text -
