Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-03-22 18:44:28

Dave Abrahams <dave_at_[hidden]> writes:

> on Thu Mar 22 2012, Martin Geisler <mg-AT-aragost.com> wrote:
>
>>> This kind of mental model is stimulated by git. It explains why git
>>> users make a fuss about amending, rebasing and efficient branching
>>> and merging.
>>
>> I'm afraid I don't agree with this. The version control systems that
>> came after CVS switched to storing repository-wide snapshots. CVS was
>> a collection of RCS files and so completely file-centric. SVN,
>> Mercurial, Git, ... are all repository-centric. Conceptually they
>> work by storing a series (linear or not) of working copy snapshots.
>>
>> Darcs is a possible exception to this: I think it might fit more
>> closely to your unit-of-work model since it models the repository
>> state as a result of a number of patches (units-of-work).
>
> People get hung up on this all the time, but whether the storage
> format is fundamentally snapshots or diffs is not really important.
> They're isomorphic to one another.

Yes, that's mostly true. Both Git and Mercurial conceptually stores
snapshots of your working copy. These snapshots are of course heavily
delta compressed -- otherwise we couldn't do DVCS in the first place.

But I say that they conceptually store snapshots since that's what
commands like 'hg diff' operate on. When you 'hg diff -r 1:2', then
Mercurial has to go out and re-compute the patch that brings you from
revision 1 to 2.

People often think that changeset 2 "contains" this diff, but it's more
complicated that this: the deltas we store on disk don't correspond
directly to this diff. This especially true for a merge changeset where
the deltas on disk are made on a per-file basis against the parent that
produces the smallest delta.

> Git, like any other modern tool, provides commands that support both
> views of the history. Rebase, for example, treats your commits as
> units-of-work and "replays" that work on a new base commit. Many other
> elements of the interface treat commits like snapshots.

It actually don't replay anything: it does a series of three-way merges,
and three-way merges are an inherently snapshot based thing.

-- 
Martin Geisler
Mercurial links: http://mercurial.ch/