[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] RE: [cdt-dev] First gotchawithadd/excludechildren of FFS
|
Never mind, I didn't see your note about meeting in the theatre before I
sent this suggestion. Let's meet in the theatre on Wednesday at 12:45.
- Ken
> From: "ext Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
> Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> Date: Mon, 17 Mar 2008 14:22:28 -0700
> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> Subject: RE: [platform-core-dev] RE: [cdt-dev] First
> gotchawithadd/excludechildren of FFS
>
> If we have all the players, but my sense is that we're going to have more
> people than can fit at the table. We can certainly start discussions at lunch.
>
> Cheers,
> Doug
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Ken Ryall
> Sent: Monday, March 17, 2008 2:18 PM
> To: CDT General developers list.
> Subject: Re: [platform-core-dev] RE: [cdt-dev] First
> gotchawithadd/excludechildren of FFS
>
> OK, let's start by meeting at the CDT lunch table on Wednesday.
>
> Thanks - Ken
>
>> From: ext Szymon Brandys <Szymon.Brandys@xxxxxxxxxx>
>> Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>> Date: Fri, 14 Mar 2008 17:19:00 +0100
>> To: <cdt-dev@xxxxxxxxxxx>
>> Subject: Fw: [platform-core-dev] RE: [cdt-dev] First gotchawith
>> add/excludechildren of FFS
>>
>>
>> We can use both BOF and lunch time on Wednesday for the discussion. I
>> would prefer to make it earlier. 9 pm is quite late for clear thinking
>> ;-)
>> --
>> Szymon Brandys
>>
>>
>>
>>
>> "Schaefer, Doug"
>> <Doug.Schaefer@wi
>> ndriver.com> To
>> Sent by: "Eclipse Platform Core component
>> platform-core-dev developers list."
>> -bounces@eclipse. <platform-core-dev@xxxxxxxxxxx>,
>> org "CDT General developers list."
>> <cdt-dev@xxxxxxxxxxx>
>> cc
>> 2008-03-13 18:06
>> Subject
>> FW: [platform-core-dev] RE:
>> Please respond to [cdt-dev] First gotchawith
>> "Eclipse Platform add/excludechildren of FFS
>> Core component
>> developers list."
>> <platform-core-de
>> v@xxxxxxxxxxx>
>>
>>
>>
>>
>>
>>
>> Well I'll be there and I want to talk about flexible file systems.
>> Szymon can you make this time?
>>
>> We can also use lunch times, I guess.
>>
>> Doug.
>>
>> -----Original Message-----
>> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of Chris Recoskie
>> Sent: Thursday, March 13, 2008 12:55 PM
>> To: CDT General developers list.
>> Subject: RE: [platform-core-dev] RE: [cdt-dev] First gotchawith
>> add/excludechildren of FFS
>>
>> I guess it depends?
>>
>> We really have no idea who is showing up to the BOF or what they want
>> to talk about. Do we know if Szymon can make that time?
>>
>> ===========================
>>
>> Chris Recoskie
>> Team Lead, IBM CDT Team
>> IBM Toronto
>> http://www.eclipse.org/cdt
>>
>>
>>
>>
>> "Schaefer, Doug"
>> <Doug.Schaefer@wi
>> ndriver.com> To
>> Sent by: "CDT General developers list."
>> cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>
>> clipse.org cc
>>
>> Subject
>> 03/13/2008 12:50 RE: [platform-core-dev] RE:
>> PM [cdt-dev] First gotcha with
>> add/excludechildren of FFS
>>
>> Please respond to
>> "CDT General
>> developers list."
>> <cdt-dev@eclipse.
>> org>
>>
>>
>>
>>
>>
>>
>> Did we just want to do this at the CDT BOF? I don't see much room in
>> the schedule. The CDT BOF is 8:45 on Wed. Thoughts?
>>
>> Doug
>>
>> -----Original Message-----
>> From: platform-core-dev-bounces@xxxxxxxxxxx
>> [mailto:platform-core-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris
>> Recoskie
>> Sent: Wednesday, March 12, 2008 9:41 AM
>> To: CDT General developers list.
>> Cc: platform-core-dev@xxxxxxxxxxx
>> Subject: [platform-core-dev] RE: [cdt-dev] First gotcha with
>> add/excludechildren of FFS
>>
>> Please count me in for such a meeting.
>>
>> ===========================
>>
>> Chris Recoskie
>> Team Lead, IBM CDT Team
>> IBM Toronto
>> http://www.eclipse.org/cdt
>>
>>
>>
>>
>> "Schaefer, Doug"
>> <Doug.Schaefer@wi
>> ndriver.com> To
>> Sent by: "CDT General developers list."
>> cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>,
>> clipse.org <platform-core-dev@xxxxxxxxxxx>
>>
>> cc
>>
>> 03/10/2008 10:27 Subject
>> AM RE: [cdt-dev] First gotcha with
>> add/exclude children of FFS
>>
>> Please respond to
>> "CDT General
>> developers list."
>> <cdt-dev@eclipse.
>> org>
>>
>>
>>
>>
>>
>>
>> Copying the platform-core-dev folks too. Is there someone from the
>> Platform who could attend a meeting at EclipseCon about flexible file
>> systems. John A, will you be there? John is Mr. EFS and we can use his
>> guidance.
>>
>> Thanks,
>> Doug.
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of Ken Ryall
>> Sent: Saturday, March 08, 2008 5:08 PM
>> To: CDT General developers list.
>> Subject: Re: [cdt-dev] First gotcha with add/exclude children of FFS
>>
>> Doug,
>>
>> Can we get together at EclipseCon to discuss this issue specifically?
>> Do you know the right platform people to invite to the meeting? We
>> really need to piece together a plan.
>>
>> I?m sure you have enough to do so if you can tell me who to recruit I
>> can help organize the meeting.
>>
>> Thanks - Ken
>>
>> From: "ext Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
>> Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>> Date: Wed, 20 Feb 2008 18:44:57 -0800
>> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>> Subject: RE: [cdt-dev] First gotcha with add/exclude children of FFS
>>
>> So, you know. The more I think about what you guys are saying, I'm
>> realizing that the EFS solution probably is the right one. The
>> objective should be to turn the IResource tree into a logical project
>> view and to remove all notions that it represents physical file
>> layout. That unfortunately starts with the .project and .cproject
>> files, but I think there are tricks we can do there. The .settings may
>> be harder but let me sleep on that.
>>
>> At any rate, this has piqued my interest again and I'll work on
>> reviving it and see where it goes. I'll try to get a prototype working
>> by EclipseCon so we can talk about it more concretely.
>>
>> Cheers,
>> Doug
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of Brunauer, Walter
>> Sent: Monday, February 18, 2008 8:53 AM
>> To: CDT General developers list.
>> Subject: RE: [cdt-dev] First gotcha with add/exclude children of FFS
>>
>> Hi Warren,
>>
>> well, the confusion my origin from the different meanings of what
>> project setup is: for me, project setup is not equal to build setup.
>> I.e., on our projects, the build setup is an independent step from the
>> project setup. We intentionally separated this to overcome all kind of
>> issues you obviously experienced as well. And this is how we see it:
>>
>> 1. Create a project at the desired location (everything beneath this
>> root location is part of the project, but it can be an empty project
>> just as well with linked resources added to it later). By default, the
>> build setup is identical to the project content (there is one build
>> target, linking/archiving everything together).
>>
>> 2. If (a) specific build setup(s) are needed, it is possible to
>> specify as many build targets with arbitrary contents as desired. This
>> approach separates the physical file system layout from logical build
>> layouts, and it even works beyond project boundaries. IOW, no matter
>> from where source files are pulled in (the same projects, nested
>> projects, outer projects, sibling projects), one is able to specify
>> any build setup exactly are needed, as long as all source files are known to
>> Eclipse (as resources).
>>
>> HTH,
>>
>> Walter
>>
>>
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [
>> mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
>> Warren.Paul@xxxxxxxxx
>> Sent: Freitag, 15. Februar 2008 14:51
>> To: cdt-dev@xxxxxxxxxxx
>> Subject: RE: [cdt-dev] First gotcha with add/exclude children
>> of FFS
>>
>>
>>
>> Hi Walter,
>>
>>
>>
>> I forgot all about the absolute paths issue with linked resources.
>> I'll update the wiki.
>>
>>
>>
>> I'm a bit confused about your comment about this not being a project
>> setup issue. We have our own builder as well, and it will happily
>> build whatever the build description says, whether those files are
>> under the project root or not. We even have our own project explorer
>> view which shows a logical representation of the project rather than
>> the physical file system layout. But we still run into a lot of
>> issues when files are not under the project root - that is, when you
>> can't get an IFile for them.
>>
>>
>>
>> We have a wide range of user types from small application developers
>> to large system developers. In many cases, a users code base
>> consists of hundreds of directories with thousands of source files.
>> In such a source base, there are many hundreds of build artifacts
>> and almost as many "logical projects". It is a huge problem for
>> these users to be able to create projects currently. They will
>> typically have a few projects going at a time, but many times the
>> natural project root for all of them will be the same. We've found
>> ways to work around some of the other issues, but not this one. It
>> sounds like perhaps you guys have found a way. Could you elaborate
>> on how you setup your projects?
>>
>>
>>
>> Thanks,
>> Warren
>>
>>
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [
>> mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Brunauer,
>> Walter
>> Sent: Friday, February 15, 2008 1:56 AM
>> To: CDT General developers list.
>> Subject: RE: [cdt-dev] First gotcha with add/exclude children
>> of FFS
>>
>>
>>
>> Hi Warren,
>>
>>
>>
>> FWIW, you did not mention anything about linked resources and
>> absolute paths these persist in the .project file by default. Again
>> a big issue around linked resources in combination with sharing
>> project within a team (even without team support), and one more
>> reason why they appear to be so cumbersome to handle. To me it seems
>> many times one has to unsell linked resources to users: Whereas
>> linked resources are (kind of!) nice for evaluation purposes
>> (because, yes, in this case you might not want to pollute your
>> sources), as soon as you start serious development, you run into all
>> kind of troubles. The hurdle to get everything right from the
>> beginning is overwhelming for novices (e.g. its not possible to
>> change a linked resource to use a variable later). Sorry, I don't
>> know how to add this to the Wiki page...
>>
>>
>>
>> Having said that, the scenario you describe is really about having
>> the flexibility around build and indexer setup, not around project
>> setup, IMO.
>>
>>
>>
>> It's rather classic: users have common code they want to reuse in
>> multiple applications - so they create one or a set of libraries out
>> of it, within one or a set of projects. Of course, indexing should
>> be able to handle only code going into these libraries, and
>> optionally ignore the rest. Then, they create their application
>> projects, which use the binary artifacts of the library project(s).
>> Now it would be great if they would have automatic support for
>> application linkage specification, i.e. some nice wizard or UI
>> allowing to select the library binaries of other projects to be
>> linked in, without the need to specify it manually in the linker
>> options. And probably also desired: during application code
>> development, the public API's of all used library projects should be
>> the only thing they see WRT code completion, etc. I guess, some UI
>> would be needed for this as well.
>>
>>
>>
>> And now think of all developers in the world. Wouldn't it be great
>> to give as many of them the freedom to choose how to achieve this?
>> Either everything in one project, or one project per build artifact,
>> or one project per module/application/product, or with nested
>> projects... its possible. Our commercial IDE based on CDT supports
>> all this, and we did not have to provide some EFS or work with
>> linked resources. Well, we had to override the build system, and
>> this is IMO the place to solve this in CDT as well.
>>
>>
>>
>>
>> Again, I don't see anything specific to project setup. The issue
>> around having the source tree polluted with project files - I don't
>> think this is the big thing. I would not leave the Eclipse path in
>> this area at all and allow to separate the project file from the
>> project location. Its a very general paradigm of Eclipse, and I am
>> pretty sure doing everything differently will generate lots and lots
>> of problems in all kind of areas (probably much more than you
>> already identified), unless you make it a new Eclipse way
>> (add/change this in the platform, not in CDT, that is).
>>
>>
>>
>> Just my 2 or 3 cents again,
>>
>>
>>
>> Walter
>>
>>
>>
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [
>> mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
>> Warren.Paul@xxxxxxxxx
>> Sent: Donnerstag, 14. Februar 2008 23:35
>> To: cdt-dev@xxxxxxxxxxx
>> Subject: RE: [cdt-dev] First gotcha with add/exclude children
>> of FFS
>>
>>
>>
>> I've updated the Wiki page
>> http://wiki.eclipse.org/CDT:Flexible_Project_Structure with
>> some more thoughts on the issue. It would be great to get
>> feedback from other CDT users - both those shipping C/C++
>> IDE's and end users. You'll see that I'm not convinced that
>> the linked resources route is a viable option. Maybe we can
>> get the platform team involved in the discussion to help find
>> the best route forward.
>>
>>
>>
>> Thanks,
>> Warren
>>
>>
>>
>>
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [
>> mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Schaefer,
>> Doug
>> Sent: Friday, January 25, 2008 11:15 AM
>> To: CDT General developers list.
>> Subject: RE: [cdt-dev] First gotcha with add/exclude children
>> of FFS
>>
>>
>>
>> I guess what my investigation has shown me that the EFS
>> solution and linked resources are pretty much identical. I
>> really noticed this when trying to figure out how to persist
>> the adds and found myself wishing I could add that to the
>> .project file just like linked resource are. And they are....
>>
>>
>>
>> I think all the issues that we have with linked resources would
>> be equally as bad with the EFS solution, possibly worse
>> because the EFS adds are hidden. The CVS one is a great
>> example. I really doubt CVS would work with the EFS solution
>> either. And I don't want us to think EFS would be better since
>> it's not in the platform where we'll have a battle getting
>> changes. Any platform changes required to make linked resource
>> work correctly would also need to be done for EFS.
>>
>>
>>
>> So my hope is to save the effort at implementing the
>> add/remove functionality since I believe that's already there
>> with linked/hidden resources. We can then focus on making
>> linked resources work where we need them and improving the
>> workflows. But this really needs to start now.
>>
>>
>>
>> So, Warren, you've somewhat started a list of workflows that
>> we'd like to support with this solution. This is a great place
>> to start. I've created a Wiki page to start capturing these.
>> Please feel free to add more information, especially to the
>> workflow section. When we have that we may get a better idea
>> of which of the two solutions will work best.
>>
>>
>>
>> http://wiki.eclipse.org/CDT:Flexible_Project_Structure
>>
>>
>>
>> Thanks,
>>
>> Doug
>>
>>
>>
>>
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [
>> mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
>> Warren.Paul@xxxxxxxxx
>> Sent: Friday, January 25, 2008 11:22 AM
>> To: cdt-dev@xxxxxxxxxxx
>> Subject: RE: [cdt-dev] First gotcha with add/exclude children
>> of FFS
>>
>>
>>
>> We've been working on Eclipse/CDT based products for about
>> three years now. I'm sorry to say that the project model is
>> still not satisfactory for our purposes. We've tried many
>> angles, but are still stuck with some pretty serious
>> limitations. I've volunteered to investigate the EFS route to
>> see if it will help at all. Based on this thread I'm assuming
>> it won't.
>>
>>
>>
>> Let me give you a brief overview of how our users work, and
>> then discuss the problem we've run into. I don't think any of
>> this is specific to our users BTW.
>>
>>
>>
>> Most of our users have existing code bases. They simply want
>> to "import" it into the IDE. Others will create new projects
>> from our templates. The new projects are created in the
>> workspace. Imported projects could be anywhere in the file
>> system. Often times they will import several projects from the
>> same source tree. This is where our biggest problem is.
>> Let's say the source base looks like this:
>>
>>
>>
>> C:\MyProjects\Project1\...
>>
>>
>> C:\MyProjects\Project2\...
>>
>>
>> C:\MyProjects\Common\...
>>
>>
>>
>> Because both projects share code in the Common directory, the
>> logical root project directory for both Project1 and Project 2
>> is C:\MyProjects\. But in Eclipse you can't have two projects
>> with the same root. This is where the .project and .cproject
>> files are created. So currently our users would import
>> Project1 with the natural root (C:\MyProjects\), but Project2
>> has to be rooted at C:\MyProjects\Project2\. This means that
>> any source/headers from the common directory are not under
>> Project2. This means those files are not in the project
>> explorer for that project, are not indexed, etc.. We logged
>> this against the platform -
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=78438
>> .
>> Basically if you put the .project file anywhere, but have a
>> project root attribute, this would cease to be a problem.
>>
>>
>>
>> Our first product actually always created the .project in the
>> workspace, and for imported projects, would create links to
>> files and folders. We ran into so many issues with this that
>> we had to change the model. I don't recall all of the issues,
>> but here's a list of some:
>>
>>
>>
>> - Version control simply didn't work at all
>>
>>
>>
>> - You can't make file system changes with links. For example,
>> if you want to rename a file or folder, or move a file around,
>> you can't do this with linked resources. It only changes the
>> link itself, not the underlying resource.
>>
>>
>>
>> - Creating new resources in a project with links is confusing
>> at best. Let's say you have a project with a linked folder
>> and file at the root. If you create a new file or folder at
>> the root, it is created in the workspace, not where the other
>> folder/file are in the file system. But if you create a new
>> file under the linked folder, it gets created where you'd
>> expect.
>>
>>
>>
>> - The location of the .project/.cproject files are
>> problematic. Some users will want to keep these in version
>> control, while others won't. Those that do want them created
>> in the source tree, but those that don't want them elsewhere,
>> like the workspace. I forget now why this was a problem with
>> linked resources, but there was something weird going on
>> there.
>>
>>
>>
>> I suppose it's worth noting that the last time we really
>> looked at this was in Eclipse 3.2, so some of this may have
>> been fixed by now. But I doubt it. In general linked
>> resources are second class citizens. Some IResource API's
>> just don't work for linked resources. Just search for
>> references to IResource#isLinked for "special handling". I
>> suspect that we'll run into similar issues with EFS though -
>> see getLocation vs getLocationURI.
>>
>>
>>
>> We also have the same issue that Doug is trying to address
>> (hiding some branches in a source tree). This is much less of
>> an issue for us though. You can already reduce the scope of
>> the indexer and the build. The only real issue for us is for
>> a very large source tree, you're going to get IResource's for
>> everything, which slows things down quite a bit. There is
>> actually somewhat of a problem in reducing the indexer scope -
>> see https://bugs.eclipse.org/bugs/show_bug.cgi?id=178159.
>>
>>
>>
>> The hidden attribute addition sounds promising for hiding
>> resources under the project root, but doesn't really do
>> anything to add flexibility to the contents of a project. EFS
>> sounds like it would though. What I mean by that is, having
>> resources under a project that are real resources, not linked,
>> but that don't live under the project root in the file system.
>> I've just started looking into EFS, so maybe it's a bit of
>> wishful thinking at this point, but I'm hoping we could create
>> a project anywhere, and when we create it we pass the URI
>> location from our own EFS. Then when asked for the children,
>> we could return URI's for files from anywhere in the file
>> system, or on other machines even. This would seem to hold
>> the potential for working around the issues listed above.
>> We'd basically have an EFS map from what we want under a
>> project to the actual file system.
>>
>>
>>
>> So hopefully some of the experts can chime in here. Is my
>> hope for EFS unrealistic? Is there a different approach we
>> should look at?
>>
>>
>>
>> Thanks,
>> Warren
>>
>>
>>
>>
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [
>> mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Brunauer,
>> Walter
>> Sent: Friday, January 25, 2008 1:47 AM
>> To: CDT General developers list.
>> Subject: RE: [cdt-dev] First gotcha with add/exclude children
>> of FFS
>>
>>
>>
>> Hi,
>>
>>
>>
>> after reading this rather long thread, I'll decided to throw
>> in my personal opinion.
>>
>>
>>
>> I consider this approach to work against one of the most
>> general Eclipse platform paradigms, where a project is defined
>> to be a root directory and everything in it. IMO, the more
>> workarounds are introduced against this paradigm, the more
>> problems will be faced, and the more incompatibilities (or at
>> least unawarenesses) created.
>>
>>
>>
>> Isn't the whole problem you try to solve here rather about
>> what files should go into the build (and probably into the
>> indexer) than what files are part of a project? I understand
>> that CDT has no separation of what a project and what the
>> build input is (well, IIRC one can exclude specific files from
>> the build, but in general, the project content defines the
>> build input, right?).
>>
>>
>>
>> In our commercial IDE, we separated this. This not only
>> introduced much more powerful build setup capabilities in
>> general, but especially enabled users to setup build artifacts
>> with arbitrary contents (think of sources being compilable
>> with different compiler flags for different build artifacts,
>> build input exclusion patterns, build input from all over the
>> workspace, multiple build artifacts within the same project,
>> reusable build artifacts accross project boundaries, etc.,
>> etc., etc.). BTW, we call this build system flexible managed
>> build - because that's what it is:-)
>>
>>
>>
>> Of course, one can setup CDT projects as of today to exactly
>> contain what is desired (with the help of linked resources).
>> However, I find linked resources to be cumbersome and error
>> prone, though many of our customers start out with them during
>> evaluation as well, mostly because they are looking for a way
>> to achieve what they did in the past with other non-Eclipse
>> based IDEs, but sooner or later I know of lots of them
>> realizing its much easier to use the features of our flexible
>> build system instead, especially if projects need to be shared
>> in a team. And now think of virtual file systems, the
>> potential complexity of these, hidden assumptions,
>> restrictions, etc. Sounds worse than linked resources to me.
>>
>>
>>
>> I guess, the point I am trying to make is: whatever you decide
>> to do, make it understandable and transparent (and of course
>> as simple as possible to use) for the user.
>>
>>
>>
>> As said, just my 2 cents,
>>
>>
>>
>> Walter
>>
>>
>>
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [
>> mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
>> Schaefer, Doug
>> Sent: Donnerstag, 24. Jänner 2008 23:17
>> To: CDT General developers list.
>> Subject: RE: [cdt-dev] First gotcha with add/exclude
>> children of FFS
>>
>>
>>
>> Jogging through the code, it really looks like the
>> HIDDEN feature is what I was looking for. What I haven't
>> found yet is UI to make a resource hidden or a navigator
>> filter to show hidden resources (in case you want to
>> bring them back). Is this planned?
>>
>>
>>
>> Assuming we have the core features available to link in
>> and hide resource, I think we still have workflow issues
>> that need to be addressed. I like Ken's idea of a file
>> that controls the linking/hiding. We could have an
>> import/export mechanism for setting up projects based on
>> this file. A nice wizard for creating the file would
>> also be good, similar to the way the way the export file
>> system wizard works.
>>
>>
>>
>> Given this, we may be further along than we thought
>> (BTW, the hidden stuff seems to have been added in 3.4
>> M4).
>>
>>
>>
>> Cheers,
>>
>> Doug
>>
>>
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [
>> mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
>> Schaefer, Doug
>> Sent: Thursday, January 24, 2008 2:51 PM
>> To: CDT General developers list.
>> Subject: RE: [cdt-dev] First gotcha with add/exclude
>> children of FFS
>>
>>
>>
>> Thanks Michael/Szymon,
>>
>>
>>
>> Is there a bug describing the isHidden feature?
>>
>>
>> Doug
>>
>>
>>
>> From: cdt-dev-bounces@xxxxxxxxxxx [
>> mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael
>> Valenta
>> Sent: Thursday, January 24, 2008 11:37 AM
>> To: cdt-dev@xxxxxxxxxxx
>> Subject: RE: [cdt-dev] First gotcha with add/exclude
>> children of FFS
>>
>>
>> Doug et al,
>>
>> Szymon is really the person you want to bug on this but
>> I'll throw in my 2 cents ;-) First, I have to say that a
>> solution at the IResource level (e.g. using linked
>> resources and the new hidden folder support) is
>> infinitely better from a repository provider perspective
>> than an EFS based solution. You may not get all the Team
>> support you want at the IResource level but a solution at
>> the EFS level would certainly break the existing CVS
>> client since the CVS client isn't EFS aware to any great
>> extent. For instance, if you tried to hide a folder
>> using EFS, the CVS client would probably try and recreate
>> it the next time you performed a Team>Update. It is also
>> important to note that the Platform does not provide all
>> the hooks required by repository providers and I know of
>> at least one provider that has resorted to using it's own
>> EFS implementation under projects that are mapped to that
>> provider to get the capabilities it requires. I think it
>> is important that tooling in Eclipse stick to using the
>> IResource layer as the layer they operate on and let the
>> repository provider (or any other tooling whose
>> responsibility it is to manage the available files)
>> control the underlying file system. If there are
>> shortcomings or enhancements required then you should
>> push to get them in at the IResource level.
>>
>> As for the current state of Team support for linked
>> resources, I think the best approach is to enumerate
>> some specific scenarios of how you see linked resources
>> and exclusions working with descriptions of what you
>> need to do today to get Team support and what you would
>> like to see. It is also important to know if you expect
>> all the links to come from the same repository (or at
>> least repository type) or whether a project could
>> contain content from different repository types
>> (obviously the later would be more difficult to
>> accommodate than the former).
>>
>> Hope this helps,
>> Michael
>>
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>>
>> _______________________________________________
>> platform-core-dev mailing list
>> platform-core-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> _______________________________________________
>> platform-core-dev mailing list
>> platform-core-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
>>
>>
>> _______________________________________________
>> platform-core-dev mailing list
>> platform-core-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
