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

[Freedombox-discuss] Hackfest Fodder: FBX as a DropBox Replacement

Nick Daly <nick.m.daly at gmail.com> 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.

I use grml (http://grml.org/)

Reply to: