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 a third 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?

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

16

Eh? It sounds as though you have version control, albeit a non-standard implementation of it.
–
TelastynJan 3 '14 at 14:25

5

@StephenCollings: MainMa's answer tells you a couple of reasons why its better to make logical commit groups, with log entries describing what was changed, and an automatic log of who did some specific change, and a guarantee that each commit corresponds to a working build. The only drawback is that you will have to get your team to change their accustomed behaviour to make them work with the version control system as they should. That will probably mean to kick some asses (including your own). Once you have educated your team, the benefits will show up by themselves.
–
Doc BrownJan 3 '14 at 15:32

Heck, I use a proper version control system for my personal (so far tiny) hobby projects! About the only situation in which I won't use it is for more or less one-off things that I write, run, and throw away. Anything more than that pretty much deserves a proper VCS in my opinion. Whether you use centralized or distributed (SVN vs Git), manufacturer-specific or generic (TFS vs SVN), and so on, is a matter of taste.
–
Michael KjörlingJan 3 '14 at 20:01

7

Your assumption that it is "trouble" to set up proper version control is problematic; it sounds to me like your hacked-together version control system is a lot more trouble to maintain than the few minutes it would take to set up a proper free or purchased version control system.
–
Eric LippertJan 4 '14 at 15:56

7 Answers
7

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 who is hard too. Version control logs, the list of changed files and a diff is 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

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.

With source control you can have meaningful commit messages. With backups all you know is that it was x minutes since last backup.

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. Especially since, like Eric Lippert mentions, your current system is probably a lot more painful to maintain than any common version control system is. Having a Git or Mercurial repository on a network drive is pretty easy for example.

Note: Even if you switch to a common version control system, you should still have a daily/weekly backup of the repositories. If you're using a distributed system it's less important though, since then every developer's working copy is also a backup.

I'll bet with this team, if two devs worked on the same file, one of the files would get thrown in the trash. "Hey, you didn't make a lot of changes did you? I really need to keep mine."
–
JeffOJan 3 '14 at 14:48

9

Merges also happen with the solo developer when the developer wants to go back to some previous point (a release), fix a bug in production, and then later move the longer living feature code into production.
–
MichaelTJan 3 '14 at 15:03

4

A slight bit of semantics... Not all commits require that the application will build properly. Often it's far from truth. Commits to the main branch should usually build, but most people I know will often commit to a specific branch anythime they feel something meaningful was accomplished. Then they have records and more detailed (meaningful) differences that can be reversed.
–
Jacobm001Jan 3 '14 at 17:34

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.

Version control was always needed, even before you hacked together your "but, we backup really often!" kludge.

Version control lets you publish those 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, metadata, and of 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.

+1 for stating that version control was always needed.
–
ChuckCottrillJan 3 '14 at 18:00

I just experienced a good example of the fearlessness yesterday. I wasn't sure about a choice I was making, so just created branches and implemented the idea and an alternative. I was free to compare multiple solutions and then choose the best path. I probably wouldn't have tried this if I had to jump through the hoops of a hackier solution than git or another VCS.
–
velotronJun 14 '14 at 20:06

There is a great deal of value in using version control even as an individual developer and it could be quite a bit simpler than the backup/file copy based system you have now.

Right now, you have the ability to get to older version of the code, but how do you find the version you want?

Just the ability to do a diff between revisions will be very valuable. Integration with development tools is another benefit you aren't getting from you current tools.

Another substantial benefit is the ability to branch, and experiment with new features or designs without having to worry about breaking anything.

As was mentioned in other responses, the ability to intentionally commit the code that you want to share with others is substantially different than just saving all versions of the code at 15 minute intervals. You are no doubt saving off multiple non-working versions of code that you or others will later need to dig through to find the previous good version that you actually need.

It is pretty simple to get a version control system up and running,
particular in an environment as straightforward as this one. So the investment required isn't very high. As I mentioned, the backup based system you have now sounds like it could be needlessly complex and potentially fragile. You should benefit from the years of investment the community has made in building tools like SVN, Git, or Mercurial to solve exactly the problem of maintaining multiple versions of the software and providing a good deal of additional capability that is directly useful to developers.

By setting up and using using formal version control, you will develop a valuable set of skills that will serve you well throughout your career. Almost every professional software development environment uses a version control system. Knowing the ins and outs of how to set up and use a repository will help you over an over again.

I am not familiar with Mercurial, but from what I understand, it is a full blown revision control system. If you already have some familiarity with it, it might be worth starting to experiment with it as a VCS.

This is very weak. It is unlikely that a shop does not need version control, but if a shop truly does not need version control and a candidate refuses to work for a shop without version control, then it probably is not a good match. That being said, I don't believe in the existence of shops that don't need version control.
–
emoryJan 5 '14 at 1:13

Good point but I'd say these days source control is just as beneficial on non-professional environments as well.
–
joshin4coloursJan 5 '14 at 22:54

As other people have said, "now" is always a good time to start using version control. There's so many benefits to using a good version control system it's almost a no brainer.

You mention you use Mercurial. Like other distributed vcs, you can always initialize your own (private) repo and work there. Why not try that? If it starts working for you, it might work for your team. DVCS is all about building from the ground up.

Version control really is one of the most critical pieces of a functional development team. Aside from the standpoint that your code is always backed up, you are exposed to features such as commit messages that help you understand exactly what the person before you (or you yourself) did to a particular file. You can also diff files with previous versions and create tags for particular releases. Tags are a HUGE benefit in that you can basically create a snapshot of version x.x.x of your app's source code. This makes tracking down old bugs much much easier.

Start reading up on different platforms and see what suits your needs best. We used SVN because there were tools integrated into our IDE to leverage SVN. Ironically we do not even use these tools now, we just use Tortoise SVN to check in and check out code.

To answer your question, version control is needed from the moment you write your first line of code.