
Dropbox is not a tool for developers - toomuchblah
http://stupidiswinning.tumblr.com/post/42361509571/dropbox-is-not-a-tool-for-developers
======
tristan_juricek
Using syncing as a developer makes sense to me because syncing or backup is
not versioning.

Versioning (using git) is about marking state at a period of time. Such that,
in the future, you can go back to that important state, and that state means
something.

Backup, syncing, they just solve different problems. They might have backups,
but those backups rarely mean something. Other than, "well I thought it worked
tuesday".

I see this is as "different by design". I want Dropbox to make the same shit
show up everywhere. I want git to manage versions and streams of work, often
coordinating with other people. Using the dropbox workflow with other people
sucks if people make changes (I have to often ask, "hey wait, what did you
do".) Using the git workflow to sync with other devices sucks because I have
to remember to tell it what to do.

------
dradtke
Why is this even a debate? Dropbox is for syncing files, not version control.

~~~
jlgreco
Unfortunately it works _juuuust_ well enough as a substitute for version
control to suck some lazier or less experienced devs in.

I talked with a group that was using Dropbox as their "VCS" before and asked
how they handled conflicts. They told me they just made sure everybody was in
the same room before anybody did anything.

------
dfc
I am surprised to see so many people mentioning dropbox and git. What does
dropbox add that you don't get from git?[1] And/or with git and a decent
backup system(tarsnap/duplicity/rsync)? It seems like a lot of extra overhead
and data privacy concerns for little gain. What am I missing?

[1] I'm not saying this because git is the magic fairy dust. Replace git with
hg, darcs etc.

~~~
jlgreco
Presumably the difference is that you don't have to pull/push. Can't say doing
that ever bothered me though.

Edit: actually it looks like most people use a bare repo on dropbox so you
still push/pull from it. I don't understand the use-case at all then.

~~~
beagle3
If you have a bare repo in dropbox, you are essentially using dropbox servers
as your git server; except it might silently drop stuff in all replicas on a
merge conflict. Or whenever it fancies (dropbox had at least one all-replica
data loss bug before). But in return, you don't have to do a 'git push' or
'git pull' or 'git-legit sync'.

Personally, I think it's stupid. If it's a non-secret project, host it on
github and do a '[le]git sync' every few minutes (from a cronjob, if you
insist).

If you don't want to expose it on github, why on earth do you trust dropbox to
keep it?

~~~
jlgreco
Hell, doesn't bitbucket support git now? Just use them if your project is
uber-secret.

~~~
beagle3
You're doing it wrong. If your project is uber-secret, you have to host it
yourself - not under a big sign that says "come and try to get super secret
source code out of me" just above the small "bitbucket" or "paid github" sign.

~~~
jlgreco
bitbucket has free private repos. If dropbox is private enough for you,
bitbucket should be as well.

Obviously I just keep my private repos on my own server. Who doesn't have
their own server these days anyway?

------
Sunlis
I'm not sure what the problem with Dropbox is. Almost anything I'm working on
is inside my Dropbox directory. Yes, every time I save or generate some files
they're uploaded to Dropbox, but if you turn off notifications[0] the only
potential problem is bandwidth. And let's face it, most small projects aren't
exactly going to hog GBs of bandwidth very easily.

For me, Dropbox is a simple way to automatically backup the stuff I'm working
on, and I don't have to think twice about it.

[0] <https://www.dropbox.com/help/34/en>

------
pfortuny
As a writer more than a developer (LaTeX stuff for my papers and students), I
have found this constant syncing more of a hassle than I expected (I have
turned Dropbox down and sync by myself, use git etc...).

It is a pity because I very seldom need git for the things I write (they tend
to be quite lienar and versions are not that important, what I really need is
syncing, not version control)...

I also want the .tex sources tracked but not the pdfs and certainly not the
logs, aux, bbl, and "synctex" files and directories.

------
ender89
You're an absolute bloody idiot iff (programming joke!) you use dropbox for
syncing your project files. Its not smart to use it as a repository because a
change by one becomes a change for all. And of course its going to be taxing
on the cpu, everytime you compile and test every file gets updated/recreated
and dropbox has to work to upload the changes to the server. Why don't you try
using a real versioning/repo tool like Bazaar or git or svn instead of the
lunacy of trying to make dropbox get the job done. And you should have to
manually do a commit at the end of the day because you need to document your
changes if anyone is going to have any hope of picking up where you left off;
therefore the argument that you would have to remember to restart dropbox is
invalid. Why don't you stop being lazy and actually do your job?

------
glanotte
I am not sure I understand. I use dropbox with git, but I use the dropbox
folder as my origin repository. I initialize a bare repository in my dropbox
folder and then push to it from my local working repository. The only time
dropbox updates is when I push. I also don't want all of my temporary files
replicated anyway and git provides me the ability to control what is and is
not in the repository. I hadn't thought to use dropbox as my working
directory, but I can imagine that it would be a painful experience.

This is usually only a temporary measure for throw away projects that have
potential. When something gets to the point that I am going to deploy it, then
I will change the origin to github and push there.

------
duck
It is a tool, but you just have to use it the right way:
[http://stackoverflow.com/questions/1960799/using-
gitdropbox-...](http://stackoverflow.com/questions/1960799/using-gitdropbox-
together-effectively)

~~~
tunesmith
I agree but it's easy to forget the premises on which it makes sense.

I like the idea of storing my git bare repository on my dropbox, while pulling
from it to another non-dropbox directory. For a private repository, it's a
nice alternative to using bitbucket. But, I think it is only reasonable if I'm
the only one syncing with the repository. As soon as I want to collaborate on
my shared private git repo, time to use bitbucket.

With Logic Pro, I will record directly into Dropbox, but only if I turn off
sync while recording. Then I can share the project with my mixer/editor in
another state. But there again we make sure not to be in the project at the
same time.

In short, my sense is that Dropbox is for sync and backup. It's not for
simultaneous co-working.

------
msoad
Forget about code and Git, Dropbox is not even good for photo sharing.

I went to vacation with a group of people. Everyone had his/her own camera. We
decided to make a folder in Dropbox and share it with everyone so we can share
our photos and get other people photos.

After a week my photos started to disappear. Why? Because my lady friend
didn't like the photo I took from her and deleted it from "her own computer".
But it was actually in a shared folder.

I don't know if this "shared folder" concept thing is too complicated or
Dropbox can not handle it. Anyway in my experience it did not work.

~~~
davis_m
I don't understand what the problem is?

It is a shared folder. If someone deletes something, it is deleted everywhere.
That isn't a bug, that is the purpose of Dropbox.

------
bpolania
I don´t think that Dropbox is intended to work as a substitute to Git, I know
I´d never use it like that. Nevertheless, I developed my own version of Github
using Box (<http://bit.ly/yZvl2a>) just for the fun of it, because I think
that Github sometimes gets a little complex for simple projects.

The idea is to drag-and-drop instead of using the console and the app to be
smart enough to recognize that you´re doing and update, and instead of forks
it just creates another folder for the same project. It also reduce the hassle
of the SSL keys.

So far, so good. Even though I don´t know if under Box terms it´d be feasible
as a business, I haven´t checked out the Dropbox API but I guess it´d be easy
to implement, and I´m also cheking the Mega API (Kim Dotcom new cloud
storage)s since it seems to be a little less restrictive about what you can or
can´t do with the API.

------
delinka
Why are you putting build directories in a folder that's autosync'd? My
Dropbox directory absolutely has a git directory in it. And each project gets
its very own 'remote' repo in Dropbox's git folder (mkdir new_proj.git; cd
new_proj.git; git init --bare). I do work from $THIS_COMPUTER behind the
corporate firewall, I push to Dropbox (git push dropbox master); I sit down to
$THAT_COMPUTER at home and pull from Dropbox; build products, indexes, and all
that jazz that happens frequently stays _away_ from Dropbox.

So Dropbox becomes my 'server' with omnipresence on the 'net so that I don't
need a VPS and don't have to expose a server at home to the world. Dropbox
deleted a file? I've got the repo in other places.

Putting your _working_ project directories _inside_ Dropbox, editing and
compiling in the same place? DOIN IT RONG

------
orrorin6
This is stupid. Sure, Dropbox isn't an ideal service for developers, but it's
one that users understand.

------
sourc3
For one developer projects (aka side projects) Dropbox is great. I now can
switch across many machines I have and don't have to lug around a specific
laptop and when I boot up, the latest version of the project is there for me
to spend an hour or two on and forget about for another week.

Having said that, DB is not a version control tool. Being how intelligent the
HN community is I don't quite understand the point of the post: use the tool
for what it's meant to be and save yourself the headache (and a blog post).

BitBucket is perfect for private repositories if you have more than 1
developer and want _version_ control and it's free.

------
NateDad
What the hell? Don't put your sourcecode in your dropbox folder. That's the
"fix". Not turning off dropbox.

Git is free. github/bitbucket/whatever else is free. Dropbox is for random
documents, music, and pictures, not your code.

------
janus
The tool you are looking for is git.

------
rarrrrrr
FYI, SpiderOak is intended more for power users. You can tell it to ignore
files and folder by wildcards (and it does meaningful encryption.)

------
jmscharff2
I have my local git files saved in my dropbox folder and use git for version
control and dropbox to make sure that everything is backed up and on multiple
computers at the same time. Doesn't solve the bandwidth problem but unless
they are massive changes I think the bandwidth/cpu/memory usage should be very
minimal no?

I think the combination of git and dropbox works great.

------
georgemcbay
Lots of posts in here talking about how Dropbox isn't for version control and
"just use git" and such, but the systems aren't mutually exclusive and so
these comments aren't helpful, IMO. Just because Dropbox isn't a proper
version control system doesn't mean it isn't (or couldn't be) useful for
developers.

I use git daily but I also use a syncing program (first Live Mesh, then
Dropbox, now Google Drive) to sync my source code directories. This isn't at
all for version control but rather so I can change systems nearly instantly
without having to check everything in to a remote git server. This allows me
to not care if I'm working on one of my two laptops or my desktop, all my code
is Just There whenever I need to switch. With a pure git solution I'd have to
push changes that may or may not be a fully coherent change set each time I
switched machines.

Anyway, my point is that all of the OP's arguments are still valid when you
are using git+dropbox, which is a perfectly reasonable thing to expect to do.

FWIW, all of the major sync systems have issues here (my biggest pet peeve
with Live Mesh was that it would hold locks on files for an abnormally long
time which would stop me from being able to compile while .o files were being
synced, for example). But Dropbox's probably are the most annoying since you
have so little control over what does and doesn't sync beyond the root sync
directory.

~~~
lojack
That may work for the lone developer, but what happens when you're on a team
with shared Dropbox folders, all working on the same code base concurrently. I
understand your reasoning, and I'm not trying to say you are incorrect in
doing this as it's a very legitimate use case. It is, however, important to
understand that using Dropbox in this way, in the context of syncing the git
repo for teams, is a step backwards.

~~~
georgemcbay
It makes no difference if I'm working alone or on a team. Syncing locally
changes nothing about my source code control usage. I'm still pushing my
changes into a shared repo (on a remote server) when it is time to do that,
but since I'm syncing locally (including my .git directory usually) I can push
from any one of three different machines, whichever I happen to be working on
when it is time to do the push.

~~~
lojack
I understand this, which is why I specifically said it wasn't wrong. Just
saying that serious issues could arise when a less experienced developer
shares their Dropbox folder and others treat that folder as their own clone of
the repository. This should never happen because we know better, but the
realist in me says its inevitably going to happen at some point.

~~~
georgemcbay
Yeah that's a potential problem if people are doing that. I certainly don't
recommend sharing a repo directory among multiple people via Dropbox.

I don't share my sync folders publicly at all, they exist only for my own
convenience when it comes to switching between different systems as needed.

------
styts
As a developer I only keep my source files symlinked to Dropbox, thus avoiding
the problem of uploading binaries. Dropbox serves as a means to recover lost
changes, should something happen between commits. There can be no excuse not
to use backups and version control.

------
up_and_up
This article has very little content for or against their own idea.

What type of developers using DropBox for what?

The only thing I use DB for is for storing/sharing Keepass files and for
shared books/resources.

Using it for source code seems wacky to me like a half step above FTP.

------
mythealias
it is not just problem for developers. users like me who edit simple text file
in vim or write a document in latex usually get a notification of syncing the
temporary files. yes i can turn of the notifications, but that is like saying
don't look at the issue and it is not there.

the problem is not just that dropbox has not addressed the issue, it is also
that they have turned a blind eye to it. there is not indication whether they
plan to work on it or not. what's the use of votebox if they do not plan to
use it.

btw those are not 22k people, rather 22k votes. there are many people like me
who have voted 10-100 times.

------
javajosh
A timely post. Dropbox loves to delete things, especially if you mess with
'selective sync'. For example, it deleted the git repository of my project a
few weeks in. It deleted _all_ of the files I had symlinked to in a
subdirectory of my project. I was able to recover these files, but Dropbox is
_damn scary_ , since I don't know that actual circumstances in which these
deletions occur. I _suspect_ it has something to do with symlinks and
selective sync, but I'm not entirely sure.

One thing that I might try is to have a very "Dropbox aware" process whereby
you intentionally create _empty_ delicate structures and then exclude them
from sync. For example, do a `mkdir .git` before `git init`, exclude .git from
DB, then do a quick `rmdir .git; git init` and pray to the God of data
integrity. But I don't know if that will work.

~~~
res0nat0r
Remember remember remember: Dropbox isn't a backup service! Make sure you keep
proper backups for your important data.

~~~
javajosh
Dropbox disagrees with you: <https://www.dropbox.com/tour/4>

Note that I've been using DB successfully as an up-to-the-minute backup since
it came out - it's only in the last week I've had problems bad enough to go
back to my weekly backups.

~~~
res0nat0r
Four out of five doctors agree that X is great also. Does it matter what their
marketing speak says?

Auto replication to the cloud isn't a proper backup plan, unless you are
counting on noticing any missing data within their 30 day backup retention
policy (if you are only using their free tier) and restoring your missing data
before it is automatically purged.

------
jcromartie
I use Dropbox for collaborating on anything BUT source code. Don't put repos
in Dropbox. Who the heck ever thought that was a good idea?

~~~
delinka
I'd like to know why this is a problem. I always have a dropbox remote on my
projects. Doesn't matter if it thinks a file suddenly doesn't exist because
it's not the only place a my repos exist.

Certainly don't use Dropbox as a working directing. Not Smart®

------
bitsoda
Dropbox is really handy for backing up your game saves when they don't support
Steam Cloud, or if you don't use Steam at all.

------
randomenduser
Doesn't this solve the problem? <http://sparkleshare.org/>

------
gte910h
git doesn't do large binaries well yet.

That opens up the field for that purpose, for developers.

------
endlessvoid94
I'm pretty sure they use Mercurial themselves.

------
seivan
Wow, this is just so bad. You're right, stupid is winning. I learned not to
use Dropbox with Git for numerous reason I won't get into here. This was 3
years ago.

------
Shorel
I'm partial to Ubuntu One.

------
smiddereens
Uh huh...

------
speeder
I never thought that put symbolic links on dropbox was good idea...

But I see where it might come from.

When my startup started, my associate nagged me to death to me put my files on
Google Drive, like the artist already did.

I ended doing it, just to show him that it would not end well...

In fact, the result was worse than expected, Mac OS X store folder icons
inside the folder, the SDK I was using use ALL files in a folder to build a
application (does not matter what those files do), the end result was the
Google Drive created icons getting shipped with the apps, that just flat out
crashed the testing devices... It took 1 week to figure out why all the
crashing, and also to make Google Drive not conflict with some other stuff,
hardlinking was required, and took more 3 days to undo the hardlinks.

Thus, lesson: DON'T, JUST DON'T.

But sometimes a person might nag you to do it, then by all means do it, it
will fall on their head and they will learn (of course, if it is a intelligent
person, if you have a dumb boss, then I fell sorry for you).

