[Pharo-project] Monticello Version Info

Frank Shearar frank.shearar at gmail.com
Fri Mar 2 17:53:26 EST 2012


On 2 March 2012 22:18, Dale Henrichs <dhenrich at vmware.com> wrote:
> 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)...

Yes. No argument here! Especially when one wants to have a project
split up into sub-packages - test, core, extension packages - and you
have to do a bit of extra work.

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: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