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.
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.
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.
I don't get it either. I've seen entire blog posts dedicated to using Dropbox as a git remote [1]. This is insanity! Git expects very fine grained control over the files in a git repository. I've also seen Dropbox generate "conflicted copies" for files that I don't have open and haven't modified. Literally I've sat and watched Dropbox notices come in about conflicted copies on files that are years old. I opened the folder containing the files and stared as the folder filled up with conflicted copies (which I promptly deleted).
There's no way I'd trust Dropbox to touch my git repos.
I use version control AND dropbox. Version control for... controlling versions, and Dropbox for sync and immediate recovery of all my work files should something bad happen.
Which did happen about two weeks ago. My laptop let the magic smoke out, and my deja dup backup wouldn't restore.
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?
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.
Not having to pull/push is also nice. If you just start editing a file and want to keep working on your laptop at the cafe without having to commit anything.
Indeed there are. People are using Dropbox as one of them.
But saying "why use Git with Dropbox it makes no sense?!" is actually wrong. It makes perfect sense. Git is not centralised. You cannot access your repository from a remote host.
Dropbox as well as Github and a number of alternative service allow that.
I asked a question about the merits of using dropbox and git and I specifically asked what I was moissing. How can a question "be wrong"? You have yet to answer what Dropbox+git offers that git+backup system does not.
I cannot access my repository from a remote host? I am guessing that you run windows, I don't. I can ssh into any machine that I need to access.
Yes it was a real question, one that you did not address at all. And what does "Git is local onl)" mean? If it was local only how did git replace bitkeeper?
I don't use github. I have a local server running gitolite that I use all the time. There is a cron script that pushes all of the repos to an offsite machine just in case. And this is in addition to normal backup system with duplicity.
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.
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.
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?
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.
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.
For those who don't click through, the linked SO answer recommends using Dropbox to sync a "remote" repo between your computers, and push/pulling that from your working repo outside of Dropbox.
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.
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.
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
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.
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.
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.
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.
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.
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.
He's not talking about syncing a git repo for multiple developers with it. He's talking about syncing his work with it. Of course it's not a replacement for a centralized git repo.
Does Dropbox do merging? Does it track history? Can you run it on server(s) of your choice? Can you setup Dropbox for centralized or distributed operation? Can you inspect the source for security holes? Can you write third party clients, servers, plugins, etc for it?
For once, the headline is perfect: true in every respect and descriptive of the article.
Did you read the comment above you? As a person who bounces around between computers, the syncing part is much more than a "whatever" and, while git-annex-assistant looks cool, it will be some time before I trust it with my most valued documents. Further, niceties like access to code on my iPad, etc, are continued benefits of services like Dropbox.
My whole post was based on the premise that using Dropbox (or another similar sync program) and git (or another similar version control system) aren't mutually exclusive. Yet you continue to make it an either/or argument.
Yes, they aren't mutually exclusive; but I just don't see the point of Dropbox at all.
Edit: The fact that Dropbox won't merge just seems to me like going backwards, and makes it utterly useless for syncing, IMHO. Since git will merge, and it syncs, why do you need Dropbox?
But the biggest thing annex-assistant adds is the automation of syncing; syncing is already builtin to git.
Edit: sorry for being so tendentious (yes, I like big words :). I'm just really having a hard time "getting" Dropbox as it seems like a poor, closed source replacement for rsync. Git can be used as a glorified rsync that will resolve 90% of multiply edited files, plus it gives you change history, and you're not locked into one company. I understand that git doesn't run on the iPad, but that sounds like a problem with the iPad, not git ;) Git runs fine on not just my Android devices, but my Maemo devices as well.
They are very useful, but for different kinds of data.
I keep my source in git, so I get proper versioning, commits, etc.
I keep all my stuff - data files, notes, documentation, agreements, tool installations, ebooks, tools/code made by others in dropbox, so they are the same everywhere.
But the git folders are outside of dropbox. The version control takes care of syncing the code, but there are all kinds of .gitignored files such as IDE path configuration and compiled binaries that differ (and must differ) between my computers. Heck, even most of the code files are different, because their line endings are converted to win or unix style.
Using dropbox to sync code for the purpose of quickly switching between machines seems like asking for trouble when there are network problems or conflicts...
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.
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.
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.
This is something I constantly have to remind people with "sync" solutions (Dropbox, rsync, robocopy, etc). Anything that mirrors or syncs has the potential to delete the SOURCE material too. That is what it is designed to do.
The responses I seem to get are "NOT if you set it up correctly!!" which is obviously true, while also somehow managing to miss my point entirely.
If you want to just one way copy something then use a solution that is ONLY one way (copy, xcopy, S3 backups, CrashPlan, etc). If you want to mirror/sync then keep a nice backup for when that goes wrong.
PS - Also make sure you know the "rules" a sync solution runs using. For example how does it decide when a file is deleting? Is it just looking at directory update time and lack of files? What if files haven't been synced yet but the folder gets updated?
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.
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.
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®
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.
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).
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.