Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stellation-res] Initial Eclipse client APIs posted for discussion 
At 09:56 AM 10/17/2002, Dave Shields wrote:

On Thu, Oct 17, 2002 at 05:19:23AM -0400, Jonathan Gossage wrote:
> > >The Svc workspace already has a notion of "workspace state" which is
> > >locally persistent, motivated by many of the reasons you cite.
> > >We've since concluded this is not such a great idea:
> > >* the local "workspace state archive" is basically a
> > >"lightweight repository"
> > >   - but not exactly.
> > >* the two entities do *not* have identical behavior, leading to confusion 
> > >   and additional code maintenance.
> > >* there is a significant performance hit related to saving the
> > >*entire* project
> > >    workspace state to a local zip archive before most
> > >Stellation operations.
Not true. The *entire* workspace state is not saved to a single zip archive, only the project file and the compressed form of any artifacts not previously archived.
Thanks for the clarification. That notwithstanding, I think Mark and I have both 
noticed some performance impact (although, for command-line use, I happily
accept the performance hit in exchange for the undo/redo capability).



> > >   A local repository, hosted on a local database, would likely
> > >do a better
Why should we have to use yet another database to save state while preparing a new revision? The save/restore is mainly meant to provide an "undo" mechanism using the 
client filesystem without the need to install any additional software.
Hmm. In our local discussions at Watson, I thought we had generally agreed that, once repository replication was operational, it would be "better" to use a local database copy rather than the save/restore workspace state mechanism. Here, "better" means: 
* less code to maintain (both in core components and in GUI components)
* same capabilities as the regular (remote) database, so developer is not confused 
  by a "similar-but-not-exactly" local storage mechanism.
* Seamless transition between local version archiving (e.g. in disconnected
   laptop-in-the-mountains mode) and working with a shared remote repository.
That said, I think the save/restore state mechanism has value for a command-line 
client, at least until replication is working and maybe after that.
But, for an Eclipse client, I think integration with the local resource history mechanism is a better solution. The local resource history mechanism, as it currently stands, does not support any notion of project-level versioning across sets of resources; 
the Stellation workspace save/restore functionality is clearly superior.
However -
* The Eclipse local resource mechanism seems adequate for providing a single level of local undo/redo (e.g. to recover after a merge or checkout that went wrong). * The Stellation client code can probably add Eclipse 'markers' to resources in the local history (or simply keep sets of resource history tags) if we decide that 
   more than one level of undo is needed.



> > >
> > >   job.  Also - the Eclipse "local resource history" mechanism
> > >fills some of
> > >   the same needs; it should be possible to leverage it even more as the
> > >   Stellation Client develops.
> > >Switching between "local" and shared repository" mode will hopefully
> > >be as simple as rebinding an ScmAccessPoint  to a different repository.
> > >
> I agree with you that the current workspace implementation is haevy-weight
> and costly in terms of resources.

Assuming the Eclipse "local resource history" will do the
job assumes the user is willing to always run from within Eclipse.
This is also "heavy-weight and costly in terms of resources".
Since you both agree the current workspace code is "heavy-weight and costly in resources", any suggestions on improving it would be welcomed, though I would prefer to put any 
changes that won't have major impact on hold until alpha release is out.


Actually, I never said "heavy-weight and costly in resources".
The workspace code is not an optimal fit for Eclipse, for a couple of reasons:

* It provides a number of services that duplicate Eclipse functionality
  (e.g. resource management).  This is great for a command line client,
  but not so good for Eclipse, esp. since Eclipse has its own conventions
  for resource path representation, etc.
  The workspace state save/restore mechanism is another feature that's
very useful for a command-line client, but not as relevant to an Eclipse client. 

* The workspace code uses a "set everything up, do one thing, tear everything
down" process model which is fine for a command-line client, but not so great 
   for Eclipse or other GUI clients.  This does add a lot of extra overhead
   (and complexity) for an Eclipse-based client.
It's worth noting that the new Eclipse ClientCore I'm working on is **very** largely based on your workspace code - just trimmed to fit, with an Eclipse-friendly makeover.
As I said in an earlier note, I think it would be great to factor out common functionality into a package that was directly usable both by Eclipse GUI clients and by command-line clients. This may be a bit tricky, since Eclipse resource management is somewhat different from stock Java file system management, but there are ways to finesse that.
Once the dust clears (post alpha release), it would be good to consolidate efforts 
and work towards that goal.

Regards,

Jim

--
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email: jim.wright@xxxxxxx

Back to the top