Quote:
Originally Posted by Tom Bottiglieri
Typically, everything lives in master. Sometimes we will tag at the end of an event so we can dial the comp bot back to where it was (as we change code a lot between events), but most times we forget to do this. Usually there is only a small group of developers using one laptop to write code, so keeping branches in sync isn't really an issue.
If a student is working on a feature that is easy to break off, I will have them make a branch that we can pull in later. An example of this is something like a tiny HTTP server or your vision code. Define the interface then let them hack on the implementation in a branch.
The main rule is don't commit code that breaks the build!
|
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.