Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] [resources] Alias management

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/" is symlinked by "/project_alias/".  Desired behavior:
* When a debugger returns the path "/real/", 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


On Tue, Oct 7, 2008 at 10:31 AM, Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx> 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.
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member

eclipse-incubator-e4-dev mailing list

Back to the top