[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] [resources] Alias management
|
Hi Terry,
I
fully agree.
-
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).
-
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.
-
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).
-
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
