In my last entry, I dropped a quick note about a feature I'm planning for CDT 5.0 due out with Ganymede next summer. We are getting more and more requests from users moving over from Microsoft's Visual Studio that the CDT should do things like in Visual Studio. One of the high runners is to be able to add files and directories from anywhere in the file system to projects, and to be able to exclude files and directories from other directories. You could use Linked Resources to do the 'add' today. But there's no mechanism to do the 'exclude'.
After playing around with EFS for remote project support, I got the feeling that I could do this add/exclude functionality using EFS by implementing my own file system that would map paths requested from IResources into real file system paths the users wants them to map to. I've decided to call this the Flexible File System (or ffs for short and as the schema name).
I'm not sure if this is going to work out yet. The simple things like opening files and building the resource tree should work. I really want to get the Team system working as well so you can keep the files in source control. That will be the really tricky part. I also think there is going to be a lot of issues we uncover where we're assuming we know the layout of the file system. And we got to figure out how to tell the external tools the real file locations they need.
For now, I'm only looking at this from a CDT project perspective. I know there are a lot of other projects that could use this and I hope we can move this to the platform at some point. And it won't do some other things with the resource system we've always wanted, like nested projects. But now that we've reached a good level of maturity with the CDT, we need to start addressing these issues and remove those final big objections to moving to the CDT and Eclipse.
The main issue I can see with your proposal is the potential for competing file system providers. You could have tooling, like CDT, that wants to change the EFS for it's projects in order to exclude subtrees. You could also have a repository provider that wants to change the EFS for the projects it controls in order to preserve copy sematics and potentially hide repository meta-data files.
ReplyDeleteIMHO, it should be the repository provider that controls what EFS is used for a project (which shouldn't be a surprise ;-). That's not to say that we don't need an exclude mechanism. I just think it should be implemented at a higher level. This could come is several forms:
1) A protocol/API for nesting EFS providers.
2) Exclusions at the workspace/IResource level
3) Exclusions at the tooling level (i.e. the files would still appear in the workspace but would not be compiled by tooling).
Currently, JDT provides support for exclusion using the third approach.
Having had some experience with EFS and team, you need to be careful. Firstly, a lot of the Team stuff (for CVS, at least) expects the mapping between the folder and the version control stuff to be the same. So if you have a directory checked out as 'foo', it needs to be in a similarly named folder 'foo' for the code to work. That somewhat prevents import-random-files into a workspace approach, or at least, you have to be happy in how it works.
ReplyDeleteSecondly, when you import individual files in, there may be other references to files where it came from that may not be in the project. So foo -> c:/foo and foo/hello.c -> c:/foo/hello.c, but c:/foo/goodbye.c may not be there. When you do a CVS update, it thikns that goodbye.c has been deleted (or depending on what kind of day it's having, updated).
Thirdly, EFS has some real headaches when it comes to special characters. Probably won't affect you much (given that most source files are ASCII most of the time) but it's a pain that shouldn't be there.
There's also a lot of overhead in some of the info class acquisition; you need to profile it when it's running to determine why it's not there. Each time you hit a character in an editor, it requests the fileInfo for your resource, which if you do a remote lookup each time can be quite performance limiting.
Oh, be aware that some revision control systems expect their parent to be present and with correct relative links as well. Sometimes if the root doesn't have version control, changes can get missed.
Hi Doug,
ReplyDeletea while back, I had a similar idea to overcome the limitations of the eclipse project system (support of nested projects):
https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973#c66
I still think it is worth an investigation. I would create a decorator on top of the EFS, this would allow to use any EFS below. If you do some experiments wit EFS, I'd be very much interested.
Michael