Multiple programmers: version control or naw?

[weaversam8]

Our team has sustained major growth this year, up to around 40 students. A good percentage of them wish to learn programming, which is a huge load on our 2-man programming team.

Programming the same robot with 2 people proves challenging enough, let alone 10.

Does anyone have any experience with multiple people working on the same code?

[BigJ]

I encourage you to look into github - and learn how to use git while it is still preseason

There is a link to their education subsite in this topic where you can get a free organization account for your FIRST team.

http://www.chiefdelphi.com/forums/sh...ghlight=github

If you try to get on without version control you're going to have difficulties down the road!

[notmattlythgoe]

The answer to version control is always yes, no matter how many people you have working on the code.

[Woolly]

I have found that version control can be handy even with only 1 programmer, and its usefulness grows exponentially with added programmers.

[pastelpony]

We had 6 programmers (including myself) touching the code when I was a freshman. It certainly wasn't the cleanest code ever written. The next year, we had 2, which led to way cleaner code. This year, it's currently only me though it should increase to 3 when I get last year's freshmen fully acquainted with LabVIEW. I think smaller groups = cleaner, quicker, and more efficient code. Keep version control; you don't want any difficult code you wrote to be accidentally removed.

[Joe Ross]

Not only do you need version control when working with many programmers, you also need a code framework that is conducive to having many people working on the code. You didn't specify what language you're using, but for C++ and Java, the Command Based framework does a good job of doing this. Other teams have created frameworks for the same purpose.

There are many other things on a robot team that can use programmers as well, so it may not be necessary to have everyone working on the robot. Dashboard, scouting and the website are things that other programmers can work on.

[faust1706]

A big way github sponsors frc is by giving teams free repos. Use them.

[Chadfrom308]

Github is only as good as the comments you put into them

From XKCD:


Also, Tortoise HG and Mercurial is like gitHub, but you can do code merging in this one (like 2 people work on the same code, it checks for errors, ect)

[pyroslev]

Originally Posted by Chadfrom308

Github is only as good as the comments you put into them

From XKCD:

I learned this in 2008. Good comments in the code help when you do commits and your commit comments get like XKCD photo.

And by going through Github, you do your CSAs a favor. It allows us to look at the code at our leisure or link to others for troubleshooting help/highlighting coding brilliance.

[Mr V]

Version control is highly recommended even with only one person doing the programing. It "bus proofs" your code.

[MamaSpoldi]

Originally Posted by Joe Ross

Not only do you need version control when working with many programmers, you also need a code framework that is conducive to having many people working on the code. You didn't specify what language you're using, but for C++ and Java, the Command Based framework does a good job of doing this. Other teams have created frameworks for the same purpose.

There are many other things on a robot team that can use programmers as well, so it may not be necessary to have everyone working on the robot. Dashboard, scouting and the website are things that other programmers can work on.

Version Control = YES, regardless of the number of programmers.

I also totally agree with Joe's comments above. We use C++ and generally start with each student programmer taking control of a single class that defines the operation of a robot mechanism. There are of course also "shared" pieces of code including the main Autonomous() and OperatorControl() functions which interact with these classes. This is a place where the version control is particularly helpful.

In addition to a formal version control system, we also make copies of the software at competitions every time the code is deployed to the robot. This ensures that there is never a question about what code is on the robot. This is particularly important if your version control relies on the internet since internet access is generally unavailable at competitions.

[hardcopi]

Yup, version control is the way to go. Github, bitbucket... whichever. I like bitbucket because they have built in issue tracking, wikipedia and a chatroom. Cost might be an issue (it is free for the first 5 users) but I haven't looked into an educational version.

[krieck]

Certainly you should use version control for all your projects.

With a lot of programmers, make sure you decompose the overall robot into a lot of decoupled modules. I highly recommend the command-based pattern for organizing the robot program, which breaks the program into separate subsystems and separate commands. You can give each subsystem to a different programmer and (hopefully) their code won't conflict with other subsystems. Later, programmers can write command classes that are (mostly) decoupled from other commands.

Also, consider programming on platforms other than the roboRIO. You can do sensor processing on Arduinos or vision processing on a Raspberry Pi, and then communicate back to the roboRIO.

[weaversam8]

Thanks for your opinions. I was planning on doing vision on an rPI, anybody got a link to a good tutorial on that, or advice?

[krieck]

Most vision processing books are either way too simple or way too deep. I recommend Practical Computer Vision with SimpleCV, which uses a Python interface to OpenCV.

I'm not a big fan of Python, but this is the best introductory text I've seen.