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