Re: [VOTE] git versus mercurial (for DragonflyBSD)

["Felipe Contreras" <felipe.contreras@gmail.com>]

On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> [Cc: gmane.comp.version-control.git,
>     gmane.comp.version-control.mercurial.general]
>
> walt <w41ter@gmail.com> 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