Philip wrote:
(5) Is this somehow a problem unique to me?
- Do others observe/require multiple workspace roots with different cases?
I've experienced this a lot. And I know that a couple of students had this
problem too.
Philip wrote:
> C:\svn" was set as a workspace root, "c:\svn" was not
One of the culprits is Eclipse. Your workspace can have different cases
depending on the path you type into Eclipse when importing a project. I
noticed this a while back, so I've been trying to use the same case (I
picked lower case) when importing Eclipse projects. However, it turns out
that the Ant sensors seem to always send C:\svn as opposed to c:\svn. So, I
should have been doing upper case when importing Eclipse projects.
There's more potential for problems... it is possible to import a Eclipse
project with this path, "c:/java/svn/hackySdt_perf/", thus sending Activity
data like "c:/java/svn/hackySdt_perf/.project". This is also a problem.
Oh.. and there are all kinds of issues with Project descriptions. For
example, if I check out hackyCore_Kernel from subversion as
hackycore_kernel, then none of my data will contribute to the Hackystat-7
project.
Cedric wrote:
> _If_ we want to get rid of case sensitivity in file names, then my 2
cents is that:
> (1) Store file names in a case-sensitive way (no change to sensor and
persistence mechanism)
> (2) Change WorkspaceFile.getFileName() to return either all lower case
or all upper case file names.
So, you're saying something that looks like this:
c:\java\svn-csdl\stackyhack\src\edu\hawaii\stack\stack.java
C:\JAVA\SVN-CSDL\STACKYHACK\SRC\EDU\HAWAII\STACK\STACK.JAVA
I agree that this would work, but I don't like this one, ... Just because
it would look funny. I do agree with part (1) of your proposal.
Philip wrote:
(3) How would case-insensitivity be implemented?
- on the sensor-side, when providing file paths to the sensor shell?
you mean on the client-side...
I came up with this: Let the client decide whether they care.
HackyInstaller can configure a property like SENSOR_CASE_SENSITIVE=true. If
this is set to true then its up to the sensors to properly "case-ify" the
file paths.
This would work if Eclipse can access the file system instead of using the
Eclipse defined "workspace" settings for the file paths. If that is
possible then the sensor will know to
use: C:/java/svn/hackySdt_Perf/ instead of c:/java/svn/hackySdt_perf/
- on the client-side, upon receipt of sensor data but before storage?
you mean on the server side... I can't think of a way to do it on the
server side.
- during Workspace instance construction?
I like this idea..
- the Workspace Root Config section in the preferences would have much less
entries.
- the persistent workspace.xml file would have much less entries.
The basic idea here is that the WorkspaceCache ignores case when adding
Workspaces to the cache. But, should the Workspaces' still contain the
actual case when it is used to display?
Say we encounter these file paths:
c:\java\svn-csdl\StackyHack\src\edu\hawaii\stack\Stack.java
C:\java\svn-csdl\StackyHack\src\edu\hawaii\stack\ClearStack.java
we probably should change one of these to conform to the other, right? In
other words, it probably doesn't make too much sense to have mixes in
case. We should either pick C:\ or c:\.
What happens if we get this?
c:\java\svn-csdl\STACKYHACK\src\edu\HAWAII\stack\Stack.java
C:\java\svn-csdl\StackyHack\src\edu\hawaii\stack\ClearStack.java
> - during Workspace instance comparison?
If only the comparison was changed then, this would help with the
hackyCore_Kernel from subversion as hackycore_kernel checkout
problem. But, it wouldn't minimize the number of enties in the Workspace
Root Config and the persistently stored workspaces.
This seems complicated... good luck. :)
thanks, aaron
