Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-03-23 09:39:44

Dave Abrahams <dave_at_[hidden]> writes:

> on Thu Mar 22 2012, Martin Geisler <mg-AT-aragost.com> wrote:
>
>> 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.
>>>
>>> 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,
>
> In the sense that the commit contains its ancestry and a snapshot,
> yes, it does contain the 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.
>
> But "deltas stored on-disk" are completely irrelevant to the user
> unless she's fiddling about with the porcelain (low-level guts of the
> DVCS). Even for most expert users, it is *always, always, always* an
> implementation detail. My point is that we shouldn't be talking about
> this stuff here; it will just confuse the less-experienced people and
> adds /nothing/.

You're right -- I got carried away in details :-)

I'm only here to try and help people who are confused about what DVCS is
and what it brings to the table. The finer details are best discussed on
the tools' own mailinglists.

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