[opam-devel] OPAM 1.3 roadmap

[Guillaume Claret]

We are using Git on an OPAM repository to optimize the Coq benches (not 
recompiling the dependencies). But there is a major limitation: Git does 
not see empty directories, what leads to some bugs sometimes.

Maybe other systems like Mercurial have less problems, else there may be 
the solution of dedicated backup tools, like https://github.com/bup/bup

Guillaume

The 02/25/2015 12: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.
>
>> 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.
>
> Thomas
>
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel
>