{"thread":{"id":"17280","subject":"read-only working copy using symlinks to blobs","startedAt":"2009-01-21T08:15:11Z","lastAt":"2009-01-21T08:15:11Z","messageCount":1,"participants":["chadrik"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"101351","messageId":"21578696.post@talk.nabble.com","threadId":"17280","inReplyTo":null,"subject":"read-only working copy using symlinks to blobs","fromName":"chadrik","fromEmail":"chadrik@gmail.com","sentAt":"2009-01-21T08:15:11Z","receivedAt":"2009-01-21T08:15:11Z","isPatch":false,"sender":{"key":"chadrik@gmail.com","avatar":null},"body":"\nhi all,\ni'm looking into using git to manage a lot of very large binary data.  git\nseems particularly suited to this task because it has features for saving\ndisk space such as clone--shared, and it's fast due to simple compression by\ndefault (instead of deltas).\n\nin my mind, there's still one major feature for working with large binaries\nthat has not been addressed:  the ability to check out symbolic/hard links\nto blobs into the working copy instead of creating duplicates of the files.\n\nimagine a scenario where one user is putting large binary files into a git\nrepo.  100 other users need read-only access to this repo.  they clone the\nrepo shared, which saves disk space for the object files, but each of these\n100 working copies also creates copies of all the binary files at the HEAD\nrevision. it would be 100x as efficient if, in place of these files,\nsymbolic or hard links were made to the blob files in .git/objects.  \n\nthe crux of the issue is that the blob objects would have to be stored as\nexact copies of the original files.  i did some googling and it would seem\nthere are two things that currently prevent this from happening.  1) blobs\nare stored with compression and 2) they include a small header.  compression\ncan be disabled by setting core.loosecompression to 0, so that seems like\nless of an issue.  as for the header, wouldn't it be possible to store it as\na separate file per blob object and thus keep the original data completely\npristine? \n\nwhat are the caveats to a system like this?  any thoughts on the\nfeasibility?\n\n-chad\n\n\n-- \nView this message in context: http://www.nabble.com/read-only-working-copy-using-symlinks-to-blobs-tp21578696p21578696.html\nSent from the git mailing list archive at Nabble.com.\n"}]}