Git-annex assistant: Like DropBox, but with your own cloud

Thanks guys - I think I will blog about it - that'd be cool.

I'm coding more than ever - hence why I want to move back.

My family just visited the 'cabin' last month while vacationing in NC. Since then my wife and are are dead set on returning to the mountain.

For me - this life is crazy busy. Constant 'suits' wanting new things built and never fast enough - and never able to understand the amount of work it takes to make 'that magic button'. Seems apetites are insatiable. That's fine as its job security - work is work afterall.

However, it seems that living in a tranquil environment helps run this marathon.

link for people using real computers. :) http://en.wikipedia.org/wiki/Absorption_refrigerator

50M!? 5 would be more likely, assuming stripping. As opposed to 5k with dyn libs.

I would say never under-estimate the amount of time polish takes - that last 10% of tweaking tiny details always takes a long time (or as the oft-repeated saying goes, the first 90% of work takes the first 90% of time, the last 10% of work takes the other 90% of time).

Good to hear progress is promising though :)

If you're using git for revision control, it lets you "version" files without having all the historical versions locally.

Example: You check in bigencryptedfile.big, which is 100Mb. Then you modify it, and check it in again. Repeat 8 more times.

In git with and without git-annex, you can check out the repository at any time and end up with the local files from that checkout.

In normal git, your local repository is now a gigabyte (the encryption in this hypothetical file prevents git from being able to delta-compress; in reality git would likely be able to compress it somewhat, but it still may be hundreds of megabytes).

With git-annex, all the previous copies are stored on the SERVER, but not in git itself. Even if you don't care about local hard drive space since hard drives are cheap, consider that if I then clone your repository, I would only need to download 100Mb instead of 1Gb. The downside, of course, is that you need to be connected to the server to get historical versions of a particular file.

When you're dealing with, say, a game project with 20Gb of binary data that's been versioned 20x on average, you end up with 400Gb to clone your art repository, which is a non-trivial download size. And if, for some reason, you want your repository cloned to multiple folders on your drive, then again you're using 10Gb each instead of 400Gb each. Even on cheap hard drives, multiple folders of 400Gb each adds up quickly.

EDIT: OH, and one other advantage of doing it this way: If you just use rsync, and you accidentally overwrite a file and don't notice for a day or two, rsync will happily destroy your backup file as well, while git-annex will just store a new revision. Should have thought of that first. ;)

git-annex keeps track of what file is where, including any duplicate copies you wish to keep on other storage mediums. If I want some file I archived, git-annex will tell me which external disk it's on (and it can do S3 and some other online storage mediums too). rsync keeps track of nothing between runs.

I find it really useful for archiving large files - an entirely different use case than git.

Some of the commercial version-control systems handle big binaries reasonably well. That's one reason many game companies, for example, use Perforce, since it doesn't choke on piles of art assets.