[ANN] DVS rev. 1.34

Avi Bryant squeak-dev at lists.squeakfoundation.org
Sat Oct 26 16:48:11 UTC 2002


On Sat, 26 Oct 2002 danielv at netvision.net.il wrote:

> Filing in via DVS will also remove methods?

Yes.  The whole point is that it brings the package in the image in sync
with whatever's in the file out - by adding, changing, *or removing*
methods to do so.

> if so, I need to start using
> it for my packages. Are you going to create an SMDVSInstaller?

Yes, I probably should.

> About the Manager - are you aware that you have very few class comments?

It occurred to me ;).

> well usually your code is very clear and the intentions are obvious, but
> I didn't get the Manager, and the division of labor between it, the
> package, the dumper, and the packagePanel GUI.
>
> Could you elaborate on this?

Right.  The basic idea is:

PackageInfo - models the internal representation of a package (what
methods/classes in the image it contains, etc).

PackageManager - knows how to find the external representation of a
package (eg, a fileOut in directory foo) and coordinates filing the
package in and out (by creating the appropiate loaders and dumpers).

PackageDumper - at the request of the manager, creates an external
representation for the contents of the package described by the
PackageInfo.

PackageLoader - parses the external representation of the package.
Compares this against the PackageInfo, and generates a changeset with the
differences.  Can then browse, fileIn, etc, this changeset.

The loader uses a bunch of Chunk classes which model various kinds of code
definitions.  It's possible that, if these were given enough smarts,
dumper/loader would become redundant and fileIn/out could easily be done
by the manager itself.  For now, however, for each external format you
need a triad of dumper/loader/manager.  The only fully implemented format
right now is the .st file, but a couple of others that would be nice to
have at some point:

- a directory of files (one per class? one per method?), possibly
packagable into a .sar file.  This would reduce CVS conflicts (although
there aren't that many anyway) and would allow you to browse the
repository at a finer granularity.

- database tables a-la StORe.  Could eventually become a pure-squeak
versioning system.

The idea of separating the manager and the PackageInfo is that you
might have the same package in different images, one of them loaded from a
fileOut and one of them, say, managed from a database.  Anything inherent
to the package itself goes in the package info, but the current external
representation is variable, and shouldn't go there.

That help?

Avi




More information about the Squeak-dev mailing list