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 >> >> 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
