I think that's it. For advanced users, they will want to sync the
repository with a location on their file system. We could then provide
an import wizard that looks at the result finding projects. Again that's
how CCRC works, which I've learned to appreciate over the last few weeks
of using it (apart from the odd quality issue and lack of support for
multisite).
Doug.
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Michael Valenta
Sent: Friday, October 03, 2008 11:42 AM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] Straw man proposal
Doug,
That's what I thought you meant ;-) Is it valid to summarize
this as saying that, in the simpler cases, the user could possibly
perform their team operations in their application layer view but for
more complicated cases, they would need to perform team operations in a
file system view? For instance, if I have a single file system root for
all my workspace projects, I may want to perform a sync of the file
system root and not on the individual projects? And, for your example, I
would like to load a file system root and then indicate which
sub-folders should be projects (or sub-folders in projects) within my
workspace (or use a set of buckminster load rules to populate my
workspace for me).
Michael
On Fri, Oct 3, 2008 at 10:11 AM, Schaefer, Doug
<[EMAIL PROTECTED]> wrote:
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.
________________________________
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Michael Valenta
Sent: Thursday, October 02, 2008 8:50 PM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] Straw
man proposal
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
<[EMAIL PROTECTED]> 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.
The proposal is here:
http://wiki.eclipse.org/E4/Resources/Strawman
<http://wiki.eclipse.org/E4/Resources/Strawman>
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
