[squeak-dev] Making trunk repo faster

Chris Muller asqueaker at gmail.com
Wed May 23 20:05:27 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..


On Wed, May 23, 2012 at 2:32 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 23.05.2012, at 21:28, Chris Muller wrote:
>
>> We will need richer criteria than simply age.  Consider a package that
>> didn't change in the last year -- purging it would provide little gain
>> while seriously limiting the repository's ability to do its SCM duty
>> (compare, merge, revert, etc. with prior versions).
>>
>> Before we knee-jerk react by hacking down our persistent model just to
>> accomodate MC's unsustainable design, may we first at least consider
>> to upgrade MC to be more scalable?
>>
>> For example, one of the things that is "slow" is due to merely
>> applying the underlining and highlighting in the Versions browser.
>> One thing that can be done here is quit going back all versions and
>> instead just the prior 20 or so...
>
>
> I don't think that's enough. Try clicking the trunk repository on the website.
>
> - Bert -
>
>
>


More information about the Squeak-dev mailing list