This seems quite reasonable to me. Aaron, would this work correctly in
the case of your Subversion repository setup?
Cedric's algorithm seems like it will work. As long as I can define a
Hackystat project with "work3" workspaces, then analyses like Daily Project
Details should know what to do.
But, let me explain further that I think this problem doesn't occur because
of a Subversion repository setup. Users could experience this problem with
CVS as well. For example, checking out hackystat modules in a subdirectory,
while checking out a single standalone module in the top level directory.
c:\cvs\hackystat\hackyBuild
c:\cvs\hackystat\hacky<ModuleName>
c:\cvs\stackyHack
However, in CVS's case this isn't the standard practice (at least in CSDL
and our SE classes). In Subversion it seems to be quite common to checkout
the parent directory of a bunch of modules. So instead of checking out
hackyBuild, hackyKernel, hackyStdExt, etc separately, Subversion
_allows_the_possibility_ of checking out all submodules from its parent
directory (well, depending on how you set up your subversion repository. i
suppose you could keep all modules at the top level, but that doesn't seem
to be the standard). Note that you can definitely checkout individual
modules in subversion like we have been doing with CVS. In fact, you guys
might continue to do that, since some of the Hackystat modules don't have
to be built locally all the time and there are different configurations of
modules.
A couple of other things:
1) I've heard that you guys are planning on importing only version 7
designs in Subversion. I personally think that it would be cool import
version 6 and use Subversion in the refactoring to keep track of the
original architecture and how it maps to version 7. For example, I think
subversion will know that hackyStdExt/src/org/hackystat/stdext/unittest/sdt
was changed to hackyStdUnitTest/src/org/hackystat/unittest/sdt/. There
could be some really interesting Hackystat analyses one could write in
regards to Software Architecture/Evolution. I'm not sure what is the best
way to do this in subversion but maybe importing version 6 into one
subversion directory (say hackystat6) then moving it to another directory
(say hackystat). Anyway, I understand why you guys have chosen not to do this.
Subversion could be one way to solve the refactoring problem in hackystat.
Of course this would be a tool specific solution.
2) has anyone started to think about the subversion directory structure for
hackystat? Here is a suggestion to start things off
http://hackystat.ics.hawaii.edu/repos/hackystat/
http://hackystat.ics.hawaii.edu/repos/hackystat/trunk/
http://hackystat.ics.hawaii.edu/repos/hackystat/trunk/hacky<ModuleName>
http://hackystat.ics.hawaii.edu/repos/hackystat/trunk/hacky<ModuleName>/src
http://hackystat.ics.hawaii.edu/repos/hackystat/tags/
http://hackystat.ics.hawaii.edu/repos/hackystat/tags/release7.0.1/hacky<ModuleName>
http://hackystat.ics.hawaii.edu/repos/hackystat/tags/release7.0.1/hacky<ModuleName>/src
http://hackystat.ics.hawaii.edu/repos/hackystat/branch/
http://hackystat.ics.hawaii.edu/repos/hackystat/branch/somebranch
http://hackystat.ics.hawaii.edu/repos/hackystat/branch/somebranch/hacky<ModuleName>
http://hackystat.ics.hawaii.edu/repos/hackystat/branch/somebranch/hacky<ModuleName>/src
http://hackystat.ics.hawaii.edu/repos/stackyHack/
http://hackystat.ics.hawaii.edu/repos/stackyHack/trunk
http://hackystat.ics.hawaii.edu/repos/stackyHack/trunk/stackHack
http://hackystat.ics.hawaii.edu/repos/stackyHack/trunk/stackHack/src
http://hackystat.ics.hawaii.edu/repos/stackyHack/tags/
http://hackystat.ics.hawaii.edu/repos/stackyHack/branches/
This last example is a little strange, because stackyHack doesn't belong to
a larger system. So, you could do something like this:
http://hackystat.ics.hawaii.edu/repos/stackyHack/
http://hackystat.ics.hawaii.edu/repos/stackyHack/trunk
http://hackystat.ics.hawaii.edu/repos/stackyHack/trunk/src
but to keep a standard way of creating modules it seems the first option is
better. But, I'm not sure. I know that maven's subversion repository
doesn't do that. See the maven core directory below.
Just to show that some other people have similar Subversion setups check
out: <http://svn.apache.org/viewcvs.cgi/maven/maven-1/plugins/?rev=232355>
You will see a directory structure like this:
maven-1/plugins/
maven-1/plugins/trunk
maven-1/plugins/trunk/jira
maven-1/plugins/trunk/<other plugins>
maven-1/plugins/tags/MAVEN_1_0_B10/jira
maven-1/plugins/tags/MAVEN_1_0_B10/<other plugins>
maven-1/plugins/branch/MAVEN_1_0_B10_BRANCH/jira
maven-1/plugins/branch/MAVEN_1_0_B10_BRANCH/<other plugins>
http://svn.apache.org/viewcvs.cgi/maven/maven-1/core/trunk/?rev=232355
maven-1/core/trunk/src/
maven-1/core/trunk/xdocs/
maven-1/core/trunk/...
thanks, aaron
At 07:27 PM 10/4/2005, Philip Johnson wrote:
This seems quite reasonable to me. Aaron, would this work correctly in
the case of your Subversion repository setup?
Cheers,
Philip
--On Tuesday, October 4, 2005 5:09 PM -1000 "Qin ZHANG (Cedric)"
<[EMAIL PROTECTED]> wrote:
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=2
>>>>> 9349
>>>>>
>>>>> >> > 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
