[NotInControl]

Originally Posted by notmattlythgoe

Ok, so it sounds like you're doing pretty much the same thing we're doing. We keep a trunk version and a branch version. Once we're sure the code is working in the branch the way we want we'll merge it into the trunk. We also do a lot of code changes between competitions (adding in a 3rd ball pickup to our 2 ball autp after week 4 and adding in CheesyVision for hot goal 1 and 2 balls currently), the first thing we did was tag our competition code from week 6. I've heard of teams that make tags after each meeting, this just seems excessive to me but we're still trying to hash out our best practice.

The pain in the butt thing we ran into this year was our practice bot is using 2 solenoid cards instead of 1 like our competition bot is using because of a lack of correctly voltaged solenoids, so making sure we don't merge in our address changes can get annoying. We currently have 2 working branches open, one for competition and one for practice so we're not constantly having to make sure we have the right addresses in. Keeping both branches and the trunk in sync is a bit annoying.

We do it a bit differently. Master is kept as the latest working/tested code that can be deployed to the robot and guaranteed to work. And only Mentors are allowed to push to master as an understanding by all programming members.

Everything else is done in branches. Every feature is branched and pull requested. The programming mentors review the branches, and either make comments, or merge it into master once the code was tested.

Now sometimes during a competition, we will work in master, but we will push to github into a new branch. And then follow the same process.

I have all of my students setup using eclipse and egit (what i personally use on my Ubuntu FRC laptop), although some students on our team use gitGui on Windows for managing their comits. We rarely ever tag, but we should.

Note: The above is the ideal scenario on our team, I hope I get to see the day that it actually works like that. LOL.


As for maintaing multiple versions of the code. The Poofs wrote a pretty neat library called a ConstantsFile I belive. It is an object that you can use to declare variables in RobotMap and then overwrite them using a textfile that lives on the CRio. If the textfile doesn't exist, it just defaults to the hardwritten value in code. I am sure someone on 254 can explain it better.

Essentially, you can maintain one code base for your comp bot and practice bot, if you wrote your variables such that they can be updated on RobotStartup via a text file, and have that text file live on the practice bot cRio. This would allow you to keep the same single source and the text file on the practice bot does the heavy lifting for you. You can accomplish this using the Poofs method, or implement your own.


As for advanced topics for command base:

1. Commands are loaded during their instantation on RobotInit. How to pass a value to a command in realtime during robot run.
2. Default commands, and how/when to use them
3. CommandBase programming philosophy. When to make something a method/function within a subsystem, when to make it a command, when to make it a command group.
4. And of course, no programming class is complete with a proper "how to comment code" discussion.


Hope this helps,
Kevin