Re: Revision control

[Ivan Shmakov]

>>>>> Arne Babenhauserheide <arne_bab@web.de> 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.

[...]