[squeak-dev] Making trunk repo faster

Bert Freudenberg bert at freudenbergs.de
Fri May 25 11:14:10 UTC 2012


On 24.05.2012, at 04:15, Chris Muller wrote:

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

Under which circumstances did you have to load a package version from trunk that's more than a year old? Honest question.

>> (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.

The normal update process does not access older versions. Neither does the committing of new versions. So I can't see how we would loose speed in regular operation.

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

Yep.

I see this a lot more often than it used to happen. At some point not too long ago someone put in an update at apparently every operation. If I click a specific version, there is *no need* to do a server listing. Can someone remember when and why that came in?

- Bert -




More information about the Squeak-dev mailing list