
A personal Dropbox replacement based on Git - gglanzani
http://www.mayrhofer.eu.org/dvcs-autosync
======
kjksf
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".

~~~
palish
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.)

~~~
damncabbage
My suggestion for improvement would be:

"Don't advertise your project as a 'Dropbox Replacement' unless you actually
are."

~~~
hardik988
I think he advertised it as a 'Personal Dropbox Replacement' which suggests he
probably just made it for himself and is releasing it to everyone if they wish
to use it.

This project is open-source, has no domain name of it's own, no fancy video
explaining how it works, no bullet-points explaining why people should dump
Dropbox and start using his project, and the author doesn't seem intent on
making money from it by advertising it as a 'personal Dropbox Replacement'.
It's quite evident that only programmers are going to use this product,
considering the dependencies and relative complexity of install procedure.

I don't see anything wrong with the way he has advertised his project as a
'Personal Dropbox Replacement'

------
rcthompson
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.

------
bokchoi
Joey Hess just blogged[0] about ShareBox[1] which creates a fuse filesystem
built on git-annex. I don't know either well enough to comment on them.

[0] <http://kitenet.net/~joey/blog/entry/new_git-annex_use_cases/>

[1] <https://github.com/chmduquesne/sharebox>

~~~
joeyh
The dvcs-autosync author is also looking at making it use git-annex for large
files.

------
bstar
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.

------
pronoiac
Won't the space taken up by revisions monotonically increase? Deleting files
won't free up the space, since the old revision is still tracked.

Dealing with gigabytes of files & revisions isn't git's forte.

~~~
rdtsc
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.

~~~
gwern
> But if you store large binary blobs and all of them change often then git
> won't work that well.

True, default git won't work well. But you can handle large changing files
git-style with a different approach; the bup backup system using git comes to
mind (see <https://github.com/apenwarr/bup> &
<http://lwn.net/Articles/380983/>) where what is stored are chunks of files,
where xdelta and other diffs work efficiently.

------
shadowsun7
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 ...)

------
aeontech
What do you think about this is better than AeroFS (<http://www.aerofs.com/>,
previous discussion at <http://news.ycombinator.com/item?id=1538731>)?

~~~
sudonim
One thing that's better is that it's available now. I can't use aerofs. It's a
closed beta.

~~~
aeontech
I can get you an invite if you like. I got my code shortly after asking for
one.

------
darklajid
Seems like a similar approach as SparkleShare [1], albeit less/not focused on
UI (and using XMPP for notifications to update the repository).

1: <http://www.sparkleshare.org/>

------
akent
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.

~~~
mceachen
rsync isn't bidirectional (see unison:
<http://www.cis.upenn.edu/~bcpierce/unison/>), but it can be hacked on to make
it store snapshots (see <http://www.mikerubel.org/computers/rsync_snapshots/>,
but it's a full volume snapshot, not a per-file versioned history).

~~~
320x200
Unison is great, I use it as a way to keep several machines in sync for large
content (several gigs) using a personal server as hub.

<http://gitorious.org/mist>

It's not a dropbox replacement, but it does the syncing job nice and simple
with nothing else but unison, ssh and a shell script. I will eventually make a
daemon using inotify so that it can sync in the background as well.

------
pat2man
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.

------
rexreed
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.

------
mkramlich
or just GitHub with private repos. then you can control exactly how and when
the synchs across various clients occur. less moving parts too.

------
leif
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.

~~~
pyre
There are a couple of FUSE modules that implement a filesystem based on a bare
git repo.

