FIRST Robotics Competition Documents
Ever since NI took part in the Ri3D adventure, we've been receiving questions about how we had multiple developers working on the same robot project simultaneously. This problem is something many people have tried to tackle and run into hurdles as merging visual code isn't as intuitive as merging text-based code. As a result, it's important to plan ahead and make decisions that allow your group to be as efficient as possible while working on the same project.
First, I wouldn't suggest having two developers working on the same VI at any given time. So, how do I get around that? I start by having a team create a new robot project using the Command and Control option. 
When you create this project, it'll break up your code into a variety of subsystems. Notice each of the folders are blue with the yellow silhouette. That means they are auto-populating folders. An auto-populating folder will sync with the folder on disk and keep your project matching. This is what makes group development easier with Command and Control. The first step for the lead developer is to follow through the tutorial for Command and Control by clicking on the link here. That will guide you through the overall idea behind Command and Control and teach you how to add subsystems. Create a project with the required subsystems and push that to your source code control, github as an example. That will give everyone that downloads the project from your source code the folder hierarchy required to be successful. Once this is in place, each developer can take ownership over one of the subsystems. As they develop for this subsystem, they'll create VIs others can use. Once these are pushed to source code control, they'll automatically be added to the other developer's projects on their next update from the server.
With advanced planning, empty VIs can be created for each subsystem before anyone starts coding. In this event, developers are free to use the actions the other developers will create even before they're finished. When they do this, it'll let the functionality be pulled in later without slowing down any progress creating important bits of code such as autonomous or teleop VIs.
If you realize you want another subsystem at a later point, it's as easy as adding it to the project and pushing that update to the source code control server. Developers can pull this down and they'll get all of the new folders and updates made.
The most important element to be aware of here is the natural way Command and Control will challenge your team to think in modular ideas. By approaching their robot project design from a modular mindset, they'll write more advanced code and learn better programming practices from the start. As an added bonus, it'll remove some of the complexity surrounding timed tasks in Teleop.
