On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > [Cc: gmane.comp.version-control.git, > gmane.comp.version-control.mercurial.general] > > walt <w41ter@xxxxxxxxx> writes: > >> No, no, I'm not the one calling for a vote. You old-timers here >> will know the name Matt Dillon, who is leading the dragonflybsd >> project (www.dragonflybsd.org). >> >> Matt is the one who is calling for the vote in his thread "Vote >> for your source control system" in the dragonfly.kernel group, >> accessible via nntp://nntp.dragonflybsd.org. >> >> I've already cast my vote for git, which I confess is not very >> honest because I've never even tried mercurial. I would truly >> be grateful to anyone here who knows both git and mercurial who >> could contribute verifiable facts to that debate. <snip/> > 3. Repository design and performance. > > Git is designed around idea of content adressed object database; > objects are adressed by their content (by SHA-1 of their type and > content). Commits for example have information about author and > comitter, pointer to zero or more parent commits, and pointer to > tree object (representing top directory in project). Branches > and tags are just pointers to DAG (Direct Acyclic Graph) of > commits; current branch is denoted by HEAD pointer to branch. > There is explicit staging area called 'index', used for conflict > resolution dureing merges, and which can be used to make commit in > stages, allow uncomitted changes in tree (in working directory). > Git design supports very well multiple branches in single > repository, and tracking changes in multiple remote repositories > each with multiple branches. > > Mercurial, from what I have read of its documentation, and from the > few discussion on #revctrl IRC channel, and from what I understand > is based on changes stored per file, with information about files > and their versions stored in manifest (flat) file, and with changes > described in changelog-like file (changerev). One of limitations > of "record" database (as opposed to Git's object database) is that > commits can have zero (root commit), one or two (merge commits) > parents only. There is apparent in design that Mercurial was > developed with single branch per repository paradigm in mind. > Local branches from what I understand are marked in CVS-like > fashion using tags. Tags are implemented as either local to > repository and untransferable, or as .hgtags versioned file with > special case treatment. (But I'm obviously biased here). > > Git and Mercurial have similar performance, although it is thought > that due to design Mercurla has faster patch applying and is > optimized for cold cache case, while Git has faster merging and is > optimized for warm cache case. > > Mercurial may have (or had) problems with larger binary files, from > what I have heard. The fact that hg is changeset based means that certain operations are slower, like checkout a specific commit. In hg my bet is you would need to gather a bunch of changesets while in git the operation is done in a single step. It also means that bare clones are not possible in hg, or at least very complicated. Note: I'm not sure if what I'm claiming is correct. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
