Pair Programming in Parallel with Dropbox [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I want to program with a friend (or a couple) out of the same dropbox folder for a project. I want to put all the assets in the same folder, including config and db files. What I really want to know, is why this might be a bad idea.

I can already think of a bunch of positives开发者_开发百科:

• Quickly sync work. As in, almost instant sync. Dropbox, I've noticed, really is that fast that it is almost like working local.
• Program multiple parts at the same time
• Dropbox is fast enough to allow one person to add a method, and then another person ad theirs a moment after
• Eclipse or Gedit both check for changes in the files so we won't accidentally end up with a conflict.

This isn't a substitute for proper source control and versioning, which we would still use Git for. Dropbox does have 30-day versioning, but for obvious reasons, it is no substitute.

I think this is especially powerful in the beginning when this are changing so fast that every team member having the exact same copy of everything is very important. This is a Rails apps if that matters.

---

Don't use Dropbox for that, because you'll be on the phone/IM/whatever trying to figure out who is going to edit a particular file (no concurrency AND no checking out!). Use a concurrent versioning system like GIT or Mercurial. There are tons of other advantages. On the downside for Dropbox, you will end up with "conflicted files" all around, which you won't know what to do with much.

The other advantages to a real version control system are well-known. Here's a list from some random blog:

File space. Let’s say your code changes 10% each week. Under the “folder backup” method, each week you’re saving 100% of the code. Using a proper VCS, you’re only saving 10% of your code. I know hard drive space is cheap, but it’s not free and I never seem to have enough.

History. The key to VCS, in my opinion, is being able to document your changes in more granular level than a file called “Changelog.txt” that might not get changed whenever you work on your code.

Bug-location: Let’s say you find a bug in a method. You search the history for that file and let the VCS runs the diffs for you.

Complete freedom to change code. You don’t have to worry about breaking something, or removing possibly useful code. Before I moved to VCS, I used to comment out old code liberally but keep it ‘cos I might need it. This quickly becomes a PITA.

If you use git, there are several providers for free or cheap online repo.