On 2 March 2012 22:18, Dale Henrichs <[email protected]> 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" <[email protected]> > | To: [email protected] > | Sent: Friday, March 2, 2012 9:46:39 AM > | Subject: Re: [Pharo-project] Monticello Version Info > | > | On 2 March 2012 17:32, Dale Henrichs <[email protected]> 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" <[email protected]> > | > | To: [email protected] > | > | Sent: Friday, March 2, 2012 9:27:39 AM > | > | Subject: Re: [Pharo-project] Monticello Version Info > | > | > | > | 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_.) > | > | > | > | 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 > | > | > > | > | > | > | > | > > | > | >
