On Fri, 15 Nov 2002 danielv at netvision.net.il wrote:

> I think this all is great. Especially having our own CVS like
> repository, tailored for Squeak work sounds wonderful.

It's coming along nicely.  The model is basically there; what's needed now
is:

 - A good UI.  I know next to nothing about Morphic, so if someone wants
to help me build a great versioning interface, let me know.
 - Remote repository support.  Right now I only use the local
filesystem.  Colin's interested in doing a MySQL repository, I might
also look at doing an HTTP PUT based one.  Cees, can squeakfoundation.org
host a simple PUTtable repo?

> In the vein of lightweight modularity work, I think PackageInfo, as
> separate from the rest of DVS, and maybe with some additions/integration
> would make a good basis for packages in Squeak generally.
>
> So I think we should think whether we might want to (gasp) add this to
> the base Squeak image.

I agree, of course, which was partly why I broke it out from DVS to begin
with.  Thanks for the summary below - I should also point out that those
conventions are just those used by the default PackageInfo class.  It is
possible to override pretty much any of them using a custom subclass, and
thus describe any set of classes and methods in the image.  But for most
purposes, the standard conventions work very well.

I'll post the separated PackageInfo and the updated DVS this weekend; if
anyone's interested in previewing or working on Monticello (the versioning
system), let me know.

> A reminder for everyone of what PackageInfo does
> -
>
> It maintains clear, well defined specification of what code is in a
> specific package, and the related information required to load/install
> it (like related files).
>
> The way it does this is by using a convention (this is what might be
> controversial and I want opinions on) where:
> A. System categories PWS-Kernel, PWS-Actions and PWS-Swiki are all part
> of the PWS package, simply because a PackageInfo exists for that common
> prefix.
> B. The method FileList>>renderFile is also part of the same package,
> despite FileList not being in those categories, because the method is in
> the method category *pws (Asterisk followed by the package name). Such a
> method is called a class extension.