Hi Terry,
I fully agree.
1.
Create / Modify Aliases. I also don't see a need for creating /
modifying file system links from Eclipse. There should be support for
visualizing them, though (which is easy to add in Eclipse 3.5 already).
2.
Consistent normalized path support. Agree. We'll need
IFileStore#getCanonicalPath() on the EFS API, and we'll need smart
algorithms on the Resource / Refresh / Compare code to avoid using
getCanonicalPath() where possible, in order to maintain good
performance. In other words, query the canonical path only when we come
across an FS link, but construct the path ourselves for "regular" files
and folders. The Workspace Tree will need some redesign to understand
links "moving around" its structure.
3.
Serve up both normalized and non-normalized path strings. Yes,
though I think this is probably more relevant for resource objects than
for filesystem objects -- the FS layer does exactly that with a
getCanonicalPath() API already, but since FS must be stateless it will
be expensive. On the Resource layer, we can add state (caching) to make
it faster.
* the non-normalized path is how the client / user originally
referred to a resource, and
* the normalized path is its normalized variant (can be computed
from the workspace tree).
4.
Support team providers for VCSs that can check in symlinks. I'm
not sure if that is required. Assuming that foo/bar is a symlink, doing
a "checkin foo/bar" will check in the symlink as needed. To me, it seems
that all we need to make sure is that we don't instruct the VCS to check
in the same file twice just because we approach a given (normalized)
file through multiple different (non-normalized) paths. This should be
possible through an improved alias-aware Workspace Tree.
I think that if we are careful, there is some potential to even add
proper Alias Management in Eclipse 3.5 already, though that needs a lot
more investigation. What I would propose, is starting that work soon in
order to see whether we can apply it to Galileo already or whether it
requires more radical change that would make it impossible in 3.5.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
