Re: backups with git and inotify

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 10, 2007 at 10:57:46PM +0100, Björn Steinbrink wrote:
> On 2007.12.10 20:29:11 +0000, Luciano Rocha wrote:
<snip>
> > So, please, suggest.
> 
> I posted an extremely simple bash script here:
> http://lkml.org/lkml/2007/12/7/279

That thread was what motivated me to write the program, but I must've
missed your post.

> 
> It just employs inotifywait to do all watching and just needs to
> translate the events to the different git command. Did just glance over
> your code, but it seems to do basically the same thing, just that it's a
> lot shorter. The overhead of being a shell script is probably neglible,
> as the amount of git calls are likely dominating anyway.

Yes, being a shell script isn't a problem. I wasn't aware of
inotify-tools, so I wrote my own. Still, the inotify-tools programs miss
a check for ignoring directories with predetermined contents (I want to
ignore sub-directories with their own git repository).

I think I'll contribute to inotify-tools a switch for that, and switch
to perl. That will simplify the development and allow for coalescing
events, so that updates with temporary files would be a simple update.

> Feel free to ignore my comments on why I think that that is crap anyway
> and do whatever you want with the script.

FWIW, I also think that trying to keep a coherent stat with automatic
commits isn't possible. As for the temporary, unneeded files, a
exclusion pattern will suffice, and using .git directly, instead of a
(FUSE) filesystem, will allow permanent storage of those temporary
files, until explicitly removed.

Thanks,
Luciano Rocha

-- 
Luciano Rocha <luciano@xxxxxxxxxxx>
Eurotux Informática, S.A. <http://www.eurotux.com/>

Attachment: pgpQ0emZ07Qz5.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux