R – How to a mobile student effectively use Dropbox with a source control system

dropboxsvnversion-control

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.

Best Solution

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.

Related Question