[opam-devel] OPAM 1.3 roadmap
thomas at gazagnaire.org
Wed Feb 25 11:20:27 GMT 2015
>>> 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.
> Also, git is pretty slow at handling many large binary files (which is
> the single worst workload you can use it for). Delta compression
> takes noticeable time on my blog, which has a mere 500MB of photos.
Git is perfectly capable of handling large blobs if the zlib compression level is set to 0:
$ git config --global core.compression 0
But yes, the delta compression algorithm has been designed for code source files, so it might be non-optimal (ie. `git gc` will not be as efficient as expected). Anyway, version controlling .opam is a nice idea, but it definitely needs some eval and more coner-cases thoughs to make it work nicely for end-users.
More information about the opam-devel