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.

1. 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.

2. Blame is extremely hard to do with your approach.

3. 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.

4. 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.

5. 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.

6. 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.

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.

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.

In a professional environment where there is code written you should always have source control.

There is always the danger of an interview candidate asking what you use for version control and refusing the position because of the lack of a reasonable version control system.

Also… if you happen to be able to hire a professional they might also have a lot harder time understanding and using your current versioning environment.

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.