Quote:
Originally Posted by notmattlythgoe
The thing we're struggling with right now is when to branch, when to tag, etc. We just haven't figured out the best process for us yet. What do you guys do?
|
This is actually one of my biggest qualms with robotbuilder, is that it doesn't support feature branching that well.
Typically I find that the drive train and the mechanisms are separate enough that, as a general rule, work on them (and they're commands) can be split into separate branches.
I personally prefer a mechanism based package structure for this reason. Something like this:
Code:
edu.pmhs
- drive
-subsystems
-commands
- arm
-subsystems
-commands
- robot
-commands (multi mechanism commands)
This allows you to quickly branch the mechanism (subsystems and commands together). It also helps to isolate the modifications that are being done.
Obviously there are still modifications that have to be made to core class (i.e. OI) but these are typically simple enough that they shouldn't require a branch.
I also encourage a "test before you commit" even for the local repo. This ensures that the students verify their work before submitting it. I also wait to do a "code review" until they are ready to publish their work.
We don't have the luxury of a multi student programming team, but I would love a model where you have a student who is responsible for each mechanism, and one responsible for the "robot".
https://www.atlassian.com/git/workfl...feature-branch