dist-hg proof-of-concept ready for use

[Carl Worth]

On Wed, 15 Nov 2006 05:43:11 -0500, Alan Cox wrote:
> No Linus told me about that and it and the disk fsck were consistent. It
> seems that during the rebase it pulled the new stuff out, moved forward
> and then in dying the stuff to reapply after the rebase vanished somewhere

OK, I can't hazard a guess as to what happened in that situation. It's
too bad we can't do any post-mortem on it.

The way git's object store is designed it really should be safer than
other systems. All of the "normal" commands only create new objects in
the object storage with a one-file-per-object correlation. So normal
commands only create new files, never modify or delete files.

The only "abnormal" commands in that sense are the prune commands
which exist specifically to delete objects. And these would generally
be run only after packing which would generally be run only after
backing up the repository, (in a cron job, say).

So your rebase should have created new objects, but all the old
objects should have been entirely untouched, (at worst left "dangling"
and needing the fsck pass to recover a reference to them).

[The discussion above is based on the design---I haven't actually
audited git's implementation to make sure it doesn't delete files in
the object store except in the case of prune.]

Contrast this "only create new files" aspect of git's design with the
mercurial design. With mercurial, every operation modifies existing
files by appending new data to them. It does this in a journaled
sense by first writing out enough information so that it can read the
expected file sizes before and after the append operation. This allows
it to recover from an interrupted append operation by truncating the
file to the pre-append size. [This is my understanding of mercurial
based on discussion with Matt Mackall in January---please correct me
if I made any mistakes or if things have changed since then---I do
notice that in May mercurial picked up a new repository file format.]

So, when disaster strikes, at worst git will be creating new files,
while hg might be modifying or truncating existing files. Git
obviously relies on fewer paths through the kernel to avoid bad things
happening.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20061115/a046e968/attachment.sig>