This is (yet another) "Dropbox replacement" project publicized in HN that grossly misunderstands what Dropbox is, why it's popular and is not a "replacement" in any meaningful way.
Here are just a few characteristics of Dropbox that this project doesn't have:
* cross-platform (windows, mac, linux)
* an easy to setup GUI client that is possible to setup by people who don't necessarily know how to enable inotify in linux kernel or copy autosync.py to location in $PATH
* won't fall over when a merge conflict happens (and a merge conflict will happen and even I, who uses git daily, would be unable to resolve it)
We are good at extrapolating and making connections but in this case extrapolating from "files, sync" to "my linux-only python script is a replacement of Dropbox" is about as valid as extrapolating from "wheels" to "my home made unicycle is a replacement of Toyota Prius".
At least he's making something. We should foster an atmosphere of encouragement, even if the idea seems silly. Who knows what it could grow into one day?
You might not have intended to be so mean-spirited. I know I've sounded that way in the past. What helped me was to offer some kind of suggestions for improvement along with whatever criticisms I was dishing out. (Rather than just pointing out all of the flaws.)
These clones demonstrate why Dropbox is such a good idea imo. Good ideas are ones that make people think "that's easy, I could do that in a weekend!" Dropbox is great because it isn't just a really good idea, it's also a fantastic implementation.
The title alone says much about the simplicity of the product. "Dropbox" is more friendly and much easier to remember than the name of "DVCS-Autosync".
I looked through the source, and it doesn't seem to have any conflict resolution. As far as I can tell, it simply executes the push and pull commands without checking their exit codes to see if they succeeded.
What makes dropbox special is that I can access it on my home iMac, my work macbook, my linux netbook, my android phone, my iPad and the web interface when I feel so inclined. On top of that, I select different directories to sync on each machine and often share file between friends and colleagues.
An uber simple interface that supported on every major platform is what makes it so awesome.
You are right. It might increase very slowly if you actually store a source repository composed of many small files and then only some of them change periodically. But if you store large binary blobs and all of them change often then git won't work that well.
You'd at least want to have the option to blow away some history as you run out of space or become confident that you'll never need it -- can't do that in git without re-writting the whole commit history from scratch and filtering out some commits.
In think in this case there is some confusion between backup and synchronization, both can be thought of as separate and git might not do well for either one in the general case. It might not be as good for backup, because you might want to blow away old snapshots and in case of synchronization. As for general bidirectional synchronization, you'd need some way to plugin in custom merge conflict resolution (can git do that?). For example you might have a policy that whenever you modify a file on the your laptop it should take precendence over the same file modified on your iphone, or some text files can handle merging while others should be replaced based on timestamp, or something like that.
It's funny - I was reading up on Camlistore yesterday, and realize that what it proposes to do very much resembles Dropbox (and - to a certain degree, Git).
Have you considered making a personal Dropbox replacement using it? I hear Brad Fitzpatrick is writing it as his Dropbox replacement.
(Also: competition is bi-directional - it's interesting to take a look at Camlistore's suggested usecases http://camlistore.org/docs/uses and think that Dropbox can do the same ...)
I would have thought the personal replacement for Dropbox is just rsync. I guess it depends if you want / need full history. But personally I never use the history features of Dropbox.
Using a git backend for this kind of service is great since it would provide a common synchronization engine for all your files. Thus if I have 3 or 4 of these services pointing at the same folder everything should work.
What I love about this is that the project uses XMPP for server-to-server communication! Someone had poo-poo'd that idea in a previous post, but I think it has tremendous merit.
git doesn't really expose a great UI for this model of behavior. This needs a good UI for many things, for example, looking through history and cherry-picking old versions of files to revert to.
Also, it doesn't give you access from public computers the way dropbox does. You'd want a non-bare repository with gitweb or an apache directory listing, at the least.
[+] [-] kjksf|15 years ago|reply
Here are just a few characteristics of Dropbox that this project doesn't have:
* cross-platform (windows, mac, linux)
* an easy to setup GUI client that is possible to setup by people who don't necessarily know how to enable inotify in linux kernel or copy autosync.py to location in $PATH
* won't fall over when a merge conflict happens (and a merge conflict will happen and even I, who uses git daily, would be unable to resolve it)
We are good at extrapolating and making connections but in this case extrapolating from "files, sync" to "my linux-only python script is a replacement of Dropbox" is about as valid as extrapolating from "wheels" to "my home made unicycle is a replacement of Toyota Prius".
[+] [-] palish|15 years ago|reply
You might not have intended to be so mean-spirited. I know I've sounded that way in the past. What helped me was to offer some kind of suggestions for improvement along with whatever criticisms I was dishing out. (Rather than just pointing out all of the flaws.)
[+] [-] wzdd|15 years ago|reply
[+] [-] Mafana0|15 years ago|reply
[+] [-] rcthompson|15 years ago|reply
[+] [-] bokchoi|15 years ago|reply
[0] http://kitenet.net/~joey/blog/entry/new_git-annex_use_cases/
[1] https://github.com/chmduquesne/sharebox
[+] [-] joeyh|15 years ago|reply
[+] [-] bstar|15 years ago|reply
An uber simple interface that supported on every major platform is what makes it so awesome.
[+] [-] pronoiac|15 years ago|reply
Dealing with gigabytes of files & revisions isn't git's forte.
[+] [-] rdtsc|15 years ago|reply
You'd at least want to have the option to blow away some history as you run out of space or become confident that you'll never need it -- can't do that in git without re-writting the whole commit history from scratch and filtering out some commits.
In think in this case there is some confusion between backup and synchronization, both can be thought of as separate and git might not do well for either one in the general case. It might not be as good for backup, because you might want to blow away old snapshots and in case of synchronization. As for general bidirectional synchronization, you'd need some way to plugin in custom merge conflict resolution (can git do that?). For example you might have a policy that whenever you modify a file on the your laptop it should take precendence over the same file modified on your iphone, or some text files can handle merging while others should be replaced based on timestamp, or something like that.
[+] [-] shadowsun7|15 years ago|reply
Have you considered making a personal Dropbox replacement using it? I hear Brad Fitzpatrick is writing it as his Dropbox replacement.
(Also: competition is bi-directional - it's interesting to take a look at Camlistore's suggested usecases http://camlistore.org/docs/uses and think that Dropbox can do the same ...)
[+] [-] aeontech|15 years ago|reply
[+] [-] sudonim|15 years ago|reply
[+] [-] mikesena|15 years ago|reply
[+] [-] darklajid|15 years ago|reply
1: http://www.sparkleshare.org/
[+] [-] akent|15 years ago|reply
[+] [-] mceachen|15 years ago|reply
[+] [-] hyperbovine|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] akent|15 years ago|reply
[+] [-] pronoiac|15 years ago|reply
[+] [-] pat2man|15 years ago|reply
[+] [-] rexreed|15 years ago|reply
[+] [-] mkramlich|15 years ago|reply
[+] [-] leif|15 years ago|reply
Also, it doesn't give you access from public computers the way dropbox does. You'd want a non-bare repository with gitweb or an apache directory listing, at the least.
[+] [-] pyre|15 years ago|reply