RFC: version (big) file snapshots with storage outside a Mercurial repo with snap

[Martin Geisler]

Klaus Koch <kuk42 at gmx.net> writes:

Hi Klaus

> [...]
>
> In comparison to other extensions like bigfiles or hg-bfiles, this
> extension can keep its re-implementation of Mercurial functionality
> down to a minimum. No need for handling special files or directories,
> and for hiding them and the big files from Mercurial. One uses the
> usual Mercurial commands to commit, push or pull snapped files.

This is very nice! It is my impression that the bfiles extension by Greg
also aims at hooking into the normal add, commit, push, pull commands
but that this just hasn't been done yet.

Do you know of other differences between your extension and the two
other extensions? I'm asking since having three extensions for this task
is two too many and it is a shame to see such duplication of effort.

> Sha1 collisions may be very unlikely, but they are not impossible.

As a cryptographer, I will say that they are impossible in practice, as
least at this time. If you are lucky enough to find a collision, you
should not work around it, you should instead save the data carefully
and send a mail to an internaltional crypto conference :)

Finally, I noticed a lot of places in the code that read

    finally:
        del(fsrc)
        del(fdst)
        del(frep)

just before the end of the function/method.

Is that meant to trigger the close method of those file handles? If so,
then calling close explicitly is better since there is not guarantee
exactly when the objects are reclaimed.

The normal CPython implementation will clone the files when you delete
the last reference to them since it uses a reference counting scheme,
but this is not true for the other Python implementations that use a
more modern garbage collector.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/