A system administration use case for git

[Jon Seymour <jon.seymour@gmail.com>]

Martin,

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
damage on a regular basis with rsync for the purposes calculating the
git deltas.   I know I can then use git to repair the damage, but then
the reference has to be protected from concurrent access.

I'd prefer not to have to maintain a copy of the tree that has to be
"damaged" on a regular basis and also if I didn't have to maintain a
copy of the git objects for identical files.

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.

jon seymour

On Wed, Apr 22, 2009 at 6:48 PM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
> On Wed, Apr 22, 2009 at 10:33 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> Hello all, it's been quite a while.
>> It'd be nice to do this on arbitrary (non-git-controlled) file system tree:
>>
>> * calculate the git hashes of the tree (without making copies of the
>> files in the tree)
>> * archive the tree hashes
>> * rsync the tree hashes to another place
>> * work out which files aren't available in the other place's git repo
>> * rsync those files the the other place
>
> Steps:
>
> 1 - rsync to the "other place"
> 2 - use the git repo in that "other place"
> 3 - if the tree hashes are needed "here", copy them from the "other
> place" git to here.
>
> rsync + git = awesomenesssssss
>
>
>
>
> --
>  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
>