There is metadata, which is for things like a filename-to-hash mapping and revision history. git-annex indexes the data in storage by a hash. There is the storage layer, which stores the literal data bytes that you are interested in. Then I’ll illustrate how it works with some scenarios.įundamentally, git-annex takes layers that are all combined in Dropbox and separates them out. Let’s take a look at the high-level architecture of the tool. Depending on your usage pattern, this central provider could require only a few MBs of space even for repositories containing gigabytes or terabytes of data that is kept in sync. Git-annex lets you set up a live syncing solution that requires no central provider at all, or can be used with a completely untrusted central provider. But I like to understand how my tools work. Ir you just want to use it, you don’t need to know all this. I found I had to sort of piece together the architecture between those levels, so I’m writing this all down hoping it will benefit others that are curious. The git-annex wiki has a lot of great information - both low-level reference and a high-level 10-minute screencast showing how easy it is to set up. It’s sort of like a different-colored smell. It takes a bit to wrap your head around, because git-annex is just a little different from everything else. This post isn’t about it’s traditional roots in git or all the features it has for partial copies of large data sets, but rather for its live syncing capabilities like Dropbox. Git-annex has been around for a long time, but I just recently stumbled across some of the work Joey has been doing to it.
0 kommentar(er)
