Most of the time, you will want to start using SVK by creating a mirror of a remote Subversion repository containing your project. Mirroring a repository creates a copy of it on your local machine. This copy contains as much of the original history of the Subversion repository as you want. For this example let's mirror everything:
$ svk mirror svn://svn.clkao.org/svk //mirror/svk Committed revision 1. $ svk sync //mirror/svk Retrieving log information from 1 to 1281 Committed revision 2 from revision 1. Committed revision 3 from revision 2. … Committed revision 1282 from revision 1281.
When mirroring a project you will have the choice between mirroring just trunk or the branch you are interested in as opposed to the entire project. In most cases you will want to mirror the entire project tree including the trunk, branches and tags directories. Since branches and tags are cheap copies on the remote server the mirror will also store them as cheap copies and thus not use significantly more disk space.
If you choose not to do this and mirror just a single branch or trunk, and you later decide you need access to other branches or tags in the remote repository, separately mirroring those will cause you local depot to contain disjoint mirrors of the individual branches and tags, and copies that were originally cheap copies in the remote repository will become full blown copies in your local depot. In addition you might run into problems with merge tracking across remote branches.
Creating a mirror of a large Subversion repository can take quite a while. However rest assured that once you have the mirror keeping it up to date is very fast. We will also discuss several ways to speed up getting an initial mirror on a large number of machines, see ##TODO.
Now that we have a mirror of the Subversion repository in our depot we are ready to create a working copy:
$ svk checkout //mirror/svk/trunk Syncing //mirror/svk/trunk(/mirror/svk/trunk) in /Users/sally/trunk to 1282. A trunk/utils A trunk/utils/extract-docs A trunk/utils/extract-message-catalog A trunk/utils/svk-ediff.el A trunk/SIGNATURE A trunk/pkg …
Although the above example checks out the trunk directory, you can just as easily check out any deep subdirectory of a depot by specifying the subdirectory in the checkout DEPOTPATH:
$ svk checkout //mirror/svk/trunk/lib/SVK/Command Syncing //mirror/svk/trunk(/mirror/svk/trunk) in /Users/sally/Command to 1282. A Command/Propdel.pm A Command/Checkout.pm A Command/Revert.pm A Command/Cat.pm …
Since SVK uses a “copy-modify-merge” model instead of “lock-modify-unlock” (see Chapter 2, Basic Concepts), you're already able to start making changes to the files and directories in your working copy. Your working copy is just like any other collection of files and directories on your system. You can edit and change them, move them around, you can even delete the entire working copy and forget about it—though you should run svk checkout --detach to let svk know you removed it.
While your working copy is “just like any other collection of files and directories on your system”, you need to let SVK know if you're going to be rearranging anything inside of your working copy. If you want to copy or move an item in a working copy, you should use svk copy or svk move instead of the copy and move commands provided by your operating system. We'll talk more about them later in this chapter.
Unless you're ready to commit a new file or directory, or changes to existing ones, there's no need to further notify the Subversion server you mirrored from that you've done anything.
While you can certainly check out a working copy with the DEPOTPATH as the only argument, you can also specify a directory after your DEPOTPATH. This places your working copy in the new directory that you name. For example:
$ svk checkout //mirror/svk/trunk svk Syncing //mirror/svk/trunk(/mirror/svk/trunk) in /Users/sally/svk to 1282. A svk/utils A svk/utils/extract-docs A svk/utils/extract-message-catalog A svk/utils/svk-ediff.el A svk/SIGNATURE …
That will place your working copy in a directory named
svk instead of a directory named
trunk as we did previously.