Reopening iFolder

Thanks for the precision. It's true this mode of operation isn't the natural use case for Unison, but they claim it can be done (they recommend using a centralised topology though, in this case, so we would loose their nice merge/conflict resolution features).
http://www.cis.upenn.edu/~bcpierce/unison/download/releas...

My first impression (haven't tried iFolder actually) would be that the strength of both tool may be different but complementary. Correct me if I'm wrong:
* Unison for multiway sync (sync your laptop and desktop in both direction, without the need for a server). Ie. typical home user.
* iFolder would be better designed for star topology (multiple desktops with a central server) replication, with strong centralized authentication management. Ie. typical needs for office user.

Is this it?

> It explicitly tells you to avoid the use of csync for laptops and
> desktops. I believe that's because it has very poor offline mode support
> -- it expects the machines to be connected at all times.

It's more because it doesn't offer users a change to handle conflicts resolution. Ie. you configure it so if in doubt (simultaneous changes on the same file get synchronised), one server is always right and the changes from the other would be lost (and similar algos), while Unison would ask the user. This indeed is not the best option for everyone, and is more targeted for servers (where you may prefer things handled automatically).

> Yes, actually, it does if you want it to be automatic.
[...]
> That requires some kind of daemon running using something like inotify
> so that it can automatically detect the changes and sync for me

Good opportunity to plug "incron", a nice cron-like system that triggers commands on file changes events (rather than time events) ;). But you're right, the other way around (pulling changes from a distant system) would be best handled by a dedicated protocol (rather than regularly launching the sync tool). And you're right about the fact that without a small kernel support (like inotify api), those tools do have to fallback on the ressource intensive "scan in loop" way of things. I would still distinguish such a "small kernel help when available" from the kernel requirements examples mentioned in the article (Coda,...).

> They're optimized for syncing text files (source code mostly) and put a lot of effort into diff calculation and the like which is largely useless for binary files

Hmm, I for one do mostly use text files in my home (except for browser cache and the like, which I wouln't like to synchronize), so that's a valid use case, and that's why I tried git-home-history (and still use etckeeper). I have to agree, it's probably not a mainstream use case, and most people would use an office suite producing binaries rather than vim and text files :).

Which lead to the observation that git and the like needs to progress in this space before they can be useful for non geeks users daily files operations (ie. a pluggable architecture to diff properly opendocument zipped files and similars). See how many people starts to think about misusing or improving git so it can be a good backup solution? and remember Lary McVoy (of BitKeeper fame) saying that, outside the opensource community, there was a huge demand for good binary files handling in SCM?
Your "one tool does not fit all needs" is wise but frustrating.

Anyway, for things like /etc directory and other folders using mostly text files, aided-SCM (like etckeeper) may do an useful job, and that's why I was surprised to see them factored out of the discussion in the article (as opposed to NFS or Coda). Which was by no way claiming they are better than iFolder for all use cases ;)