Re: Organizing your programming
 

First, I'm always there... just ask our programmers. :yikes:
Also because of our development methodology there is somewhat less interaction between the coding being done by individual programmers than for some other teams. In general, no 2 students are working on the same source files. Each programmer works on a class that is related to their own robot mechanism. The exceptions to this are related to button assignments (and their implementation in the main code loop) and the autonomous mode coding which are generally handled by the lead programmer. Although the autonomous code generally resides in the main robot class it is isolated in separate function which is simple to merge with other changes if needed.


We never deploy in queue. That is a very dangerous idea... mistakes happen when you are rushing. We always do a basic system test after deploying code to verify the robot operates correctly.


We generally have more changes at early competitions than at later ones. Even so, the naming-system we use gives us 26 revs per day of competition which seems more than sufficient even based on your estimate. :D

Each deployed version can be checked in separately, and in fact that is often done for early competitions when there are more changes made. We mark the final versions of each file as a tagged revision, ie. this is the code from event X.

I strongly agree that the goal of FIRST is providing skills that will help students in the real world. But I think that you may be overestimating the universality of Git. I realize that it is a big part of the online, shareware community and it is great that it is being used by FIRST teams as well. But I have been a software engineer for over 30 years and have only seen it used on one commercial project that I have been part of. I do not want to imply that it is not used commercially but to point out the commercial world is vast and does not always reflect what you see/hear on the net.

I don't care for the paradigm used by Git and some other recently developed source code control systems. Like I said, maybe I'm a bit old fashioned. I prefer the straight forward use of check-in and check-out (or commit and update if you will) rather than commit/update/push/pull. I just find it unnecessarily complicated and redundant. Of course, I'm not a big fan of the cloud either... I don't trust it yet.

Always happy to help a fellow programmer. See you Saturday!

Re: Organizing your programming
 

It's better at 30,000 feet:
https://cloud.google.com/actual-cloud/

Re: Organizing your programming
 

I'm into year 10 of my current career path and this project I'm on now is the first time I've seen and used git. Coincidentally I was learning to use git for the first time right around build season in 2015, so I was learning it at the same time my programming students were! That led to some fun times.

Yes, the bottom line is that students need to get used to the idea that they don't work in isolation - that there is version control, team collaboration, and the concept of risk management (don't deploy new code until it has been tested!) (One of my proudest moments this year was actually when our most "enthusiastic" programming student said "I think we should just leave it for now. It works, and the drive team is doing well with what we've got. We can fix [the remaining issues] in between now and our next competition." YES!)

Git is a good system but it is not the only system and it is not the best system. There is some thinly-veiled "git is best" attitude in this thread.

Prior to git, I've used ClearCase/ClearQuest, a stupidly obtuse one called Continuus, and CVS.

I do like gitflow and I'm getting used to Github, but I'm told that coming from a ClearCase mindset is actually making it harder for me to wrap my head around git concepts. So I totally understand if students are confused.

The YouTube link posted earlier is a great presentation.

Re: Organizing your programming
 

Yes! I have been there before too... especially when the cRIO was first brought in. That was a big paradigm change for FRC... and then again but to a much lesser degree with the roboRIO introduction. But I must say it is a great experience to learn things along side the students. It helps them to see that we continue learning throughout our lives. Regardless of the level of experience we have there are always new things to learn and figure out.

Awesome! I applaud that realization. It shows a level of maturity and experience. I think that too many times changes are made when they are not needed and often have unintended consequences. You should be proud that you have instilled this level of consideration into your students. This is possibly the biggest lesson that they can learn from our experience. Think things through before you make a change... and review the change (preferably with another set of eyes looking over your shoulder) before you deploy it.

I definitely will check out that link. I'm interested to see what it has to offer by way of process and explanations.

Never too old to learn new tricks... but old enough to be skeptical that new tricks are always better than the old ones. ;)
Thanks!

Re: Organizing your programming
 

Well, as others have said, version control is your answer. Although the team didn't like git as a tool this year, git will solve the problem you have proposed. In fact, saving copies of your code at crucial points, as you have suggested, is pretty much what git is doing under the hood.

Using the tool properly requires team discipline to follow a workflow. When everyone does their own thing, it's pretty much guaranteed to fall apart. Here is one workflow suggestion that has worked well for us:

One student or mentor is the lead ("architect"). Other students are developers. The lead creates the initial project in the repo. This should be on a special branch (call it "master", maybe). By process, you must guarantee that the latest work on master represents the latest version of working software for the robot.

After this, developers are assigned specific tasks to work on. Each task should be done by creating a brand new branch at the latest commit on master. ALL of the work for the task should ONLY be done on that task's branch, nowhere else. If another task is started, start a new branch. In this way, once a task is completed, there is a 1-to-1 relationship between "this task was completed on this branch".

Once a task is completed, the developer should review the changes made with the architect, and possibly other developers. Look for bugs. Try the software out on a robot, if possible.

Once the architect and developer are satisfied the code is as correct as it can be, the architect should merge the latest on that development branch back to master. If multiple tasks are being merged, the developers and the architect may have to work together to resolve merge conflicts (where two developers made different changes to the same line of code). Note by carefully ordering tasks and merges, you can avoid most merge conflicts.

Finally, after content has been merged to master and tested on a robot, you may put down a tag to establish a milestone in software production. Use some simple numbering system (ex: v1, v3, v46, etc.) to indicate the progression through time. These are helpful in understanding which points in time functionality was added/removed and tested.

The most important part here is properly using branches. Minimize changes made directly on master - none if possible. All tasks should be done on their own branch. No re-using branches for multiple tasks. No putting tags wherever you want - tags indicate a set of proven functionality.

Not to say you couldn't ever deviate from this workflow, but having the standard up front is crucial to the success of a version control system

Re: Organizing your programming
 

Not going to get into the version control system argument here, other than to use Git.

Now, a couple of other things -

GitKraken is my GUI client of choice when I use a GUI client, but the git command line program is fantastic and actually extremely easy to use. Eclipse also has built in support for Git through E-Git, though it's not great it's helpful if you already have eclipse and don't want to install anything extra.

Another hosting alternative is GitLab, which besides providing servers also provides a community edition, which lets you install GitLab and self-host it on any machine/VPS. We used it last year and it was incredibly powerful.

Re: Organizing your programming
 

For anyone starting out in version control, Git is the predominant option in industry today which is easily shown through this Google Trends search. There is no need to get into a VCS war when clear data is available.

For those new to Git, try the following tutorials:

• http://www.codecademy.com/learn/learn-git
• http://try.github.io
• http://learngitbranching.js.org/

I generally use the command line, but when I need an IDE I use SourceTree: it's fully-featured, stable, and free.

Re: Organizing your programming
 

Ironically, that's the type of attitude that actually starts flame wars.