views:

340

answers:

3

I got a laptop in preparation for the coming semester, which will see me taking a university programming course while working full time. I will, of course, be using a source control system (probably Subversion) and had the idea of creating my repositories in my Dropbox folder, which would enable me to check out and work on code locally using my laptop or my desktop (or, indeed, any other computer that can access the Internet), and then commit it back to the shared Dropbox repository.

  • Any pitfalls or reasons why this is not a good way to accomplish my goal? (Let's assume that I can avoid corrupting the SVN repository by doing something stupid.)
  • Any clear advantages to going with a web hosting solution that would outweigh the advantages of Dropbox (viz. it's free and already set up on my machines)?
  • Any other strategies to share for working on code from multiple locations?

Note: I do not intend to share the Dropbox folder with others, as I realize that multiple people accessing a repository via file:// is a bad idea. My question only pertains to an individual user.

+3  A: 

While at first glance this seems like a bad idea (basically layering two different revision control systems on top of each other with different workflows), there is a way that would make sense for you assuming you are the sole developer.

(As a side note, what Dropbox gives you is offline backup of your data as well as a server from which to sync with. If you attempt to use SVN on its own, you will have to configure your machine to allow access remotely. This may or may not be a deal-breaker for you depending upon your level of expertise in sysadmin type tasks.)

What you could do is create a repository for a given project in your Dropbox drive. Then when checking out a working copy, create it outside of the Dropbox folder, accessing your repo using the file: protocol. This way the repository stays synced across all machines, but each machine has a separate working folder, allowing you to work on a different branch on one machine than another if you wish, or maintaining uncommitted code without it getting propagated to another machine. Where this breaks down is if multiple people are accessing the repo via the file: protocol - this is not recommended due to possible race conditions.

Note: this solution allows you to continue to commit even when offline, like other DVCS would. But note, doing this and then committing offline on another machine before allowing the repos to sync could be disastrous! It is extremely important to allow the repos to sync after working offline before doing a commit on another machine.

RedFilter
The workflow you describe is what I'm proposing to do, and I edited the question to make that clearer.
Michael Hackner
I added a note for a potential danger.
RedFilter
+1 very good point, I hadn't thought of that.
Michael Hackner
+2  A: 

I would suggest using a DVCS rather than Subversion with Dropbox. The reason is that it is possible to produce a merge conflict with Dropbox by changing the same file from to machines at the same time with limited / no network connectivity. If you manage to mess up your subversion repository like this, it will be difficult to fix the repository, whereas with the popoular DVCS systems you can at least nuke the broken repo and clone a local version of it back to the Dropbox share.

I realised while writing the above, that you do not mention whether you are using more than one computer with the same Dropbox account, so the above does not really apply if you're using your Dropbox account with only one computer (I guess it might if you do something really silly / weird).

liwp
I should add that I do exactly this with my emacs and shell configuration files: I have a Mercurial repository on Dropbox which I clone onto all the machines that I use. Whenever I makr changes to my config I push them back to the Dropbox repo and pull them onto all the clones. So far it's worked great.
liwp
+2  A: 

I would use Git and Github. Then you have a source control AND you can easily access it from both places.

Or even more ideal would be to setup your own server to host the svn or git repo, but that's obviously not always an option.

Tyler Smith