Using a code repository can save a lot of time during development and deployment to a staging or production server.  Commonly used among many developers working on a codebase, each developer can work on different parts of the code, and when finished, commit to a central repository.  Subversion and CVS take away the pain and frustration of merging the different files and code among developers and makes resolving conflicts less painful.

Though it works well in a team environment, using a repository for your own projects is beneficial.  Everyone is reminded frequently to backup their files often, yet the task is avoided because it can take time and cause frustration trying to figure out what version is which and what files have been changed.  Having a “one-click button” that does it for you is rarely frustrating and makes backing up code quick.

Once you commit code, reverting back to a previous version is easy.  This makes experimenting with code a little less challenging if you change your mind midway through a change.  When something completely breaks and you don’t know where, going back to a version where you know it worked can save a lot of time.

Every developer has made a foolish mistake and has written over a file by accident.  The second this mistake is made, the developer realizes it and head banging can occur.  If there is no undo in an editor, the file is pretty much gone for good.  If the file is in the repository, a simple revert will get it back.

A repository is also very helpful in deploying an application.  When you know you have a working version, you can check out a copy and release it on a staging or production server.  Pushing out new updates only requires an update.  Again, no more trying to figure out which files were changed or added and missing that one critical file.

While there are more advanced issues with repositories that come up when working with a team or branches for example, repositories allow you to keep track of changes without manually tracking each change when you make it.