Hey Guys, I have a problem with workspace roots that I would like to report. I have a directory structure that is similar to this example:
C:\cruisecontrol-work\checkout\hackystat\hackyBuild C:\cruisecontrol-work\checkout\hackystat\hackyKernel C:\cruisecontrol-work\checkout\hackystat\hackyKernel\src C:\cruisecontrol-work\checkout\hackystat\hacky... C:\cruisecontrol-work\checkout\applicationBar C:\cruisecontrol-work\checkout\applicationBar\src C:\cruisecontrol-work\checkout\applicationFoo\module1 C:\cruisecontrol-work\checkout\applicationFoo\module1\src C:\cruisecontrol-work\checkout\applicationFoo\module2 C:\cruisecontrol-work\checkout\applicationFoo\module2\src What I've done is checked out the parent directory of the modules in Subversion to the checkout directory. This seems to be a common Subversion practice. You should see the problem already; there are nested Workspace Roots. Working with Subversion and CruiseControl, this directory structure seems to be the standard way one would do this. However, the only reason I can't do this is Hackystat's Workspace Root nesting problem. In CSDL, I had one top level directory (C:\java\cvs) that contained many cvs modules hackyBuild, clewNewsbulletin, stackMvc, stackyHack, etc... But, that seems to be closely tied to the way our CVS repository is organized. In an organization that uses Subversion, we are able to organize the modules in directories. For example, in Apache's SVN repos you can checkout all the plugins from its top level trunk (http://svn.apache.org/viewcvs.cgi/maven/maven-1/plugins/trunk/?rev=293492). So, one workspace root could be C:\java\svn\maven\plugins\ and another could be C:\java\svn (which won't work of course). So, I guess my question is, does it seem silly to change the directory structure (for cruisecontrol) to get around the Hacksytat workspace root problem? Not to mention, if I ever get developers to use client side sensors, I would have to ensure that they do not nest their workspace roots. thanks, aaron
