Space savings: cherry picking, partial cloning, overlays, history trimming, offline revisions, and obliterate

[Jared Hardy]

On Fri, Mar 21, 2008 at 6:19 AM, Martin Gadbois
<martin.gadbois at colubris.com> wrote:
>  I like Mercurial, but I ran into this warning on some occasions, and I
>  do not know if your images and other binary data could be affected:
>
>  $ hg add linux-2.4.32.tar.bz2
>  linux-2.4.32.tar.bz2: files over 10MB may cause memory and performance
>  problems
>  (use 'hg revert linux-2.4.32.tar.bz2' to unadd the file)

Oh yes, we go over 10MB files routinely. Is there any configuration
setting to set the threshold higher? We would probably bump that up to
a few hundred MB, in our use case. This is where Forest seems very
handy, where we might have a normal code repository, in the same
forest tree with a big art repository, each with different threshold
warning settings.
    Do you know, does this size refer to the actual file, or the
snapshot/diff size? Most of our files are diff-able, because they are
raw uncompressed, so that may help temper this issue.

>  Also note that there is no way to "lock" a binary file. If two or more
>  people change the file at the same time, some modification will be lost
>  (no merge possible).

You caught me! That is an accurate prediction of my next feature
proposal e-mail, but I wanted to make that a separate thread, for
clarity. ;)
    SVK doesn't have locks support directly, either. I used the parent
SVN repository lock status, and wrote some batch wrappers for SVK that
would reference SVN repository locks directly, before allowing certain
operations.
    I planned to do the same thing with Mercurial as well, but I hope
at some point to write it as an Extension, rather than a mere wrapper
script. I would start out simple, where only the "parent"
repository(s) would be asked for a lock. Even that simple
implementation would allow for many deep star push/pull topologies --
lock requests just propagate to a shared root. I think it could be
extended to reference "lock peer groups" -- a set of trusted friends
who all have lock "voting" rights. Any non-responsive voters would be
assumed offline, and forced to sync locks on the next connection. Then
you go into fancy optimizations, like LAN peer broadcast lock vote
requests, multicast lock vote requests, etc. You could even determine
"needs-lock" status automatically, by assigning it to any file type
without a defined merge tool. Then, into madness... But that's for
another thread. ;)
    I need to do some more reading (and coding) before making any
official lock feature proposals. Early guidance doesn't ever hurt,
much.

    Thanks!
    Jared