[opam-devel] OPAM 1.3 roadmap

[Peter Zotov]

On 2015-02-25 14:20, Thomas Gazagnaire wrote:
>>>> I'm less sure about the viability of recording installed files
>>>> strictly -- I view thatas an advisory rather than enforcement-based
>>>> mechanism.  The reason I like the "make ~/.opam a git store" is that
>>>> its possible for applications to write directly into the store as 
>>>> they
>>>> do right now, but still let us track changes precisely.  In fact, if
>>>> we forbid subshells from writing into `~/.opam/.git`, this would be
>>>> a production grade solution that also offers instant-rollback in 
>>>> case
>>>> of compilation errors (no more waiting for a full recompilation of
>>>> the original dependencies!).
>> 
>> Please don't make .opam a git store. Even with one snapshot, it means
>> that my .opam would be 11G instead of 5.5G it currently is. What's 
>> worse
>> is that every recompilation or upgrade would balloon the store even 
>> more.
>> I can easily anticipate it filling the entirety of my 500GB drive,
>> for example. That's absurd.
> 
> It's not so simple, Git uses implicit hash-consing to share as much
> blobs as possible, so snapshotting is free. This also means that
> switches will be able to share binary blobs (a long-standing request).
> All of this needs to be evaluated properly.

I know. The issue is that reinstalls tend to change large amounts of
files. Imagine upgrading Core, or even worse, the compiler. Even
with delta compression there would be no, or almost no, sharing
among the biggest blobs; without it, less so.

-- 
Peter Zotov