Ideas, Experiences required for changes managements

Daniel Vainsencher danielv at
Tue Apr 1 01:33:21 UTC 2003

I don't know, I don't think forcing people is the issue here. Most
people loading code are loading it either as part of their own code
management system, whatever that may be, or from SM, or from the
FileList. Whatever tools we make available there, will determine what
people can use.

In SM, packages of th DVS type, could preferentially be loaded using an
appropriate loader, that detects and raises exception for redefinitions.
This will be quite easy as soon as we start using services instead of
hardwired options in SMLoader. We could start doodling with this now,
nothings stopping us.

Installing DVS could also add this service to the FileList, and that's
most of the coverage needed.

We don't need to maintain an absolute invariant here, we need to give
people a way to often detect when they're loading something that will
cause problems in the future.


Avi Bryant <avi at> wrote:
> On Mon, 31 Mar 2003, John W. Sarkela wrote:
> > Exactly the point. Perhaps DVS could in the future signal a
> > Notification upon redefinition. That way redefinitions could
> > be easily loaded (with notifications of redefinitions that are
> > typically ignored) but that allows a more careful loader policy
> > to intercept the notification, preferably prior to changing the
> > state of the image.
> An interesting point.  The problem is that most people loading DVS
> packages are doing that outside the control of DVS, ie, they're just
> filing them in as changesets.  This means that any such notification has
> to be embedded in the fileout, which gets a little bit ugly - the most
> robust thing would be to have a doIt at the top of the fileout that
> checked, for each extension method in the package, whether that method
> already existed in another package and was about to be overwritten, and
> raised a notification if so.
> Perhaps it's time to look at something halfway between Monticello (which I
> realistically don't have energy to maintain right now) and DVS - ie,
> something that still relies on CVS for versioning, but drops backwards
> compatibility with chunk file format.  That would allow these kinds of
> checks to be made a lot less hackishly, since you'd force people to be
> loading the package in the "safe" way.  Thoughts?  Is there any real
> reason to keep using chunk format?
> Avi

More information about the Squeak-dev mailing list