Page 146 -

Check Out Code into a Working Copy
Before a Subversion repository can be accessed, it must be checked out. Checking out a
repository simply means retrieving a snapshot of the repository and copying it to the
user’s local machine. The repository is not altered in any way when files are checked out.
The local copy of the repository is called a working copy. This is the core of the copy-mod-
ify-merge model: any changes that the user needs to make are done in the working copy,
which must be brought up to date before it can be checked back in. *
Everybody gets their own working copy; one person can have any number of working
copies. When files are checked out from a repository, the Subversion client creates a new
working copy for those files. Usually a programmer will check out only one copy of a
given directory or tree at a time, but there are occasions when a programmer will have
several working copies that contain different snapshots of different parts of the repository.
(Only directories or trees can be checked out—Subversion does not allow a programmer
to check out a single file in a directory.)

There can be many working copies of the same code, even on the same machine. Each
working copy keeps track of both who checked out the files and when they were checked
out. The user can retrieve the differences between the working copy and the revision that
he had originally checked out at any time, even if the user’s machine does not currently
have access to the server from which the working copy was checked out.

Additionally, a programmer can check out all of a repository, or just part of it. The check-
out can include a single folder or an entire branch including all subfolders. (It can also
include the entire repository, but in Subversion this is almost never done, because it can
cause an enormous amount of data to be retrieved.) When the files are checked out, the
latest revision of each file is copied to the working copy. When the programmer looks in
the working copy, she sees all of the files and folders that she checked out, plus another
hidden folder called .svn. This folder contains all of the data that Subversion uses to check
for differences and to keep track of the state of the working copy.
The programmer edits the files in the working copy, and, when she is satisfied that the
files in the working copy are ready, she can commit them back to the repository. It is only
during the commit that the repository is updated to look like the working copy. The com-

mit is the step that the programmer takes to finalize the changes and integrate them back
into the source code stored in the repository. When someone commits changes to the
repository, Subversion updates only those files that have changed since the working copy
was checked out. Once changes have been committed, they will be accessible to anyone
looking at the repository.

* Some people refer to this as the sandbox model—each person gets to play in his own sandbox, and
only has to clean up later when it’s time to merge the code back. They will often refer to Subver-
sion’s working copy as a sandbox.

138 CHAPTER SEVEN