[Pharo-project] Monticello Version Info
camillobruni at gmail.com
Fri Mar 2 13:52:11 EST 2012
On 2012-03-02, at 18:27, Frank Shearar wrote:
> On 2 March 2012 17:02, Dale Henrichs <dhenrich at vmware.com> wrote:
>> 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.
>> 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?
>> ----- Original Message -----
>> | From: "Sven Van Caekenberghe" <sven at beta9.be>
>> | To: Pharo-project at lists.gforge.inria.fr
>> | 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
More information about the Pharo-dev