Hi, Philip & Aaron,
I am not strongly against this change but I don't see the connection between
nested workspace root and SVN and CSDL or Hackystat specific module-based
directory structure.
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
I can understand why Aaron has directory structure like this because we
don't want to create repository
for each Hackystat module (for instance, Ikayzo uses
SVN://ikayzo.org/jupiter as repository name) To hackystat
we may use SVN://hackydev.ics.hawaii.edu/hackystat as repository name to
include all the modules.
(Obliviously, Philip & Cedric may take different strategy.)
Assume we can create nested workspace root
C:\cruisecontrol-work\checkout\hackystat\ and
C:\cruisecontrol-work\checkout the benefit is
hackyBuild, hackyKernel hacky..., and applicationFoo line up as the
top-most level workspace.
But they are different systems, seeing hackyBuild etc on the top level do
not add real values to Aaron.
I can see the side effects caused by nested workspace root. Using Jupiter
as example, we have folders like this:
C:\cvs
C:\cvs\jupiter
C:\cvs\jupiter\src
C:\cvs\jupiter\src\org
C:\cvs\jupiter\src\org\csdl ...
We can configure both C:\cvs and C:\cvs\jupiter\src as workspace roots.
Then we define a Jupiter project
in Hackystat which has workspace jupiter\. To run the project analysis we
will get nothing matched because
all files match workspace root C:\cvs\jupiter\src not C:\cvs.
Again, it is not hard to have nested workspace roots. I can implement it
but we need to think more before
we head to it. I will look back into Tim's email to think it thoroughly.
Thanks,
Hongbing
At 10:14 AM 10/4/2005, 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
