Organizing your programming

[marshall]

Originally Posted by MamaSpoldi

I personally am not a fan of Git either. We have been using SVN for 8 years and it works great. We originally had a local respository, but last year we decided to store the repository online using SourceForge. This makes it easier for each programmer to access the updates individually.

As the programming mentor, I am the only one who can commit new code. This allows me to review all the code before it is shared. This also allows me to keep track of the progress being made and if someone needs additional help or support... or is going off on a tangent.

At competitions where we have no internet access I make a backup copy on a flash drive each time our lead programmer loads new code onto the robot. This is my role at competitions... just like during build season, I am the source code control system integrator. This backup provides a trail of what has changed between each download if something unexpected is affected. This is very helpful when something suddenly works differently on the robot... it helps the programmers be able to validate with certainty what changed and what did not change in the software. Each backup sub-directory is labeled with what was changed and when, eg. CMP-1b-MoreAutoAngle would be the code from Championship, day 1, version b (or 2nd change of the day), and change was adding more rotation driving to autonomous mode. This reminds me at a glance the types of changes that were made and when. After competition, the final version is committed to SVN and marked as a revision.

If you have questions or would like help setting something like this up, please feel free to pm me.

Github has support for SVN clients: https://help.github.com/articles/sup...rsion-clients/

Use git.

[virtuald]

Originally Posted by MamaSpoldi

I personally am not a fan of Git either. We have been using SVN for 8 years and it works great. We originally had a local respository, but last year we decided to store the repository online using SourceForge. This makes it easier for each programmer to access the updates individually.

As the programming mentor, I am the only one who can commit new code. This allows me to review all the code before it is shared. This also allows me to keep track of the progress being made and if someone needs additional help or support... or is going off on a tangent.

At competitions where we have no internet access I make a backup copy on a flash drive each time our lead programmer loads new code onto the robot. This is my role at competitions... just like during build season, I am the source code control system integrator. This backup provides a trail of what has changed between each download if something unexpected is affected. This is very helpful when something suddenly works differently on the robot... it helps the programmers be able to validate with certainty what changed and what did not change in the software. Each backup sub-directory is labeled with what was changed and when, eg. CMP-1b-MoreAutoAngle would be the code from Championship, day 1, version b (or 2nd change of the day), and change was adding more rotation driving to autonomous mode. This reminds me at a glance the types of changes that were made and when. After competition, the final version is committed to SVN and marked as a revision.

If you have questions or would like help setting something like this up, please feel free to pm me.

Yeah, disconnected operations as you describe sounds really annoying and is exactly why we don't use SVN. Here's our workflow at competitions:

• I create a bare git repo on a flash drive (cd /path/to/drive; git init --bare NAME)
• We set up remotes on each students computer to push to the flash drive (git remote add usb /path/to/drive/NAME)
• They do their normal development stuff, commits, branches, stash, etc
• When one of them wants to push code, they plug in the flash drive and do "git push usb BRANCH"
• When someone wants to pull from the flash drive, they do "git pull usb BRANCH"
• At the end of the day, I bring the flash drive home and push the commits up to git -- it's great, keeps history, no folders to keep track of -- and if someone screws something up, a 'git reset --hard HASH' allows us to go back to a known working state

Sure, git has a learning curve. But its advantages are numerous -- particularly in a disconnected environment.

[MamaSpoldi]

Originally Posted by virtuald

Yeah, disconnected operations as you describe sounds really annoying and is exactly why we don't use SVN. Here's our workflow at competitions:

• I create a bare git repo on a flash drive (cd /path/to/drive; git init --bare NAME)
• We set up remotes on each students computer to push to the flash drive (git remote add usb /path/to/drive/NAME)
• They do their normal development stuff, commits, branches, stash, etc
• When one of them wants to push code, they plug in the flash drive and do "git push usb BRANCH"
• When someone wants to pull from the flash drive, they do "git pull usb BRANCH"
• At the end of the day, I bring the flash drive home and push the commits up to git -- it's great, keeps history, no folders to keep track of -- and if someone screws something up, a 'git reset --hard HASH' allows us to go back to a known working state

Sure, git has a learning curve. But its advantages are numerous -- particularly in a disconnected environment.

The advantage of our operations at competition (the "disconnected" operations as you describe them) is that I can view the files on any computer... and we have an automatic backup if something should happen to our programming laptop. This gives us the ability to quickly recreate our environment and software on another system if it becomes necessary. And I don't need specialized tools to access the files. Sorry, I'm old-fashioned and I don't really trust the cloud as my sole backup.

[virtuald]

Not to have a VCS war here but...

Originally Posted by MamaSpoldi

I can view the files on any computer

When checked out at rest on a computer, all the files are there just like SVN and can be seen without special tools. I can copy directories too if I wanted to, but don't need to.

... and we have an automatic backup if something should happen to our programming laptop.

We do one better -- since git's local repo is a complete copy of the repository + history, each repo on each student's computer has complete history, and the flash drive does too. And development at the competition is almost exactly how we do development at home -- just pushing to a flash drive instead of to github.

Also, I can use git diff to figure out exactly what changes were made.

This gives us the ability to quickly recreate our environment and software on another system if it becomes necessary. And I don't need specialized tools to access the files.

Well, if you had a completely raw system with no development tools on it, you would need to install Eclipse+compile tools or LabView. So from that perspective, it's just an extra piece of software you need to have installed. So we're still even.

To answer the original OP's question: At the end of the day, one needs to have a process that works for your team so you can do development at home and at the competition. For teams using text-based languages and more than one team member -- there are a lot of different ways to do it -- but use a version control system of some kind, and don't try to roll your own. There are a lot of opinions on which one is best -- but there's a good reason why distributed VCS such as git and mercurial have been hugely popular since their introduction.

[JohnM]

Wow this thread has exploded in the last few hours. Yes, I'm going back to GitHub. We already having an organizational account that we created back in December/January and we used GitHub along with the Windows desktop client up until mid-March, which is when we switched from LabView to C++. I cleaned up the GitHub account yesterday and since I'm about to teach some programming to members of my team, I'm going to have each of them who have not already create a personal GitHub account and add to the organization.

So basically we will be using Git/GitHub rather than the stupid idea I had in the beginning.

Also I went into the organization setting and downgraded everybody's permissions so that they must make pull requests and I must approve them. (Good idea MamaSpoldi)

BrianAtlanta, I'll make sure to distribute that video to everyone.

remulasce, definitely a relevant XKCD. We had to do that a few times. Will include that in tutorials for teaching Git/GitHub.

My plan is to teach programming (C/C++) which I still putting together material for. When teaching I think I'm going to require the entire group I'm teaching (about ten people) to all use GitHub for a final group project, and they vote on a single person to be the master of the repository (accepting reviewing pull requests.) This way I'm teaching programming and they have to use GitHub if they want me to review their work. Any suggestions beyond this or to add to this idea?

I'm currently writing up a document on what GitHub is and how to use it. If anybody would like to help me with it, PM me and I'll give your Google account access.

One last question. I'm currently using the Windows GUI client to work with repositories on GitHub, is there any opposition to that?

[virtuald]

Originally Posted by MamaSpoldi

Sorry, I'm old-fashioned and I don't really trust the cloud as my sole backup.

Oh, missed that one. One more comment and then I'll shut up...

TL;DR: With SVN, you rely more on the cloud than when using git.

With SVN, to do any operation you *must* have a server involved (eg, the cloud -- even if it's your own personal cloud!). Otherwise if you have no connection to the server, you cannot use any of the normal SVN tools -- they all require a connection to the server. svn log? need a server. svn commit? need a server. svn update? need a server. And if the server isn't available, then you have to go back to the old way of copying files around by hand until the server is available.

With git, I can do all of the normal operations without a server ever getting involved, ever. commit, push, pull, diff, whatever. No cloud required. 100% local.

[virtuald]

Originally Posted by JohnM

So basically we will be using Git/GitHub rather than the stupid idea I had in the beginning.

Not stupid. Naive.

Also I went into the organization setting and downgraded everybody's permissions so that they must make pull requests and I must approve them. (Good idea MamaSpoldi)

Yes, this is a great way to do it. I also give the more experienced students permission to merge pull requests, that way they can work independently.

I'm currently writing up a document on what GitHub is and how to use it. If anybody would like to help me with it, PM me and I'll give your Google account access.

Once it's done, this would be a great document for FIRSTwiki....

One last question. I'm currently using the Windows GUI client to work with repositories on GitHub, is there any opposition to that?

There are a lot of ways to use git. I personally find the command line easiest -- but at the end of the day it's all what works best for you.

[AustinSchuh]

Originally Posted by JohnM

So basically we will be using Git/GitHub rather than the stupid idea I had in the beginning.

Version control gets reinvented quite often. Normally by accident, or by someone trying to "make it easier"

We use Git and Gerrit. Gerrit lets us integrate code reviews into the development process and control the quality of code that goes on the robot. Learn how to do code reviews with github and pull requests, and make that part of your development process. Software is really hard, and the more eyes, the better.

[Knufire]

Originally Posted by JohnM

One last question. I'm currently using the Windows GUI client to work with repositories on GitHub, is there any opposition to that?

I am a big fan of SourceTree as a Git client.

[marshall]

Originally Posted by JohnM

Yes, I'm going back to GitHub.

Yay! Common sense prevails!

[Spillertb]

Im the one programmer on our entire team, and I just use github desktop on my macbook air, works perfectly. I also don't make mistakes so that helps to

https://github.com/FRC-5752/FRC-5752-2016

[BrianAtlanta]

Originally Posted by Knufire

I am a big fan of SourceTree as a Git client.

Love source tree. We switched to git at work about a year ago and selected source tree for looking at the branches. I still like command line for basic commits.

We use gitflow for our branching strategy. Master is competition. One thing I'm trying to get drive team to buy off on is that they control master. So using the git flow we create a release branch and deploy to a bot for acceptance testing by drive team. If they give thumbs up, it's merged into master. Nothing goes into to master with out drives approval.

[EthanJF123]

My team uses LabVIEW, and we use tortoiseSVN for version controlling. Is there is an advantage to using git for a LabVIEW team?

[BrianAtlanta]

Originally Posted by EthanJF123

My team uses LabVIEW, and we use tortoiseSVN for version controlling. Is there is an advantage to using git for a LabVIEW team?

No. The process is more important than the tool. If you had an IDE that would integrate the version control. That would make the process easier.

[SamcFuchs]

Originally Posted by MamaSpoldi

We have been using SVN for 8 years and it works great.

I'm so sorry.

Originally Posted by MamaSpoldi

last year we decided to store the repository online using SourceForge.

Isn't SourceForge the guys that started bundling malware into installers they were hosting? And besides, I think their primary missive is distribution, not FOSS.

Originally Posted by MamaSpoldi

I am the only one who can commit new code.

What if you're not there? As a lead programmer, I would want more security, so that if the mentor was missing or busy, I would still have control. I don't know how many programmers you have, but this system doesn't seem very scalable - I would be concerned about kinks in collaboration.

Originally Posted by MamaSpoldi

At competitions where we have no internet access I make a backup copy on a flash drive each time our lead programmer loads new code onto the robot.

So every revision goes on that drive? Sounds risky. I like that I don't need an internet connection to git commit. And besides, if you need a mentor, how can you deploy in queue? /s

Originally Posted by MamaSpoldi

This is very helpful when something suddenly works differently on the robot... it helps the programmers be able to validate with certainty what changed and what did not change in the software.

Like git diff?

Originally Posted by MamaSpoldi

Each backup sub-directory is labeled with what was changed and when, eg. CMP-1b-MoreAutoAngle would be the code from Championship, day 1, version b (or 2nd change of the day), and change was adding more rotation driving to autonomous mode.

I guess this works if you don't make too many changes at competitions. Personally, I've been known to make anywhere between 10 and 20 revisions at competitions, with I think a high of 30. Those would be very specific file names.

Originally Posted by MamaSpoldi

This reminds me at a glance the types of changes that were made and when.

Kind of like a commit title?

Originally Posted by MamaSpoldi

After competition, the final version is committed to SVN and marked as a revision.

So after all the work at a competition, you have to summarize that all into one revision?

Anyways, I realize that this came off as kind of an attack, and I didn't mean it as one. I'm just considering potential drawbacks of this workflow. I do like that everything gets summed up into one version for each competition. I guess what it comes down to is whether it works, and it sounds like it does for you.

Personally, I will promote git and GitHub for as long as they are the status quo of the professional programming world. I think it's important to learn those skills if you want to succeed in the workforce, and learning new skills that are applicable to the real world is what FIRST is all about. Our GitHub is at GitHub.com/Team236/ and in my signature.

At the same time, I recognize that it is difficult to teach git and learning it requires a level of dedication that is not commonly found on an average robotics team. After all, our team has pretty much one programmer. I'm curious, what don't you like about git?

By the way, thanks for your help at Waterbury. Thanks in part to your help that day, 236 went 11/11 successful autos at CMP. I'm working on motion profiling and vision for the offseason, and maybe we'll something new next year to show off. Hope to see you at CT state champs!