[Pharo-project] Monticello Version Info

Frank Shearar frank.shearar at gmail.com
Fri Mar 2 12:46:39 EST 2012


On 2 March 2012 17:32, Dale Henrichs <dhenrich at vmware.com> wrote:
> Frank,
>
> That's right ... the major difference between the two is that git manages multiple files ...

Well, kind've. A blob usually does contain the contents of a file.
(http://book.git-scm.com/1_the_git_object_model.html) That is, when
you checkout some branch you end up with a directory structure
containing files, which is what you're talking about. It's probably
better not to think of them as files: the blobs might look like files
in your working copy, but they're just, well, blobs. Chunks of binary
stuff that, for versioning software, happens to be UTF-8 encoded plain
text (or whatever).

(This is exactly why, from standing inside an image, mapping a method
to a file makes sense: a method's a single unit of stuff.)

Which is probably why you express yourself this way: Monticello turns
a whole bunch of methods + comments + class definitions into a big
snapshot.st - a single file in the zip - and a corresponding list of
changes to an image - "add this, remove that".

Both are still versioning a collection of things together, though: I
see no problem with saying "Monticello package Foo-fbs.2 means that
you have this class with this definition and that method with that
definition". That's pretty much the same thing as saying "git commit
id deadbeef means that you have this file with these contents and that
file with those contents".

frank

> Dale
>
> ----- Original Message -----
> | From: "Frank Shearar" <frank.shearar at gmail.com>
> | To: Pharo-project at lists.gforge.inria.fr
> | Sent: Friday, March 2, 2012 9:27:39 AM
> | Subject: Re: [Pharo-project] Monticello Version Info
> |
> | On 2 March 2012 17:02, Dale Henrichs <dhenrich at vmware.com> 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_.)
> |
> | 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" <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 mailing list