[NIT] Managing repositories in MC

Avi Bryant avi at beta4.com
Mon Sep 22 03:17:10 UTC 2003


On Sunday, September 21, 2003, at 07:33 PM, Colin Putney wrote:

> It does go beyond optimization, though. Right now, VersionInfo is only 
> ever part of a Version. Occassionly we'll grab a version's info, 
> examine it and then throw it away. I'm talking about making 
> VersionInfo more of a first class entity, one that might be stored or 
> transmitted on it's own.

<snip>

> To get back to the problem at hand, I'd much rather have a 
> user-definable search order for repositories than a url pointing back 
> to the snapshot. More generally, I'd like to have Monticello work with 
> naked VersionInfo much of the time, and retrieve or reconstruct full 
> Versions only when necessary.

You make good points here.  If we're going to be moving in that 
direction, I would propose the following entities:

VersionReference - contains the actual name and UUID of the version
VersionHistory - a tree of version references.  Log, date, etc, should 
maybe be in these nodes as well.
VersionInfo - contains a VersionHistory and a Package.
Version - contains a VersionInfo and a Snapshot.

There are two motivations here.  One is to bring Package into 
VersionInfo, which makes VersionInfo objects more useful on their own - 
otherwise, you can't group/filter by package which is an obvious thing 
for a UI to want to do.

The other is to introduce a lightweight object for when really all you 
want to do is refer to a version by ID, and you don't need all the 
ancestry - which is true in many of the places that we currently use 
VersionInfo.

Anyway, with some reasonable way of representing VersionInfo on its 
own, I can definitely picture having a somewhat centralized "feed" of 
VersionInfos that you would subscribe to (ie, that would automatically 
download itself into your local cache and build pretty ancestry trees, 
etc), combined with the distributed searching through repositories that 
we currently have for actually getting the snapshots.



More information about the Squeak-dev mailing list