[NIT] Managing repositories in MC

Colin Putney cputney at wiresong.ca
Mon Sep 22 02:33:02 UTC 2003


On Sunday, September 21, 2003, at 03:51 PM, Avi Bryant wrote:

>
> On Sun, 21 Sep 2003, Colin Putney wrote:
>
>> I've begun to think that what we really want is eager copying of
>> verison *info* and lazy copying of versions themselves. Then all the
>> clients have a clear picture of what the version tree looks like, but
>> you only need to ship around the bulk of the data when you actually
>> need it for a load or merge.
>
> Yeah, that's obviously a good optimization.

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.

> I think it could quite possibly be introduced as exactly that, however.
> Say you started out by eagerly downloading Versions.  Then you 
> introduce a
> RemoteVersion that only stores the metadata, but hangs onto a URL for 
> the
> full thing for the first time it's asked for its #snapshot instead of
> #info or #package.

And this is exactly why I want to consider the idea of separating data 
and metadata a little more broadly than as optimization. I really, 
really dislike RemoteVersion. I think it goes in the opposite direction 
from the distributed model that's been emerging.

We all agree that distribution is good, but we haven't talked much 
about what it is that we want to distribute. I haven't quite pinned it 
down myself, but I think the most important thing to distribute is 
authority.

I really like the fact that I can download Seaside from SqueakMap, make 
some changes, commit to my own repository and share that with the 
world. I don't have to get commit rights to the canonical Seaside 
repository and my version is just as accessible to other users or 
developers as Avi's. If Avi releases a new version, and some third 
developer wants to merge my work into that, he can do it easily, with 
all history information intact. You just can't do that with CVS, SVN or 
any other system I know of.

Central to this is our idea that a repository is just a collection of 
versions, nothing more. Versions can move between repositories, 
repositories can be merged or divided, repositories can be moved from 
on url to another. There is *no* canonical home for a package or even a 
version. To put it another way, I'd like to see the MonticelloSphere 
evolve into something more like Freenet than the web. A particular 
version might be located in more than one repository, and would have a 
tendency to migrate to the repositories near the users that use them 
the most.

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.

Colin



More information about the Squeak-dev mailing list