VS Code: How do I synchronize workspaces between multiple systems?



It turns out that what I really wanted was to be able to do remote development on my laptop, and – if I also did something local on my robot, to have the changes show up on my main development system.

This substantially similar question was asked about 10 months ago and has received no replies since then.  As there have been a lot of improvements in VS Code since then, (and since Stack Overflow discourages "Me Too!" replies), I have decided to re-ask the question in hope that someone will notice it and reply.

Viz.: https://stackoverflow.com/questions/60034690/how-to-sync-workspace-folder-beween-host-and-remote-target


  • A Windows 10 system running VS Code, both current as of this instant date.
  • A Raspberry Pi based robot, (a GoPiGo3) that has the remote development using SSH software installed that allows my Windows 10 system to communicate with it via VS Code.
  • I have made an exact copy of the workspace environment, in its entirety, including the enclosing workspace folder, from the Windows 10 system to the robot, using FileZilla.

My previous workflow was to develop on the Windows box, transfer to the robot, run on the ‘bot using Thonny, note any errors and either fix them in-place, (within Thonny), and transfer back to the Win-10 machine or fix within Windows 10 and transfer back to the ‘bot.

"Clumsy" is a masterpiece of understatement.

Now that I have set up Remote Development on the bot, I believe I can escape most of that.

What I notice is that within the robot’s copy of the workspace, most, (if not all), of the files are now either "modified" or "untracked" and updating my GitHub repo from the ‘bot will cause all kinds of confusion.

What I want is the ability to develop on either platform seamlessly. (i.e. Changes made on the one are automagically reflected on the other when next connected.) And I want to do this in such a way that the commit and/or change status is accurately reflected on both machines.

I could go into a long explanation as to why this is useful to me, but this question is long enough already.

Any help would be gratefully appreciated.


OK people, I think I have this figured out.

Lesson #1:

  • It turns out that my original problem was actually more about workflow and "what’s the best way to do a specific something", as opposed to how to do dual-development.  So, in essence, I was asking the wrong question.
    (So, I have to down-vote myself now because I asked a bogus question, right?  :wink!:)

Lesson #2:

  • You do not have to install the entire VS Code IDE on the remote device.

    That’s the original mistake – I misunderstood "install VS Code on the remote device" and I installed the IDE itself in both locations.

    • The result was that it slowed down the robot so much that it was unusable.
    • Having more than one instance of the VS Code IDE installed created confusion about what was happening where.

Lesson #3:

  • I did not realize that VS Code can install a small server module, (like a shim of sorts), and do some SSH magic on the remote device that allows VS code to use the remote device as if it were local to your main computer or laptop.

  • What you do is open VS Code on the local device, and then tell it you want to connect to a remote device for development.

  • Once you have that sorted out – this is very site specific and a web search is your friend – you can edit code and even execute code from your local computer and have it run on the remote device as if you were physically there.

In my case, (after experimenting with several different ways to work on my projects), I discovered that placing the VS Code IDE on my Windows based laptop and the "server", (shim) module on the robot, (with the appropriate extensions installed), provides an almost seamless environment that doesn’t appreciably load the robot’s processor – a Raspberry Pi 4.

  1. Make sure the workspace on the local computer is fully up to date on GitHub (which is where my project repo is located).

  2. Install the requisite VS Code remote development modules and make sure you can communicate with the remote system.  Exactly how to do this is specific to your environment.

  3. Either "sync" or "clone" the relevant GitHub repo down to the device using the remote dev tools in VS Code as if it were your local box.

  4. Note that this is very system and site specific.  VS Code does a good job of helping walk you through this, and a web-search will rapidly clear up any lingering questions or issues.

Eventually you will have a fully up-to-date version on the remote platform.

When this is done, you won’t have to mess with manually syncing code as the code is already on the ‘bot.  All you do is edit code on your local machine, (my Windows laptop for example), and run it from VS Code.

An additional advantage is that if you have to duplicate or clone the robot’s workspace, or restore the workspace from a backup, (you DO have your projects in a separate folder don’t you?), all the "vscode" and "git" information is located there too and you can re-open your project after moving it with everything intact.

Additionally, if you have VS Code set up on different machines in different places, it might be possible to connect to the same server endpoint and have the same environment available.

(i.e. One installation on a desktop at work and another installation on a laptop for use on the road, (or while quarantined), both connecting to the same server endpoint.)

  • Note: I have not done this personally and it might require further research.

What I ended up doing, workflow wise, is that I do the lion’s share of the development within VS Code,executing remotely on the robot itself.

Sometimes, if I want to try a quick and dirty fix, I’ll "break the forth wall" and open an editor directly on the ‘bot itself and it automatically shows up as "modified" within VS Code.

Answered By – Jim JR Harris

This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0

Leave A Reply

Your email address will not be published.

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More