[gerthworm]

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