Nick Daly <[email protected]> writes: > Can anyone look into making a script that reacts to the inotify events > and another script that correctly configures a folder to be that sort > of repository? The second script is probably easier, it just needs to > call out to the inotify extension and the other script.
lsyncd might be of interest. Like SparkleShare, it's already packaged in Debian (see http://packages.debian.org/squeeze/lsyncd ). It is a simple inotify-based daemon that watches some directories and sends changes to a server using rsync. It may not be the exact thing that FBXers want, since its role is one-way sync to a backup server (more like Apple's Time Machine, which is basically a fancy rsync hack, than like DropBox, I suppose). But it might be an interesting source of inspiration for people who want to look at inotify. I don't find the idea of making a DVCS pretend to be a DropBox clone all that appealing, however; I think both types of tools suffer from trying to draw that analogy. DropBox, SpiderOak, etc. are much more like old-fashioned lockstep VCSes like CVS--"distributed" only in the sense that systems sharing a synced folder have their own local copy, not in the sense that they are designed to allow users to fork their own version of some files and merge them back later. Such tools do typically keep a revision history, but it's basically linear as far as I understand it, not DVCS-like. People who use that kind of thing by and large don't want the complexity of a DVCS or want to deal with the idea that there could be two equally authoritative versions of a file on two systems sharing a folder. DVCSes, on the other hand, shouldn't go around committing things and merging them into the parent branch automatically without user intervention. So much of the usefulness of a DVCS arises from the fact that commits represent meaningful, understandable units of change to the user(s)--the fact that [hopefully] some thought went into the commit messages, the fact that you can see how conflicts are resolved at a merge, etc. Automatic commits and merges/pushes/whatever triggered by inotify seems like an ugly kludge that will make revision history hard to review and understand. There are some good tools like etckeeper that commit certain file sets automatically on some criteria, but these are usually working on a limited pile of data that doesn't change too often, like (in etckeeper's case) committing config files after a package operation. A DVCS's job is not to sit beside me while I'm editing and live-transcribe everything I say. Synchronization tools are synchronization tools, and VCSes are VCSes. Obviously, one can force a DVCS to act as a store of revision history for a synchronization tool, but in so doing, you're basically making it act like a poorly maintained CVS repo where nobody writes sane commit messages. If you want synchronization with _incremental backup_, it's probably better to use an incremental backup tool like rdiff-backup or duplicity or amanda or something to save the increments. Best, WGG -- I use grml (http://grml.org/) _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
