skip to primary navigationskip to content
 

How a working copy works

A working copy and how it works

This information is from TortoiseSVN Help

Working copies

Useful notes about working copies (directories):
  • A Subversion working copy is your own private working area, which looks like any other ordinary directory on your system.
  • It contains a COPY of those files which you will have been editing on the website. You can edit these files however you wish, in the usual way.
  • 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 copy (by reading from the repository).
  • Most importantly, should files get overwritten in anyway, Subversion gives you the ability to retrieve your old version back.
  • A working copy also contains an extra folder: the .svn directory.
    This is created and maintained by Subversion, to help it carry out these commands.
    You should never need to access this area, but you should NEVER delete it either.

A typical Subversion repository often holds the files for several projects.
In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository.

Filesystem with two projects For example, this shows a file system with two subdirectories (or projects):
Calc and Paint:

To get a working copy of these two projects, you would create a copy of the directorie in a private working area, using the command check out

If this was your project and you were to make changes to one of the files, i.e button.c, you publish that file for others to see using the commit command.
The file remains local and private until you run this command.

To update your private working area with files edited by other authors, you use the update command.

Note:
Because you are using Subversion, all subversion commands are prefixed with svn.
i.e.
svn commit
svn update

Repository Revisions

Useful notes about revisions:
  • An svn commit operation can publish changes to any number of files and directories as one single transaction.
  • You can change files' contents, create, delete, rename and copy files and directories, and then commit the complete set of changes as a unit.
  • Each commit is treated as an atomic transaction: either all the commit's changes take place, or none of them take place.
  • 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.
  • Each revision number is a snapshot of the way the repository looked after each commit.
  • Subversion's revision numbers apply to entire trees, not individual files.
    Repository revisions

    An example

    If project Calc is checked out as revision 4, it may contain files:

    calc/Makefile:4
    integer.c:4
    button.c:4

    But if you edit file button.c and commit it, the repository revision is incremented to 5, updating button.c, but the other files remain as revision 4:

    calc/Makefile:4
    integer.c:4
    button.c:5

Working file states

There are four states of a working file:

Remember:
Commit pushes your local file to the repository
Update pulls a Repository file to your working copy)
  • Unchanged and current
      No change to file in working copy     (commit would change nothing)
      No change to file in repository       (update would change nothing)
    
  • Locally changed and current
      File is changed in working copy       (commit would push changes)
      No change to file in repository       (update would change nothing)
    
  • Unchanged and out-of-date
      No change to file in working copy     (commit would change nothing)
      File is change in repository          (update would pull changes)
    
  • Locally changed, and out-of-date
      File is changed in working copy       (commit would push changes)
      File is change in repository          (update would pull changes)