But the goal of making the image smaller is congruent with the goal of making Morphic smaller, which would be congruent with the desire for Monticello to be "scalable". So the solution should be smaller packages, not more and bigger tools. Besides, the measure of scale you've chosen is an build / initialization step, which can much more afford to be "slow", especially if the dream is to just have it sit and build 24 hours a day. A better non-scaling measure to recognize in Monticello, IMO, is using FileBased repositories, which require enumeration of an ever-growing number of versions for many of its operations. Using a database-backed MC repository solves that. On Sun, Jan 29, 2012 at 11:48 AM, Philippe Marschall <kustos@gmx.net> wrote:
On 29.01.2012 17:02, Sven Van Caekenberghe wrote:
On 29 Jan 2012, at 15:30, Philippe Marschall wrote:
As for scale.. monticello scales well.
No, it does not.
Please elaborate: I really can't see the difference between doing a merge (either an easy one or a more diffucult one over multiple files, spread over a couple of days, with intervening changes by others) using either Monticello or Git.
The scalability limits of Monticello are well understood. PackageInfo doesn't scale, at all. You put too many classes in a package, and snapshotting gets really slow. Don't believe me? Make a change in Morphic which has only 200 classes and save it.
And it's not like loading is any faster. Seaside takes 10 minutes to build from locally cached [1] packages, only 12 seconds go to running tests [2]. This makes C++ compilation times seem fast by comparison.
 [1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend  [2] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testRep...
Cheers Philippe