Stephen Collings asks:
I work in embedded systems. Right now, my organization has two full-time programmers and two occasional programmers. It’s rare that the same project is worked on by two programmers. All code is stored on a network drive. There are folders for the current production code, another folder for the source for every released version throughout history, and another folder for active work. We have an automated system (Mercurial being abused) that makes backups of every changed code file in Working every fifteen minutes, so we can revert to previous states.
My question is this: is it worth the trouble to set up a formal versioning system in an environment like this? Why or why not?
See the full, original question here.
Time is precious
Christopher Creutzig answers (41 votes):
Just my personal view: version control is useful for anything that takes me more than half a day or that involves a lot of trial and error—or both, of course. If it involves two or more people who are not using the same keyboard and monitor all the time, it is essential.
The cost of using a formal versioning system, beyond the initial learning curve, is negligible. Initializing a repo? Two seconds. Adding files? One second. Being able to go back to what I tried this morning and discuss what I discarded with my colleague? Worth hours or days, easily.
Kilian Foth answers (32 votes):
Version control was always needed, even before you hacked together your “but, we backup really often!” kludge.
Version control lets you publish changes across files that belong to a logical function as a unit. If you need to review “what was necessary for case-insensitive sorting in that mask?” it tells you all relevant changes and suppresses the irrelevant ones.
Good version control keeps track of file names and metadata, and it tracks the provenance of every individual line of code.
Version control lets you tag all changes with the reason you made them.
Version control is not about allowing more than one person to work together. It is about guaranteeing the historical record of your codebase. Secure in the knowledge that you cannot lose anything, or even forget when you did it and how, you are free to refactor, invent, and create without fear. And you don’t know what fearlessness is before you’ve experienced it.
There’s a better way
MainMa answers (74 votes):
As you describe it, you already have some sort of version control, though currently there are some issues with it compared to a typical version control.
An intentional commit in version control indicates that the developer strongly believes that the current state of the system would build successfully. (There are exceptions, as suggested by Jacobm001’s comment. Indeed, several approaches are possible, and some teams would prefer not trying to make every commit possible to build. One approach is to have nightly builds, given that during the day, the system may receive several commits which don’t build.)
Since you don’t have commits, your system will often result in a state which doesn’t build. This prevents you from setting Continuous Integration.
By the way, a distributed version control system has a benefit: one can do local commits as much as needed while bringing the system to a state where it cannot build, and then do a public commit when the system is able to build.
- Version control lets you enforce some rules on commit. For example, for Python files, PEP 8 can be run, preventing the commit if the committed files are not compliant.
- Blame is extremely hard to do with your approach.
- Exploring what changes were made when, and by whom, is hard too. Version control logs, the list of changed files, and a
diffis an excellent way to find exactly what was done.
- Any merge would be a pain (or maybe developers wouldn’t even see that their colleagues were modifying the files before they save the changes). You stated that “it’s rare that the same project is worked on by two programmers,” but rare doesn’t mean never, so merges would occur sooner or later.
- A backup every fifteen minutes means that developers may lose up to fifteen minutes of work. This is always problematic: it’s hard to remember exactly what changes were done meanwhile.
A real version control ensures that you can always revert to the previous commit; this is a huge advantage. Reverting a backup using your system would be slightly more difficult than doing a one-click rollback, which you can do in most version control systems. Also, in your system branching is impossible.
There’s a better way to do version control, and you should certainly consider changing the way you currently do it.
Find more answers or leave your own answer at the original post. See more Q&A like this atProgrammers, a question and answer site for professional programmers interested in conceptual questions about software development. If you’ve got your own programming problem that requires a solution, log in to Programmers and **ask** a question (it’s free).