A Version Control System tracks and manages changes made to a file or files. A user can commit files, view the history of the file, and allow other users to check out the files. Over the years Version Control Systems have expanded to include a multitude of other features like branching, tagging, being distributed versus centralized, having a client-server setup, etc.
Being able to see the tracked changes of a file comes with many benefits. A novice to the team could find out who created the file or made a recent change to ask them questions. With code, when prioritizing a bug, a user can look at the changes to determine when the bug was introduced. In that same vein, they can even see who introduced the bug and can communicate with them in order to find out what they were trying to achieve thus eliminating the chance of removing a feature when fixing a bug. If something went wrong or if a previous version is preferred a user can rollback or reimplement that change.
A distributed version control system comes with redundancy built in as if the server goes down the clients essentially have backups. When using a centralized version control system, the server can be setup to backup to another server. In either of these cases if a disaster occurs then it is merely a hiccup versus losing everything and having to start over.
Since projects usually involve a team of individuals that need to work together, having a version control system helps with collaboration. Individual team members can be assigned different tasks and can just commit their changes when they are done. As mentioned before with being able to view who made the changes, a novice team member can communicate with veteran team members to find out why things are the way they are.
Most drawbacks are dependent on which Version Control System is in use and are usually documented or come with experience using the system. When choosing a Version Control System, it would be best to do as much research as possible and make sure that everyone that will be involved is fine with the drawbacks and any work arounds that come from them.
Some Version Control Systems require the file to be locked while modifications are being made to it. This can cause issues if a user locks a file then spends a week modifying it blocking any other user from being able to make modifications. A work around would be to make changes to a copy of the file, lock the original file, apply all the modifications, and then unlock the file. Another file locking issue could occur where someone locks the file then leaves the project. A work around here would be for someone with access to the Version Control System, an administrator, to manually go in an unlock the file.
Security is something to be considered when leveraging a Version Control System. If you are using a Version Control System that is hosted by another company, you might want to make sure that your files are not public, unless you want it to be, or that someone who no longer works on the project no longer has access. If you are setting up a server to host a Version Control System then you will want to make sure that the server is secure. When working with a Version Control System that has a client-server or distributed setup then you will have to make sure the client users have their machines secure and follow proper security protocols like locking their computer when they are away.
Not everyone that works on your project, now or in the future, are going to have the same knowledge or experiences. This means that training will have to occur to get everyone up to date on how to use the Version Control System. Depending on the Version Control System, training might come easy or it could prove difficult.
While many Version Control Systems are free and open source, you should always consider cost. If you are planning on hosting the Version Control System yourself then the server hosting it will have a cost. When using Version Control System in a Software as a Service (SaaS) setup, you will want to check if the features you want are free, if there are a certain number of free seats before additional seats come at a cost or if making your project private comes at a cost. Ultimately nothing in this world is truly free and you should make sure you know what the real costs are.
Below are some of the Version Control Systems that I have used in the past with some brief information about them, feel free to look them up to get more information.
Git is currently one of the most popular version control systems available. It is a free and open source distributed version control system that is lightweight and efficient. It promotes branching early and often.
SVN, or Apache Subversion, is the successor to CVS and was originally built to fix the flaws found in CVS, CVS is mentioned below. It supports atomic operations thus removing the issue of a failed commit causing the files on the server from becoming corrupt.
CVS, or Concurrent Versions System, operates as a front-end to RCS or Revision Control System and expands upon it. RCS allows users to revise a document, commit changes and merge them. CVS adds a client-server model in which a server contains the original version of files while a user checks out the files to their local machine, the client, to revise then later commit to the server.
Alienbrain is specialized for art, design and animation teams and can also be used by developers. It is or was the version control system used at my college where our final project involved working with animation and sound students to develop a video game.