>>>>> Arne Babenhauserheide <[EMAIL PROTECTED]> writes:
[...]
>> The total disk usage for the two repositories will typically be less
>> than the doubled disk usage for any one of them. (As the
> Mercurial offers the same, for GNU/Linux and Windows.
Indeed.
I assume that it will break the hard link as soon as a change is
committed for the file?
>> Also, it's possible to use a related local repository as an
>> additional source for changesets while cloning a remote repository
>> over the network, allowing for the bandwidth saving as well.
> Did you test the efficiency (and how often it can be used)?
I use it once in a while.
I assume that the efficiency is comparable to that of the
hardlinked repositories case. E. g., a (bare) clone of the
Linux 2.6.23's Git repository is about 1.3 GiB in size (as per $
du --apparent-size.) The size of the Linux 2.6.24's repository
clone made with an appropriate --reference= option is about 57
MiB in size. Assuming that the size of non-shared Linux
repository clone is about the same for 2.6.23 and 2.6.24, and
assuming that the network traffic is proportional to the cloned
repository size, it allows to estimate the efficiency as:
(- 1 (/ 57 1.3 1024))
=> 0.957
roughly 96%.
>> Also, as Mercurial records only the parents of the revisions (and
>> not all their ancestors), it should become challenging to implement
>> the ``cherry-picking'' feature. (Though I don't
> There's a Google Summer of Code project doing that.
> And Mercurial knows the parents of parents, so it knows the whole
> history step by step. It avoids keeping duplicate data that way.
That's the point.
Consider, for example, branches A and B, containing revisions
A.1 .. A.3 and B.1 .. B.3, so that A.1 and B.1 are direct
descenders of some revision C.1. Then, one wants to merge the
change B.2 (the change between B.1 and B.2) into the branch A
(as A.4.) There, one cannot simply use A.3 and B.2 as the
parents for A.4, since that would imply that B.1 is also an
ancestor of A.4. But the whole point of cherry-picking is that
it /doesn't/ become one.
Of course, one may produce a diff (B.1 -> B.2) and then apply it
to A.3, making A.4, but it won't be tracked by Mercurial. (Thus
leaving the possibility for applying a change twice, or not
applying a change at all.)
Note also that if, e. g., B.1, B.2 and B.3 are all get merged
into A, but in some different order (e. g., the revision A.3
combined with patch B.2 becomes A.4, B.3 with A.4 becomes A.5,
and B.1 with A.5 becomes A.6), then the final revision /has/ the
whole B branch in its ancestry, and thus B.3 /could/ be
considered a ``parent'' of A.6 in Mercurial terms (despite that
B.3 was merged into A not in A.6 but in an earlier revision.)
[...]
> As a plus, I like the Mercurial documentation very much. Even
> advanced stuff can be found quickly.
I've never had any serious need for documentation for Mercurial,
but (unfortunately) I could easily believe that it's better than
the one supplied with Git.
[...]
