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
_______________________________________________
opam-devel mailing list
[email protected]
http://lists.ocaml.org/listinfo/opam-devel
