[squeak-dev] Making trunk repo faster

Chris Muller asqueaker at gmail.com
Wed May 23 20:52:01 UTC 2012


>> That's why I said "for example", it's not a silver bullet.  My only
>> point was that unless we address the inherent scalability issue then
>> the suffering will be on-going even as we scramble to discuss it and
>> move files around and then hunt for them later for basic SCM needs.
>> Seems worthy of a little thoughtful discussion at least..
>
> Agreed. So, as I wrote in the original post: "Other ideas?" :)

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.

The older ones should still be accessible in a separate repository.

===

As far as other ideas:  Change SqueakSource's implementation to stop
using MCFileBasedRepository which I suspect is the root of the
scalability issue.  A Magma-based MC backend performs steadily
regardless of size, I'd love to test this if someone can get
SqueakSource going on Squeak 4.3.  I also know there are other
solutions like ss3 and SmalltalkHub although SH may be too different
to easily migrate..


More information about the Squeak-dev mailing list