Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite

I have some friends telling me that Dropbox can be used as a version control tool. I have always used SVN or Git. I was looking around Dropbox and couldn't find anything that tells me about is characteristics as Merging, Fork and other characteristics for a complete VCS.

Can someone point me what I'm missing.

share|improve this question
16  
"is a bad idea" is the logical end of the title's sentence fragment. – Kyle Oct 21 '12 at 19:40
like your comment – Goows Oct 21 '12 at 22:20
Just as a comment, we used this at a place I worked at once, file corruption, duplicates of files galore. Avoid like the plague. – Ryan McDonough Dec 17 '12 at 15:43

closed as not a real question by Mark Trapp, Walter, Bernard, ElYusubov, World Engineer♦ Oct 22 '12 at 3:00

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, see the FAQ.

6 Answers

up vote 15 down vote

Dropbox is not a suitable replacement for something like Subversion or Git for controlling changes to source code. There is some functionality to revert to old versions of files, but (to the best of my knowledge and consulting with the documentation) there is no support for performing merging, or branching. There are some APIs that expose diffs, but you would need to find a way to integrate these APIs into your tool.

However, for personal projects with few (if any) other developers, it's not unreasonable to use Dropbox to store your repositories and make them more readily available. The backup and global access to your files could help make it easier for you to do your development work. This model breaks down with larger teams working on the project.

share|improve this answer
1  
If you only have a small number of people committing at once then having your svn/git repo 'locally' on dropbox works well. With bigger teams there are issues with many multiple updates happening at the same time – Martin Beckett Oct 21 '12 at 16:40
@Thomas: well I think I share your opinion. I just wanted some different opinions and arguments. – Goows Oct 21 '12 at 16:51
@MartinBeckett That's a good point - I'll edit that paragraph to be more clear. I was thinking of the use case where I was either the only developer or the upstream repository was someplace like Github or Bitbucket and what was in Dropbox was my local repository. – Thomas Owens♦ Oct 21 '12 at 17:27
2  
"This model breaks down with larger teams working on the project." If by that you mean "larger than one." Any more than that and you're going to have a really hard time with multiple updates. And worse, nothing will tell you it's going bad. – pdr Oct 21 '12 at 17:39
up vote 4 down vote

You're not missing anything about Dropbox. It's great for sharing files, and occasionally useful to recover a file that someone has deleted or updated by accident. But it shouldn't ever be relied on as a source control application. Never.

At best, when you're working alone and you want your files available everywhere, it's still not as good as a Git/Mercurial repository, because you can't batch changes and publish them with a single comment (so you can figure out later what you were doing).

What you're missing is BitBucket, where you can have free private Git/Mercurial repositories with up to 5 collaborators. Once you're above that number of developers, you need to think about whether to pay for an IT department or pay for BitBucket's extended service, but by that point you're WAY beyond being able to get away with DropBox.

Setting up your repository is about as complicated as sharing a DropBox folder.

share|improve this answer
"But it shouldn't ever be relied on as a source control application. Never." , I like this... I was answering that SVN was a serious solution and that for me Dropbox was more storage in the cloud. – Goows Oct 21 '12 at 22:19
up vote 0 down vote

As Thomas pointed out, you would lose some features that are relied on heavily in team environments. If your goal is to have a file share that is super-simple, it would work. If your goal is to avoid a real version control system at all costs, it would work.

You could use them together. Have the functionality of version control that utilizes the file sharing (price and privacy, sharing may cost more?) across multiple devices of DropBox. I've never done it, but here is a link: http://rogerstringer.com/2012/04/16/using-dropbox-as-a-git-repository.

share|improve this answer
up vote 0 down vote

Yeah, DropBox could be used as a VCS, file-centric VCS. Did you heard of ClearCase? - it's just a big DropBox.
However, there is a lot of people who hate ClearCase, so maybe there is something wrong with file-centric VCSes.

share|improve this answer
up vote 0 down vote

I'll go against the trend and argue that it can prove useful in certain cases.

While I fully agree that Dropbox is in no way a substitute for a proper VCS, it can come in handy when it comes to sharing binary files with others on the team.

The most obvious case is images. The guys whose task is to come up with several different designs for, say, a button on a webapp, will want to share a few psd files, which will then be reviewed by the one who's going to make the call.

Now, while committing assets such as images to source control is definitely worthwhile, throwing in all the intermediate versions isn't going to buy you anything, all the while making your repository bloated (which is especially true if you're using a DVCS). Nevertheless, Dropbox having some sort of rudimentary source control capability, you can still see the history of a file.

So yeah, I think that Dropbox (or Google Drive or whatever) can find its place in a team.

share|improve this answer
up vote 0 down vote

It can be technically used as version control, similar to making a tar.gz/zip file after every change can be used as version control. Which is probably not the best method to go about doing things, even if you include a changelog with every change and zipfile.

It won't include support for things like comparing and diff'ing two different versions, merging different versions, having multiple concurrent branches that you can work on with a simple "git branch" to choose between them, and a list of other features that I am not immediately thinking of. I've done the "zipfile at the end of every feature change" method before and it's clearly better than nothing, but personally I recommend using a proper tool for the job.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.