Using OneDrive to Sync Development Machines

[tl;dr : Don’t do it!]

I have a laptop at work that I do most of my development work on, but I don’t take it with me everywhere. Sometimes I’ll find myself at home next to my older PC and wanting to do some work. So what’s the best way to ensure that I have all the most up-to-date code on both machines simultaneously? If you’re thinking “Use source control and make sure you push your changes every night before you go home!” you are correct. But a couple of years ago when I first set this up, I had dozens of projects that I hadn’t created online repositories yet for various reasons (legacy codebases I rarely work on, e.g.) and it seemed daunting to create them.

What about OneDrive?

Since both of my machines run Windows, I thought “Why not move all of my development work into my OneDrive folder? I get a generous 1 TB of space with my Office365 subscription, and  everything will get sync’d in the background between the two machines.”

One of the first issues that arose was that the physical path of the OneDrive folder, %UserProfile%\OneDrive, is different on each of the machines and some of my development tools (I’m looking at you Visual FoxPro) actually hardcode full physical paths in their project managers. So VFP would complain whenever I switched machines. I got around this by creating a job in Task Scheduler to use the old DOS SUBST command to map each PC’s OneDrive folders to O:\ on each machine, I was able to create consistency. I’m actually a little surprised that Windows doesn’t have any other facility for mapping a drive letter to a local folder, but if there is I couldn’t find it.

After the initial sync, everything appeared to be working great.  [cue dark music]

What Went Wrong?

I started noticing that changes I made on one machine did not appear to be syncing over to other machine. Sometimes OneDrive would indicate that there was a problem (e.g. if I had a program open on one machine, it would never sync to the other), but other times OneDrive never said anything was wrong.  It turns out OneDrive’s syncing is a little…unreliable. But that that wasn’t the worst of it.


The bigger issue, which turned into the eventual dealbreaker, was that OneDrive does not handle conflicts well. It has zero concept of merging, which should be easy enough on text files but difficult on binary files (which VFP uses to store source code for screens, menus, and reports). But even times when I worked on a text file on one machine, OneDrive wouldn’t reliable overwrite the older file on the other machine. Instead it would simply rename the new file by appending the machine name to it and sends it over as a “conflict” to the other machine for you to handle manually.

OneDrive thinks these files are different, so it renames one of them.

And on top of all that, OneDrive’s “conflict management” couldn’t even distinguish when there weren’t any conflicts. The two files in the graphic above, for example, are exactly the same, yet OneDrive renamed one of them anyway and sent it over to the other machine.


Don’t do it. If you want to use OneDrive for storing non-important stuff that doesn’t change very often that’s probably more in line with its intended use, but do not use it as your development workspace. And I don’t think DropBox, Box, or anything else would be any better.

I ended up creating a C:\Dev folder on both machines to get around the fact that %UserProfile% was different on my machines, and checking the code I’m actively working on into git repostitories on BitBucket. I push changes every night like a good boy, and pull every morning.







Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: