| RE: [stellation-res] Code Audit for Workspace package |
On Tue, 2002-09-03 at 02:11, Jonathan Gossage wrote: > > > > >-----Original Message----- > > >From: stellation-res-admin@xxxxxxxxxxxxxxx > > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C. > > >Chu-Carroll > > >Sent: September 2, 2002 4:01 PM > > >To: stellation-res@xxxxxxxxxxxxxxx > > >Subject: Re: [stellation-res] Code Audit for Workspace package > > > > > > > > > > > >I don't want you to feel ignored... The reason that there's been no > > >acknowledgement of this audit yet is because Dave Shields, who's the > > >guy responsible for the workspace code, is away, taking his daughter > > >to college. > > > > > >One quick comment: I noticed a couple of places where you ask "Can > > >you be sure that this code will only be used from the command line". The > > >answer to that is "yes". The behavior of a system that's well integrated > > >into the Eclipse IDE is sufficiently different from that of a > > >well-designed command line tool that we're going to keep them separate. > > >(There's some significant overlap right now, but we're going to be > > >gradually eliminating that.) > > > > > > -Mark > > No problem with feeling ignored. I thought that something like this would be > necessary. With regard to workspace management in the Eclipse and command > line environments, I believe it is worth some thought to try and see if > there is not a core set of functionality that can sit on top of either the > Eclipse workspace objects or standard command line objects. If you can do > that, perhaps using the same interface definition as Eclipse uses, you could > preserve a substantial portion of the workspace code base. It seems a bit > rude to have to duplicate functionality to support the two environments. > After all they are both file based workspace environments so the conceptual > pardigms are not totally different even if the details are. There is going to be a significant amount of common code, but it's going to be in the underlying data structures: Projects, BranchImages, Artifacts, Agents, Inputs, and Outputs. The command implementations are specifically implementations of commands invoked from the command line. Those classes contain command line interpretation, and logic that is pretty specific to the command line. For example: the real meat of checkin in really implemented by Handle.updateBranchHead. The command-line checkin command does a lot of work to figure out what's modified. In Eclipse space, the IDE keeps track of that, and sends change notifications which are tracked by the Stellation team plugin. If Stellation did the change identification itself inside Eclipse, that would be asking for bugs, where Eclipse and Stellation don't agree about what the workspace looks like. There are similar issues in checkouts, merges, etc. But the real work is (or will be) done by either the Handle, the Project, the Agents, or the I/O components. There are probably still places where there's functionality in the command classes that should be in one of the shared data structures, and as we identify it, we'll migrate it. -Mark -- Mark Craig Chu-Carroll, IBM T.J. Watson Research Center *** The Stellation project: Advanced SCM for Collaboration *** http://www.eclipse.org/stellation *** Work Email: mcc@xxxxxxxxxxxxxx ------- Personal Email: markcc@xxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part