>> At a minimum please start more conservatively.  Older than two years
>> but ensuring to keep a minimum of 10 versions of each package
>> regardless of age.  That way we can at least keep SOME history easily
>> accessible for all packages and let's see how much speed that gains
>> us.
>
> But you are aware that all the history meta data is in each and every MC package?

Yes, I am familiar with the entire MC model.

> How often do you actually need to look at a package as it was more than a year ago? And, in that case, how much additional
> effort would it be in that case to select the "attic" repository instead of the "trunk" repository?

We have ~75 packages in the trunk.  Minimum 10 versions per isn't too
much to expect the system to handle, is it?  Sure, the concession of
having to check the archive repository is not-so-bad but I just
concerned cutting to the bone (down to 1 version) would rear its
inconvenient head too often for a not-enough gain in speed.

> (that is, if we don't change the tools to automatically look in attic for stuff not found in trunk).

Yeah, maybe one or two select tool hacks would make it more
transparent.  But we'd have to choose carefully or it would defeat the
speed up.

> Monticello is a purely client-side SCM. You should take a look at the SqueakSource code base. It doesn't use Monticello code for its basic operation at all. It's just a WEBDAV server treating MCZ files as binary blobs.

Ok, didn't know that.

> Assuming that the HTTP listing of gazillions of versions is the bottleneck, neither of those would help significantly. (of course, we need to profile where the slowness actually comes from).

Bad bad -- what use-case thinks it needs to list gazillion versions?
Oh, is that, "Updating trunk..." I see?