With the recent announcement of WPILib adopting Visual Studio Code and the recent release of Visual Studio Live Share, I started thinking about the viability of collaborative programming for my team.

Before this past season started, our team switched to OnShape and we loved being able to work concurrently on any given subsystem.

However, I am trying to think of how this collaborative workflow would translate over to our programming team. What is everyone's thoughts on this?

I have been experiencing with this for a while, and it's super cool. I don't think the deploy commands for the roborio will work remotely, but it terms of collaboration and intellisense, it should work great. We will keep doing testing at wpilib and seeing if there are any cool and viable features that will work for FRC.

__________________
All statements made are my own and not the feelings of any of my affiliated teams.
Teams 1510 and 2898 - Student 2010-2012
Team 4488 - Mentor 2013-2016
Co-developer of RobotDotNet, a .NET port of the WPILib.

From what I've seen the host can create a shared terminal. That should work for deploying if the host is connected to the RIO since it's just a gradle task right?

Yes, a shared terminal would definitely work. But things like the buttons specifically for deployment, and the command creation buttons likely would not work.

__________________
All statements made are my own and not the feelings of any of my affiliated teams.
Teams 1510 and 2898 - Student 2010-2012
Team 4488 - Mentor 2013-2016
Co-developer of RobotDotNet, a .NET port of the WPILib.

My long grey beard and suspenders say this is horrible and kids these days have it way too easy and everyone needs to learn git (and clearcase and svn and shell-only development and assembly cuz that's what real programmers use).

But, seriously, someone(s) try it out and let us know how it works. I'm leery to trust it with the integrity of the codebase, especially with the number of programmers we have, and the level of git expertise we already have. Still though, if we can show it's a genuinely better development process, I see no reason not to adopt.

My long grey beard and suspenders say this is horrible and kids these days have it way too easy and everyone needs to learn git (and clearcase and svn and shell-only development and assembly cuz that's what real programmers use).

But, seriously, try someone try it out and let us know how it works. I'm leery to trust it with the integrity of the codebase, especially with the number of programmers we have, and the level of git expertise we already have. Still though, if we can show it's a genuinely better development process, I see no reason not to adopt.

This isn't a version control system, and it's not meant to be. It's meant to be a means of doing pair programming from two different machines, or from teaching people from a remote location (which is effectively pair programming anyway).

I would be mildly horrified if someone were to use this as a VCS by setting up a constant VS Code session that you connect to.

This isn't a version control system, and it's not meant to be. It's meant to be a means of doing pair programming from two different machines, or from teaching people from a remote location (which is effectively pair programming anyway).

I would be mildly horrified if someone were to use this as a VCS by setting up a constant VS Code session that you connect to.

TIL! I got the wrong impression from my 30-second perusal of their website.

Fun story: Back in college, for our OS class, the main project was work in a team of 4 to write an OS in ~5 weeks. Pretty nifty. They set up SVN for all of us to use but, for a good chunk of the class, this was the first they had even heard of "version control". One group had posted on the online forum for the class about "How do we possibly have multiple people write the same software? Can we write our code in google docs and then copy-paste into real files to test?". aaaaahahahahahahuummgmgmgpphhhhh.... I read this and was comforted that they had identified the key problem, but failed to see the solution already provided to them. None the less... this has left me with a lasting dread of similar workflows.

TIL! I got the wrong impression from my 30-second perusal of their website.

Fun story: Back in college, for our OS class, the main project was work in a team of 4 to write an OS in ~5 weeks. Pretty nifty. They set up SVN for all of us to use but, for a good chunk of the class, this was the first they had even heard of "version control". One group had posted on the online forum for the class about "How do we possibly have multiple people write the same software? Can we write our code in google docs and then copy-paste into real files to test?". aaaaahahahahahahuummgmgmgpphhhhh.... I read this and was comforted that they had identified the key problem, but failed to see the solution already provided to them. None the less... this has left me with a lasting dread of similar workflows.

Therefor:

You have been warned. Here be dragons.

I donít see why you couldnít have every change update live in a server and have all files be shared. I feel like this could actually be useful to avoid miscommunications. Of course, git is easy enough to use instead of setting up everything prior...

I don’t see why you couldn’t have every change update live in a server and have all files be shared. I feel like this could actually be useful to avoid miscommunications. Of course, git is easy enough to use instead of setting up everything prior...

It gets complex if two people happen to change the exact same line at the same time. There's also the question of how you mark down certain points in the development history as "important", or how to try something out before forcing everyone else to pick up the change. Mostly, these are just general version control questions.

Clearcase is a different, ancient version control system that did some of this live updating, at least in the context that the version tree was stored on a server, and any file changes you made were by default server interactions. Though not everyone had to have the "live" view, every change was "instantly" available to everyone else. It has its benefits, but also its drawbacks (indeed, this style of VCS was what Torvalds was using as an anti-example while creating git).

I think the live-update works to a point, but as you're looking for more advanced development workflows it starts to break down. But, YMMV, and at the end of the day, the real goal is to make working software for your robot as quickly as possible. Whatever way you find to get that done, and also that makes sense to ya, go for it! Darn the naysayers!

Re VSCode and version control - I will say I've been impressed by the git integration into VSCode. I've started using it for viewing diffs before making a commit. I still prefer using the command line for most other things. I do like that it whines if your commit message line is over 72 characters.

I haven't had a chance to try out Live Share, but I'm looking forward to it.