On 25 Feb 2015, at 11:23, Peter Zotov <[email protected]> wrote: > > 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.
In this situation, the git base can be rebased after a successful upgrade to remove the old version of the compiler and save space. In the event of failure, it would allow for a fast switch back to the old working version. -anil _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
