Re: A system administration use case for git
- From
Jon Seymour <jon.seymour@gmail.com>
- Date
- Apr 22, 2009, 10:18 UTC
- Message-ID
- <2cfc40320904220318ra5e8fcbh863f9a4bf9c82443@mail.gmail.com>
- In-Reply-To
- <46a038f90904220307h2ac16881qe29c77c5a0334160@mail.gmail.com>
Martin,
Thanks for the info about hard-linked trees...they may well do exactly what I need - thank you!
jon.
On Wed, Apr 22, 2009 at 8:07 PM, Martin Langhoff <martin.langhoff@gmail.com> wrote:
Show 36 quoted lines
> On Wed, Apr 22, 2009 at 11:22 AM, Jon Seymour <jon.seymour@gmail.com> wrote: >> One disadvantage of that approach is if the file system is very large >> and only has a few deltas, then I effectively have to have two copies >> of the reference file system - one in the GIT repo and one that I can > > You could minimise the on-disk footprint -- and protect it from > concurrent access (concurrent change) by using a hardlinked tree on > the destination side. rsync knows to break hardlinks, etc. > > Currently, you can't "rsync into git" which would save you that step. > It's a ton of work to do that -- if anyone is planning on working on > something like that, perhaps writing directly into the fast-import > protocol is a good shortcut. > > I'd like to have something like that for my OLPC School Server, which > could benefit from using git as the backup backend -- it currently > uses hardlinked directories. > >> In an ideal world, storage requirements at the other place would be >> those of the reference file system + those of the various deltas, but >> no more. > > rsync + hardlinked trees + git gets you quite close to that. > > cheers, > > > > m > -- > martin.langhoff@gmail.com > martin@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff >