Thanks, Michael. I think it's important to support existing
workflows, such as checking out projects as we do today. My point is that we
should extend the current set of wizards and framework so that users can do
team operations without having to deal with setting up projects. I've seen a
number of cases where users are forced to set up their environments outside of
Eclipse using the command-line version of CVS since the Eclipse CVS
integration doesn't support the way their command-line peers have set up the
repository.
And it doesn't need to be a native client. I'm not suggesting
we throw away the CVS client we have in Eclipse. We may need to extend it to
support these operations. But users expect these clients to work to the same
level as their command-line counterparts. One of the things that bugs me about
the ClearCase Remote Client is that it doesn't implement all the operations I
need, like reqmaster, and I do have to go to the command-line at times to
do my work.
And it seems to me to be a prerequisite if you are to
take advantage of the flexible resources that you have the source set up in the
file system first. The root tends not to be a project so you need to be able to
check out a CVS module, for example, to somewhere on the user's file system and
then have the projects created based on what he checked out.
But, of course, we also need to support the existing
environments were these integrations work fine as is.
Doug.
Doug,
I don't agree with the statement that Team providers should use a native
tool to bootstrap your Eclipse workspace (i.e. you used the phrase "how team systems should
work"). I think that
the user should have the option to use the native tool if they so choose but I
think that many users appreciate being able to setup their Eclipse workspaces
using checkout (load, etc) wizards integrated in Eclipse (i.e. I can't imagine
what life would be like if I had to use the CVS or SVN command line clients to
checkout projects from those repositories and then import them into
Eclipse).
Or were you describing this from the standpoint of a desirable
architecture for a repository provider implementation were a native client is
used for the operations on the local file system and the integration in
Eclipse is handled through a layer on top of that that makes any changes on
the local file system known to the Project layer so it can be passed on to the
application layer? I know this is done in many cases but does have drawbacks,
mostly related to responsiveness of the UI during long operations (e.g.
progress reporting, cancellation, resource deltas).
Michael
On Thu, Oct 2, 2008 at 8:18 PM, Schaefer, Doug
<Doug.Schaefer@xxxxxxxxxxxxx>
wrote:
Hey gang,
To feed the discussion for tomorrow's
resource meeting, I have put together a straw man proposal for the e4
resource system architecture. I'm sure it has a lot of holes and I'm hoping
you'll help me fill them. I could also be totally on the wrong track and
maybe there's better answers we can put on the table. But let's
discuss.
Also at tomorrow's meeting we should
discuss if we want to continue our discussions on the platform-core-dev
list, or move them to the e4-dev list. My opinion is changing on this. I'd
like to get concensus from the team on how we want to do
this.
Cheers,
Doug.
_______________________________________________
eclipse-incubator-e4-dev
mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
