Hi Martin,
Thanks for your comments. Keeping the file system layer stateless is the
right approach. I think the following additions would be sufficient:*
IFileStore.getCanonicalPath()
* IFileStore.isAlias() -- much lighter weight than getting
the canonical path, only returns true if last segment is aliased
A big concern I have is that if the resource layer solely adds
getCanonicalPath() to existing methods, it won't get invoked consistently.
Perhaps having {IWorkspace,IProject}.findResource(String absolutePath) API
calls as the primary/only way to convert a path string to a resource would
provide the consistency we need.
Here are some scenarios for which we will want aliasing to work correctly:
A) The file "/real/myfile.cc" is symlinked by "/project_alias/myfile.cc".
Desired behavior:
* When a debugger returns the path "/real/myfile.cc", the debug framework
opens the resource associated with project_alias, not a separate resource
outside the workspace
B) "/project/external_lib/headers" is symlinked to the folder
"/project/external_lib/v1234/src/headers".
"/project/external_lib/v1234/src/headers/file_with_syntax_error.h" fails to
compile. Desired behavior:
* Clicking on a console hyperlink or a Problems pane item for the
error opens the workspace-mapped resource. (This is no different from A,
but illustrates that symlinks can occur in any segment in a path, not just
the end segment.)
C) "/project1/external_lib/headers" and "/project2/external_lib/headers" are
both symlinked to the folder "/project1/external_lib/v1234/src/headers". On
a build of project1, code in an #ifdef in
"/project/external_lib/v1234/src/headers/header.h" fails to compile. Desired
behavior:
* You get two different editor panes when
opening "/project1/external_lib/headers/header.h"
and "/project1/external_lib/headers/header.h", since they may be used with
different compilation directives, which would affect their display
* Clicking on a console hyperlink or a problems pane item for the
error opens the workspace-mapped resource for the project1 version of the
file
* Editing the "header.h" file updates both editors in concert
--Terry
On Tue, Oct 7, 2008 at 10:31 AM, Oberhuber, Martin <
[EMAIL PROTECTED]> wrote:
> 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
>
>
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
