Create a working copy.

The checkout operation is used when you need to make a new working copy for a repository that already exists.

A working copy is a copy used for, er, working.

A working copy is a snapshot of the repository used by a developer as a place to make changes. The repository is shared by the whole team, but people do not modify it directly. Rather, each individual developer works by using a working copy. The working copy provides her with a private workspace where she can do her work isolated from the rest of the team.

The life of a developer is an infinite loop which looks something like this:

Let’s imagine for a moment what life would be like without this distinction between working copy and repository.  In a single-person team, the situation could be described as tolerable.  However, for any number of developers greater than one, things can get very messy.

I’ve seen people try it.  They store their code on a file server.  Everyone uses network file sharing and edits the source files in place.  When somebody wants to edit main.cpp, they shout across the hall and ask if anybody else is using that file.  Their Ethernet is saturated most of the time because the developers are actually compiling on their network drives.

With a version control tool, working on a multi-person team is much simpler.  Each developer has a working copy to use as a private workspace.  He can make changes to his own working copy without adversely affecting the rest of the team.

The working copy is actually more than just a snapshot of the contents of the repository. It also contains some metadata so that it can keep careful track of the state of things.

Let’s suppose I have a brand new working copy.  In other words, I started with nothing at all and I retrieved the latest versions from the repository.  At this moment, my new working copy is completely synchronized with the contents of the repository.  But that condition is not likely to last for long.  I will be making changes to some of the files in this working copy so it will become newer than the repository.  Other developers may be checking in their changes to the repository, thus making my working copy out of date.  My working copy is going to be new and old at the same time.  Things are going to get confusing.  The version control tool is responsible for keeping track of everything.  In fact, it must keep track of the state of each file individually.

For housekeeping purposes, the version control tool usually keeps a bit of extra information with the working copy.  When a file is retrieved, the VCS stores its contents in the corresponding working copy of that file, but it also records certain information.  For example:

This stuff is stored in the administrative area, which is usually one or more hidden directories in the working copy.  Its exact location depends on which version control tool you are using.