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 >
