[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] Straw man proposal
|
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.
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
<Doug.Schaefer@xxxxxxxxxxxxx>
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.
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
_______________________________________________
eclipse-incubator-e4-dev
mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
