Frank, That's right ... the major difference between the two is that git manages multiple files ...
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 | > | |
