On 2012-03-02, at 20:09, Frank Shearar wrote: > On 2 March 2012 18:52, Camillo Bruni <[email protected]> wrote: >> >> On 2012-03-02, at 18:27, Frank Shearar wrote: >> >>> On 2 March 2012 17:02, Dale Henrichs <[email protected]> wrote: >>>> Sven, >>>> >>>> A Monticello mcz file is a version data base for a single package .... Git >>>> is a version data base for a directory structure ... >>>> >>>> Monticello has branching by convention (change the name of a file to >>>> create the branch), although the mcz ancestry handles branches just fine. >>>> In Git branches are first class objects ... it is difficult to do things >>>> in git if you are not on one branch or another ... >>> >>> Bearing in mind that a branch is just a pointer to a commit: look in >>> your blah/.git/refs/heads/ and each file is a branch containing the >>> SHA1 id of the head of that branch. (And each commit knows its >>> ancestor/s, just like an mcz file, except that the hash means the >>> relationship's based on the commit's _contents_, not its _name_.) >> >> that's right. However mcz store a bunch of redundant data in there by having >> the complete ancestor history in there. in git you only store the pointers / >> hashes to the immediate ancestors which is enough in most cases. >> >> right now we spend quite some time in just parsing the complete ancestor >> history, whereas this could be done lazily or in a more efficient format. > > But since there's nothing stopping you from losing an mcz (by accident > or on purpose: it's happened to me by accident), storing the entire > history lets you know _something_ about the history. Otherwise, with > the git-style pointer, you'd be screwed if you wanted history. "Oh, > where's this mcz? I have no idea, nor any idea where to look!" > > Of course it's not necessary to parse the whole lot, which I suspect > is what you mean by "lazy".
right. I honestly don't care about the data being around ;) that is indeed a nice integrity property of an mcz version. But as igor pointed out, we should consider a slightly more efficient way of storing / retrieving data. the current approach is just too slow I think. I don't know what happens on server side of squeaksource, but is it easy to just add another entry to an mzc file? To me this seems like an easy solution to speed up MC quite a bit on Pharo but still keep it backwards compatible on other platforms. best cami
