Working Copies You've already read about working copies; now we'll demonstrate how the Subversion client creates and uses them. A Subversion working copy is an ordinary directory tree on your local system, containing a collection of files. You can edit these files however you wish, and if they're source code files, you can compile your program from them in the usual way. Your working copy is your own private work area: Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so. After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands to publish your changes to the other people working with you on your project by writing to the repository. If other people publish their own changes, Subversion provides you with commands to merge those changes into your working directory by tortoisesvn change repository url from the repository. A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, your working copy contains a subdirectory named. The files in this administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work. A typical Subversion repository often holds the files or source code for several projects; usually, each project is a subdirectory in the repository's filesystem tree. In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository. For example, suppose you have a repository that contains two software projects. In other words, the repository's root directory has two subdirectories: paint and calc. To get a working copy, you must check out some subtree of the repository. The term check out may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you. Suppose you make changes to button. However, Subversion does not make your changes public until you explicitly tell it to. The act of publishing your changes is more commonly known as committing or checking in changes to the repository. To publish your changes to others, you can use Subversion's commit command. Now your changes to button. When you commit your change to button. To bring her project up to date, Sally can ask Subversion to update her working copy, by using the Subversion update command. This will incorporate your changes into her working copy, as well as any others that have been committed since she checked it out. Note that Sally didn't need to specify which files to update; Subversion uses the information in the. One day you will find your repository has been subtly corrupted. Revisions A svn commit operation can publish changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents, create, delete, rename and copy files and directories, and then commit the complete set of changes as a unit. In the repository, each commit is treated as an atomic transaction: either all the commits changes take place, or none of them take place. Subversion retains this atomicity in the face of program crashes, system crashes, network problems, and other users' actions. Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered zero, and consists of nothing but an empty root directory. A nice way to visualize the repository is as a series of trees. Imagine an array of revision numbers, starting at 0, stretching from left to right. Global Revision Numbers Unlike those of many other version control systems, Subversion's revision numbers apply to entire treesnot individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit. It's important to note that working copies do not always correspond to any single revision in the repository; they may contain files from several different revisions. However, suppose you tortoisesvn change repository url a change to button. In this example, the text of Makefile is identical in revisions 4, 5, and 6, but Subversion will mark your working copy of Tortoisesvn change repository url with revision 6 to indicate that it is still current. So, after tortoisesvn change repository url do a clean update at the top of your working copy, it will generally correspond to exactly one revision in the repository. Given this information, by talking to the repository, Subversion can tell which of the following four states a working file is in: Unchanged, and current The file is unchanged in the working directory, and no changes to that file have been committed to the repository since its working revision. A commit of the file will do nothing, and an update of the file will do nothing. Locally changed, and current The file has been changed in the working directory, and no changes to that file have been committed to the repository since its base revision. There are local changes that have not been committed to the repository, thus a commit of the file will succeed in publishing your changes, and an update of the file will do nothing. Unchanged, and out-of-date The file has not been changed in the working directory, but it has been changed in the repository. The file should eventually be updated, to make it current with the public revision. A commit of the file will do nothing, and an update of the file will fold the latest changes into your working copy. Locally changed, and out-of-date The file has been changed both in the working directory, and in the repository. A commit of the file will fail with an out-of-date error. The file should be updated first; an update command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a tortoisesvn change repository url way automatically, it leaves it to the user to resolve the conflict.
