Hey Cedric, This problem has nothing to do with the SVN sensor. It has a lot do with the way hackystat handles workspaces and workspace roots. It seems that when using Subversion we can checkout entire directories instead of just modules in CVS. This Subversion feature allows easy nesting of workspace roots.
So, in my example, I setup a CruiseControl build system for some of my projects without thinking about Hackystat. Now, that I want to use Hackystat, I've noticed that I have nested workspace roots, which cause major problems in defining Hackytat projects and running analyses. I've been collecting some FileMetric and UnitTest data but for some of data is totally unusable because of the nested workspace root problem. For example, the second workspace root is nested and illegal. Workspace Root 1 = C:\cruisecontrol-work\checkout\ Workspace Root 2 = C:\cruisecontrol-work\checkout\applicationBar I could change my directory structure based on my knowledge of Hackystat's workspace roots, but I think that is a brittle solution as other developers might nest their workspace roots. In other words, the only limiting factor is Hackystat. So, what I'm asking is if there is a possible solution on the Hackystat side of things. Instead of making an "invisible" requirement on all of the development machines. thanks, aaron ----- Original Message ----- From: "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]> Date: Tuesday, October 4, 2005 12:37 pm Subject: Re: [HACKYSTAT-DEV-L] Workspace root problem > I may not understand the problem correctly. But given that the svn > sensor allows you to prepend arbitrary directory in front of the > file > path, why we need to handle nested workspace root? Is there > something I > am missing? > > thanks. > > cedric > > Philip Johnson wrote: > > I think with the advent of subversion we're going to be forced > to deal > > with the nested workspace root issue. > > > > Hongbing, how hard would it be to remove this constraint? I am > thinking > > that the behavior when roots are nested is to match against the > longest > > string. Does that make sense? > > > > Cheers, > > Philip > > > > --On Monday, October 3, 2005 4:48 PM -1000 Aaron Akihisa Kagawa > > <[EMAIL PROTECTED]> wrote: > > > >> 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=29349>> 2). > >> > >> 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 >
