[Kde-scm-interest] Mercurial

[Pierre THIERRY]

Scribit Thiago Macieira dies 04/10/2007 hora 09:57:
> I did consider it, for a time. But I stopped when I was told that, in
> order to create a branch, I'd need to clone the entire repository.

You don't need, you can. I don't use branches myself, though, because I
find the workflow with clones both easy and efficient.

But you can use either clones as branches or named branches inside the
repository.

> I did not verify this information first-hand.

At least, for a project the size of KDE, ask the DVCS' developpers about
the potential issues with it, directly. For what I know, partly from the
discussions for the Mozilla project, teams for Git, Bazaar and Mercurial
are all open to those questions. They are eager to resolve the issues
that would slow down their adoption, so raising them would even help
make these tools better.

> One advantage I heard about Mercurial was its compression. Again, not
> verified first hand.

By default, Mercurial has a storage of changesets that is efficient both
in space and speed. Retrieval of any revision of the history is done in
constant time WRT to the numbers of revisions in the repo.

Changesets are either compressed deltas or compressed snapshots. Each
time the volume of deltas stored since the last snapshot reaches some
level, a new snapshot is stored, so both old and new revisions are
retrieved quickly (whereas with only deltas, retrieval time is O(n) of
the number of revisions).

Mercurial's storage is also designed to be safe: any number of processes
can read the repo without locking it, and writing is an append-only
operation.

Chapter 4[1] of the Hg book[2] explains the basics of Mercurial's
internals.

  1. http://hgbook.red-bean.com/hgbookch4.html
  2. http://hgbook.red-bean.com/

> Hardlinking is very interesting.

Files that contain the repository information (one file per file in the
source tree) are hardlinked, and links are broken on modification, so
when doing a clone locally, you only use further disk space for the
working copy and the differences in history.

Quickly,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20071004/116353f8/attachment.pgp