[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
Thanks Michael/Szymon,
Is there a bug describing the isHidden
feature?
Doug
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
