Sometimes you may want your “snapshot” to be more complicated than a single directory at a single revision.
For example, pretend your project is much larger than our
calc example: suppose it contains a
number of subdirectories and many more files. In the course
of your work, you may decide that you need to create a working
copy that is designed to have specific features and bug fixes.
You can accomplish this by selectively backdating files or
directories to particular revisions (using svn update
-r liberally) or by switching files and directories
to particular branches (making use of svn
switch). When you're done, your working copy is a
hodgepodge of repository locations from different revisions.
But after testing, you know it's the precise combination of
data you need.
Time to make a snapshot. Copying one URL to another won't work here. In this case, you want to make a snapshot of your exact working copy arrangement and store it in the repository. Luckily, svn copy actually has four different uses (which you can read about in Chapter 9, Subversion Complete Reference), including the ability to copy a working-copy tree to the repository:
$ ls my-working-copy/ $ svn copy my-working-copy http://svn.example.com/repos/calc/tags/mytag Committed revision 940.
Now there is a new directory in the repository,
/calc/tags/mytag, which is an exact
snapshot of your working copy—mixed revisions, URLs,
Other users have found interesting uses for this feature. Sometimes there are situations where you have a bunch of local changes made to your working copy, and you'd like a collaborator to see them. Instead of running svn diff and sending a patch file (which won't capture tree changes, symlink changes, or changes in properties), you can instead use svn copy to “upload” your working copy to a private area of the repository. Your collaborator can then either check out a verbatim copy of your working copy or use svn merge to receive your exact changes.
While this is a nice method for uploading a quick snapshot of your working copy, note that this is not a good way to initially create a branch. Branch creation should be an event onto itself, and this method conflates the creation of a branch with extra changes to files, all within a single revision. This makes it very difficult (later on) to identify a single revision number as a branch point.