Version control is essentially a software that maintains a repository of multiple versions of files. Version control is needed not just for programmers, not just for researchers in science or engineering but for any one who needs to write a document that is going to be updated. If you are collaborating with somebody else then version control is a must. But even if you are not collaborating you need version control because too often you want to undo some changes and revert to a previous version. In short if you save a document that you are going to improve upon you must use version control. Kalid gives a good introduction to version control software from a user’s perspective.
There are two types of version control: distributed and centralized. A Distributed Version Control System (DVCS) duplicates the entire repository on each user machine (workspace). The centralized version as the name implies keeps one repository and the users pick and choose the files they want on their computers. A large organisation like say Microsoft would use a centralized repository. But a small company is better off with DVCS, although the meaning of ‘small’ is changing rapidly with improvements in the size and cost of hard disks. The only catch is that ease of use is better for centralized version control. Kalid suggests “to start with Subversion, get a grasp for team collaboration, then experiment with a distributed model.” Subversion is used as an example centralized version control, although I would recommend Perforce.
Perforce is a centralised version control software and can be hosted in house. It is free for small teams or projects (twenty users and twenty workspaces). It is pricey if you want to scale up but if you must scale the productivity gains will hopefully outstrip the cost. If you can get away with bragging “I am the least technical person,” you need Perforce. But for the rest of us who cannot afford that luxury, an application like Git, Mercurial , Fossil or Subversion is better. These are not easy to use although on Windows, a software called Tortoise greatly eases the pain. There are other Graphical User Interfaces for these repositories that are good too. There are good introductions for each of these products on Wikipedia.
If you need to collaborate with remote users there are a few options. Bitbucket (now run by Atlassian) provides free private Git or Mercurial workspaces for five users and a paid version for more than that. Both Git and Mercurial are distributed version control systems. Mercurial is supposed to be better from a ease of use perspective. But Git was established earlier and software developers are better off with Git as there are already a large number of repos using Git. Another good DVCS (Distributed Version Control System) is Fossil which came from the creator of SQLite. It is a good software that it is not widely used. If you do not depend on Github or any other service provider I would recommend it.
Another option if you want to use Perforce without the hassle of set up is to use a commercial version control hosting website like Assembla (https://www.assembla.com). However you must be prepared to see Assembla stop providing the service as there is no guarantee that they will not change their terms of contract. Usually, such companies, give you time to download your existing repositories.
Yet another possibility is to use Amazon EC2 cloud services. This essentially means that you hire a server preferably Linux based, on the Amazon cloud. (The usage charges are in realm of cents per hour of usage rather than dollars for small teams) Then you install whatever software you want. This is useful if your team is distributed or if you do not use the service often and hence would like to save on additional hardware.