I think I have a simple algorithm for Hackystat to have nested workspace
root support, of course, with one assumption.
A file path = workspace root + releative path.
In order to have an efficient algorithm, we need to eliminate the guess
work which workspace root should this file path use. The assumption is
always using the longest workspace root.
Suppose we have 2 workspace roots:
C:\work1
C:\work1\work2
and a file path
C:\work1\work2\work3\file.java
Then we use
C:\work1\work2 as workspace root for this file, because it is the
longest matching workspace root.
I think this restriction is very reasonable.
Cheers,
Cedric
Hongbing Kou wrote:
Hi, hackers,
Aaron called in and we discussed the problem he is facing. In our
analyses we
have module or top-level workspace based analysis. In Aaron's
configuration we
can let project Hackystat include workspaces hackystat\hackyBuild,
hackystat\hackyKernel
.. but we won't be able to know how much time we spend on individual
modules such as
hackyKernel, hackyReport, hackyStdExt etc. And there are telemetry
analyses on
module level as well.
Thanks Aaron for clarifying the misunderstandings in this issue. I
will think it over
and I'd like to know others' comments as well.
Thanks,
Hongbing
At 03:35 PM 10/4/2005, Hongbing Kou wrote:
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
