+1 I would like that we respect a bit MC. Because so far this is the only thing that we have that is working well. Ranting about it does not make it any better (Camillo this is not about you in particular but in general).
Stef On Mar 1, 2012, at 11:11 PM, Nicolas Cellier wrote: > I think the main reason is that you cannot load just the metadata, but > the whole mcz when you need to dig into the history... > That ain't cheap, and that happens when you merge more or less distant > branches. > > Also, it's not unusual to upload directly version N+5 without the > whole N+1 to: N+4 ancestry... > In this case MC can still find a common ancestor. > > Nicolas > > Le 1 mars 2012 23:07, Dale Henrichs <[email protected]> a écrit : >> For the majority of use cases I think that the immediate ancestor is the >> only one needed ... so you might be onto something here... >> >> Dale >> >> ----- Original Message ----- >> | From: "Camillo Bruni" <[email protected]> >> | To: "Pharo Development" <[email protected]> >> | Sent: Thursday, March 1, 2012 1:53:48 PM >> | Subject: [Pharo-project] Monticello Version Info >> | >> | I am still having a look at the Monticello implementation. >> | Now coming from the git world, this seems very weird: >> | >> | Why does each Monticello version store the complete ancestor history? >> | >> | ------------------------------------------------------------------------ >> | >> | Wouldn't it simply be enough to keep pointers to the immediate >> | ancestors, and then lazily load and cache them? >> | >> | Where is the complete ancestry needed, besides diffing/merging? >> | >> | ------------------------------------------------------------------------ >> | >> | The current setup implies that something like >> | >> | MCCacheRepository default loadVersionFromFileNamed: >> | 'SLICE-Issue-5416--Improve-MC-version-loading-CamilloBruni.1.mcz' >> | >> | takes around 1.5 seconds to complete, whereas this could be done in a >> | fragment of a second for most cases... >> | >> >
