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