[Mr. Lim]

We don't program in C++, but instead in Java.

I doubt this post will help you directly, but maybe will aid someone with a similar question, but has chosen Java instead.

Our school uses Google Apps for Education, and so we've chosen Google Code (SVN) for our version control back-end. We did this a few years ago before the free git/github offer was provided, but staying within Google Apps has made administering everything a lot easier. The only "downside" is that Google Code requires that your code be made public, and force you to license under a select choice of open licensing agreements. This really isn't a problem for us, as I don't think we do anything particularly novel - we'd rather do something simple, and do it well. We're the type of team that puts tons of time and effort into things like CAN recovery routines, instead of the flashier programming pursuits.

NetBeans has integrated SVN support, and all our programmers have NetBeans, and the FRC plugins installed on their computers. Using version control doesn't require any changes to the build environment, scripts or any other changes other than they need to type in the repository URL and their Google Code log/pass credentials. All programmers have the ability to checkout, update, commit, branch, merge, and send code directly to the robot.

We usually have 5-6 programmers working on the code at once, with a wireless router setup on the 10.6.10.xxx domain with both an internet connection and a connection to the robot.

After a programmer commits a major change, they yell "update" and everyone else in the room (usually) complies by updating their working copy.

Contrary to the workflow that you're proposing, we allow students to send directly to the robot first and test their code BEFORE they commit to the repository. That's about my only concern with your post. If you require a pull request, then you act as a gatekeeper for code to be merged, and only after you merge is code allowed to be sent to the robot, your devs will get frustrated about how long it takes for them to test their code. I know I would.

Programmers are allowed to send code directly to the robot as our router is configured to hand out DHCP leases on the 10.6.10.xxx domain that don't conflict with the the cRIO, robot radio, DS, etc. Again, programmers usually yell "I'm sending code" and anyone else who had the same thought just waits till the robot is available.

We are diligent about employing the Subsystem + Command structure, and so conflicts are generally rare as most people are working on different subsystems/commands at a given time. When they do occur, we ensure the head or asst head of programming is present to resolve them, unless they are trivial conflicts. As a general rule, we don't allow any programmer to commit anything unless it compiles first.

Our FRC code usually just has a trunk. There is an odd occasion when we'll branch, possibly late in the process to support some minor code differences between a practice vs competition robot. Most other times all programmers are working right off of the trunk, ensuring they update their working copies before each coding session.