What are the uses of svn copy?

Question

Example:

$ svn copy foo.txt bar.txt  
A    bar.txt

• When would you use this technique, and why?
• Will this command (taken from svn's "red book") creates a copy of <foo.txt> while preserving the history of it to be shared with <bar.txt>?
• If I'm changing <bar.txt>, what will happen to <foo.txt>?

What are the equivalents to this in other modern systems (Clearcase, Accurev, Perforce)?

Let me emphasize the point I'm searching for:
Is this kind of branching out on a file level?
What happens if you use it in the same branch, i.e. create a copy of a file and than start changing that new file. all in the same branch?
I understand that it is also used for tagging but what is interesting me is what to expect when performing <svn copy> on the file level.

Answer 1

Aside from branching/tagging, you can also use it when you split a file in two. In this case both new files will have history and you'll be able to look at the code before the split.

BTW: that's one of few features that SVN has, but Git doesn't (Git will try to guess origin of code after the fact, especially if you add -C to commands).

Answer 2

When would you use this technique, and why?

To create tags, and also to create branches, although usually you'd use it on a directory rather than a single file. A tag is a copy of one or more files, which you keep for convenience but never change again. A branch is a copy of one or more files, which then evolves separately from the original

Will this command create a copy of foo.txt while preserving the history of it to be shared with bar.txt?

Not quite, foo.txt's history will effectively be copied to the history of bar.txt, then an extra entry appears in the history of bar.txt indicating that it was copied from foo.txt, and thereafter they are independent. So the history up to the point of the copy is identical/shared.

If I'm changing bar.txt, what will happen to foo.txt?

Nothing, they are completely separate. But you can later merge changes from one to the other.

Answer 3

This is a slightly unusual use, but I find that sometimes I have to divide a source file into two separate files - for example, if it contains two sets of unrelated functionality, and I use svn copy to do this. I then modify both files and delete the inappropriate bits from each. This way, both of the new files retain revision history for their relevant bits.

Answer 4

What are the equivalents to this in other modern systems (Clearcase, Accurev, Perforce)?

git will notice the file is the same on a plain copy and show it as a copy.

Answer 5

I use this technique when I'm creating a new file, and I want to copy scaffolding (I currently use Perforce, but used to use Subversion). Changing a copy will not effect the other file.

Answer 6

Branch is not a first-class citizen in Subversion, since it is "implemented" as a directory.

Hence, the svn copy allow to kind of branch of file within the same branch (directory). You can later merge back the copied file into the first. But this is ill-suited for just one file, as mentionned in this thread

The equivalent in ClearCase would be a select rule like

element * .../myBranchForCopy/LATEST
element /myPath/myFile /main/myBranch/LATEST -mkbranch myBranchForCopy

However, in this view made for branching a file, you will only see one foo.txt at a time (either in the myBranch, or if it is checked-out, in the myBranchForCopy). There is no real "copy", it is the same element. Any merge would be between:

• foo.txt@@/main/myBranch/myBranchForCopy/LATEST
  and
• foo.txt@@/main/myBranch/LATEST

Answer 7

svn copy came in handy after I inadvertantly deleted a file. See the anwer to an accoring question I have asked.