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". frank > cami > >> >> frank >> >>> You can merge with Monticello and you can merge with Git ... >>> >>> The big difference is that Git allows you to version a bunch of files >>> together and with Monticello you are versioning a single file. >>> >>> Part of what Metacello was invented to do was to create a "data base" of >>> versioned collections of mcz files ... Git was designed to manage >>> collections of files... >>> >>> Is this what you were asking? >>> >>> Dale >>> >>> ----- Original Message ----- >>> | From: "Sven Van Caekenberghe" <[email protected]> >>> | To: [email protected] >>> | Sent: Friday, March 2, 2012 12:31:42 AM >>> | Subject: Re: [Pharo-project] Monticello Version Info >>> | >>> | >>> | On 02 Mar 2012, at 01:52, Chris Cunningham wrote: >>> | >>> | > The issue is that Monticello is setup for distributed processing, >>> | > and >>> | > allowing for multiple repositories, some of which may not be >>> | > available >>> | > to all of the users for a project. For instance, a project might >>> | > be >>> | > developed internally (or on the developers hard-drive) until they >>> | > feel >>> | > comfortable distributing the code later. So, publicly, you get >>> | > version 12, 17, 34, and 37. There is no access to the intermediate >>> | > ones (unless you happen to be the one that created them and didn't >>> | > release them). The 'whole ancestry' let's you do diffs off of a >>> | > version derived from 37 against one derived from 34 - the ancestry >>> | > can >>> | > determine that version 34 if 'common', and work from there. [Note >>> | > that just numbers aren't enough - the original developer, say, cbc >>> | > could have version cbc.34, while you could have, say, >>> | > CamilloBruni.34, >>> | > but yours is based off of 17 (since you picked up that verison and >>> | > started working there). So, merging cbc.37 with CamilloBruni.34 >>> | > would >>> | > need to pull down cbc.17 for a good merge to work.] >>> | > >>> | > At least, that's my understanding from long ago discussions. >>> | >>> | This makes sense, but how is this handled with git ? >>> | >>> | Sven >>> >> > >
