Live data from Hacker News

Elfshaker: Version control system fine-tuned for binaries

github.com

11–20 of 115 posts

Re: Elfshaker: Version control system fine-tuned for binaries

#16
post #6
post #3

I find the description a bit confusing, is there and example where we can see the usage?

Same here. There is a usage guide, which helped a tiny bit: https://github.com/elfshaker/elfshaker/blob/main/docs/users/... Honestly, I sort of looked at it for conventional backup strategy...as in, i wonder if it could work as a replacement for tar-zipping up a directory, etc. But, not sure if the use cases is appropriate.

Author here. We'd love this to be a thing, but this is young software, so we don't recommend relying on this as a single way of doing a backup for now. Bear in mind that our main use case is for things that you can reproduce in principle (builds of a commit history, see manyclangs).

Re: Elfshaker: Version control system fine-tuned for binaries

#17

Does it make a sense to turn it into fuse fs, with transparent deduplication?

Author here. Maybe, it's a fun idea. I have toyed with providing a fuse filesystem for access to a pack but my time for completing this is limited at the moment.

Re: Elfshaker: Version control system fine-tuned for binaries

#18
post #7

This should be integrated with Cargo to reduce the size of the target directories which are becoming ridiculously large.

Author here. I'm unsure whether this would apply very well to cargo or not. If it has lots of pre-link object files, then maybe.

Re: Elfshaker: Version control system fine-tuned for binaries

#19
post #4

Huh, interesting, could you maybe use this as an in-repo alternative to something like git-lfs?

Author here, I don't currently know how this compares to git-lfs. It it is possible git-lfs would perform quite well on the same inputs as elfshaker works on. If git-lfs does already work well for your use case I'd recommend using that rather than elfshaker, as it is more established.

Re: Elfshaker: Version control system fine-tuned for binaries

#20
post #15

Does this work well with image files? (PNG, JPEG, etc)

Author here, it works particularly well for our presented use case because it has these properties:

* There are many files,

* Most of them don't change very often,

* When they do change, the deltas of the binaries are not huge.

So, if the image files aren't changing very much, then it might work well for you. If the images are changing, their binary deltas would be quite large, so you'd get a compression ratio somewhat equivalent to if you'd concatenated the two revisions of the file and compressed them using ZStandard.

Post reply on HN