Version Control Software

When projects require several developers (i.e. designers, developers, html coders, etc), they may run into situations where multiple people try to edit the same file at the same time. This could be problematic, since one developer could easily overwrite another's work.

To prevent one person from overwriting another's work, most teams of coders use version control software. Version control software allows multiple people to simultaneously work on the same files while not overwiting each other's work.

Subversion is probably the most popular version control software:
http://subversion.tigris.org/

CVS is an older version control software. Subversion considered to be the better successor to CVS.
http://ximbiot.com/cvs/wiki/

For our intents and purposes, they are equivalent. There are a few simple concepts for using Subversion or CVS:

The Repository
CVS and Subversion use a type of client/server architecture. The permanent location of all files is on the server, in what is called a Repository. The Repository has the current version of all files, as well as all the older versions of the files. It keeps a permanent record of any changes to the project. Clients can always get the latest copy of the files by copying them from the Repository. So developers generally make changes to files on their local machines, and then upload them to the Repository so that other developers can get the lastest version of the files.

The Client
Your local computer runs a Subversion client that automates the common tasks that you will need to do when using version control. The recommended client for Windows is TortoiseSVN. For Mac, you should check out the client recommendations on the subversion site.

Working Copies
When a developer downloads the latest copy of the files from the Repository, they are placed in what is called a Working Copy. This is exactly what it sounds like - a copy of the original files that a developer can use to work. Once a developer has finished working on them, she has to then upload them back to the Repository so other developers can see the changes.

Updating
To get the latest copy of files from the Repository, a developer runs a command called Update. This automatically downloads the latest files from the Repository.

Committing
When a developer has finished making changes to her Working Copy of the files, she first runs the Update command to make sure that nobody else has modified the same files she is about to upload, and then runs a Commit command that automatically uploads the changed files to the Repository.

Conflicts
When two developers have modified the same files at the same time, and then they both Commit their changes, the second developer to commit his changes will experience a Conflict. Usually the work the developers have done is in different parts of the file, so Subversion or CVS can automatically merge the two versions together. However, in some cases Subversion and CVS cannot figure out how to merge the two versions of the file, so it asks one of the developers to manually merge the two. Subversion will show you the difference between the two files, and you can usually easily see what has to be done to get the two versions to merge correctly.