Is svn copy cheap when not done in the repository?

Question

If I do an svn copy using two urls, I get a 'cheap' copy in the repository...

svn copy http://repo_url/trunk http://repo_url/tags/release_foo

But what if do the copy in the working directory and then commit it like this...

svn copy trunk tags/release_foo
svn commit tags/release_foo

The copy creates local copies of the files which are automatically svn added. They only go into the repository when committed.

The examples in the doco always seem to use the url to url copy for tagging or branching but I couldn't find anything that explicitly states that you should not use WC to WC followed by a commit.

So are these two methods the same? Do both create a cheap copy inside the repository?

Answer 1

I believe that a url copy and a WC copy are pretty much the same thing when it comes to being "cheap". In your WC any copy that is made isn't a copy like copying a file on a file system.

svn is smart in that it basically creates some soft links from the origin to your new tag, branch or whatever.

Answer 2

Don't do this:

svn merge <local copy>/branch <local copy>/trunk

Your commands like this, can be similarly troublesome:

svn copy trunk tags/release_foo
svn commit tags/release_foo

While copying in a local working copy is fine, but these commands make it look like you've checked out the entire repository into a single working copy. I had someone do this and we ended up having to delete trunk and copy it from a previous revision. Unforutnately, I don't remember the details of what boxed us into that corner. I do remember, things go south very quickly when you try to do merges between branches on "local" directories.

Always use repository URLs for creating/managing/merging tags and branches. It's safer. It guarantees your working copy isn't out-of-date for creating the tag/branch and also guarantees the creation is transactional.

I think the problem may have happened like this:

1. Person A updates their mass everything working copy
2. Person A makes some tags, does some branches, does some merges, but has not committed, yet.
3. Person B commits some changes to the source of those tags, or the branch that was merged.
4. Person A tries to commit and svn won't let them.

Again it was a number of years ago, so I don't remember the specifics, but there isn't really a good reason to set your working copy up like that.

Answer 3

When you do the copy locally, you will of course incur a space and time cost from copying the files on your local machine (your local filesystem doesn't know about SVN deltas), but when you go to commit, you should see that only the root of the copied directory structure is listed as added (with history). It will thus create the "cheap" copy on the server when you commit.

That said, the URL copy method is generally preferred for branching or tagging because it doesn't require you to have checked out the repository root (including all branches and tags -- this would be huge!). The normal use case is to branch/tag server-side (using the URL copy), then check out the branches/tags on an as-needed basis for your work.

If you're just copying a file or folder within your working copy for some reason (say you're breaking one class file into two and you want to preserve the common history), then just use svn copy in your WC.