[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-core-dev] Flexible Resource Model use case
|
Thanks, Michael, that's been the community's experience
playing with EFS in the past. There are definitely major issues there. As we
investigate further, we definitely need to consider the impact on Team
providers.
Are there other components we need to worry about? There
are things in the CDT that we need to address on the build side where
assumptions about the underlying file system.
In the end, I think the workflows where exclusions, or
flexible resources at all, make sense and those that do not. We need to
carefully manage that list and ensure that whatever we do is optional to
maintain existing workflows.
Cheers,
Doug.
From: platform-core-dev-bounces@xxxxxxxxxxx
[mailto:platform-core-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael
Valenta
Sent: Tuesday, May 20, 2008 2:42 PM
To: Eclipse
Platform Core component developers list.
Subject: Re:
[platform-core-dev] Flexible Resource Model use case
Although the effort of adding exclusion support in the resource
layer may be straight forward, I wonder what additional effort would be
required to make this support work well with the Team layer. One of the
factors that makes this complicated is that there is a wide range of
integration styles for repository providers. Some have rich integration and
are Eclipse resource aware (CVS), others may have some resource knowledge but
operate directly on the file system (SVN), some use their own EFS
implementation on projects to have better control over moves and copies (Jazz)
while others have a low level of integration (i.e. actions launch
external commands). It is important that any work that is done in this area
have clear expectations on how this will effect the different types of
repository providers. Ideally, the support should just work with existing
providers. However, this probably isn't possible so it may be necessary to
provide a means of allowing repository providers to indicate whether they
support exclusions or not. It would also be good (I would even say necessary)
to have API that makes it possible for any style of repository provider to
adopt support for exclusions.
Michael
On Tue, May 20, 2008 at 2:01 PM, John Arthorne <
John_Arthorne@xxxxxxxxxx>
wrote:
Exclusion is definitely an interesting area to
explore. Note that IResource#setHidden is not the best mechanism for
implementing this though. setHidden will hide the resource from the UI, but
under the covers it will still create the entire subtree and much of the
cost will be the same. You can actually exclude subtrees today using a
linked resource pointing to the null file system, but there is no UI for
doing it. I think with a bit of UI work, exclusion support could be added
with very little effort even in 3.5 if there was interest in doing
it.
John
I haven't seen the following use case yet
so I want to add it to the discussion.
- A project needs to pull in code that is rooted in folder
"A1"
- A1 is outside the user's workspace
- A1 contains many subfolders
- Only a handful of A1's subfolders are a part of the
project
- IFolder.createLink() is called, linking the project to
folder A1
- IFolder.createLink() starts a refresh that traverses
_everything_ under A1
- The cost of traversing all of A1's subfolders is too
high--IResource.setHidden() can only be called on subfolders after they
have been pulled into the workspace
We need a
way to hook into the resource delta creation so that any nested subfolder
can be hidden _before_ that subfolder is traversed.
--Terry Parker_______________________________________________
platform-core-dev
mailing list
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