[Pharo-project] Monticello Version Info

Dale Henrichs dhenrich at vmware.com
Fri Mar 2 17:18:38 EST 2012


Frank,

  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". 

Okay I don't have a problem with that sentence.

  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".

If you are implying that a single package version can be versioned in git with same semantics as Monticello, then I will agree. 

Again, where git and Monticello differ is that one can version multiple packages with git (same version/same commit) and one cannot with Monticello (different files for each package and no shared commit history)...

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:46:39 AM
| Subject: Re: [Pharo-project] Monticello Version Info
| 
| 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