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