Easiest/Best setup for multiple development computers

Hey everyone,

I have a question that I am hoping someone can help me out with, its an organizational thing more or less.

This year I am moving our team to using proper source control using git and gitub. I plan on maintaining the master repository and I want to have the students and other mentors use proper pull requests to have me merge their work into the main robot program.

In order for this to be effective I need the easiest way to setup a build environment for all the students, now these systems don’t need to upload to the robot necessarily just let them know if they have made a syntax mistake. If there are no mistakes we can merge the code and go forward with it.

I was hoping I might be able to set the WPILib up with code blocks or possibly even a command line compiler for a quick setup on a bunch of computers and then setup windriver on only a few for actually uploading code to the CRio.

Has anyone else done a distributed setup like this for their team? I’ve also been looking into the ucpp and new toolchain being a linux user myself. Also along the same vein has anyone setup a buildbot for FRC projects? This is new territory for me but it would be cool because then I could run the bot after accepting a pull request and have any issues emailed to me.

Anyways let me know if you’ve done something similar!

I set up a system last year using github, and it worked fairly well. We installed Wind River on 4 of the school computers, along with the main programming laptop and the classmate. We could have done setups without full WR installations, but I figured it would be more convenient to have the a consistent IDE/toolchain across all devices. On top of that, I set up an installer that installed the EGit plugin for Wind River, ran the WPILib updater, and did the initial setup for git (installing ssh keys, loading git configuration into WR, and put a preconfigured repo into the workspace). Note that (at least with the 2012 tools) you had to install disk 2 of Wind River for EGit to be compatible. With this, a programming environment would be fully functional after installing the 2 disks and running the custom installer. I can supply the source files for the installer if you’d like.

In terms of organization, we had separate branches for each group working on the code, generally split by subsystem. I would then merge those into the master branch when they were stable. Pull requests are an interesting idea, but I personally would find it disruptive to have to move out of the IDE to get something merged. Under this setup, the use of github is almost completely invisible.

One downside of the installer method is that all of the computers end up with the same ssh key, and thus all use the same github account. This isn’t so much of a problem for us though, since EGit by default signs each commit with the username of the windows account, and in our case that was the student’s name. For your situation, you probably wouldn’t have that same benefit, but you can still manually set names and emails. Github is also smart enough to recognize known email addresses and tag commits with the proper account.

In terms of buildbots, I haven’t tried anything like that. Wind River uses makefiles for builds, so you’d probably be able to set up one around that.

In terms of getting everyone set up with the exact setup for development, I created a VirtualBox VM for all of the programmers.
I set up Ubuntu inside the VM and installed Eclipse and Java and all the necessary tools so that everyone has a fully featured development environment on their laptops.
I just passed around a USB hard drive that had the VirtualBox installer and the VM files and had everyone install it at one of our first programming meetings.

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.

Our team uses Mercurial Tortoise and a bitbucket cloud storage account to not only provide for multiple computers, but also for source controll. This will work for C++ and Java easily, and can be simply made to work for LabVIEW as well.