I've had a long-standing beef with 'svn cp wc URL'. Specifically, I see users invoking this techique as a
way to make a quick snapshot of the working copy. Then I see complaints about how the tag
"resurrects" files that the user had already deleted.
'svn cp wc URL' builds a repos transaction by walking over the mixed-revs in the working copy; but my
suspicion is that it doesn't report 'deleted' files as missing in the transaction (which is what we do in
updates).
[Philp sez: That sounds probable, until recently 'svn cp wc wc' also failed to
handle 'deleted' items.]
I've long insisted that there was a bug here, and now I have a script to prove it!
--------------------------------------
#!/bin/sh
rm -rf repos wc
svnadmin create repos
svn co file://`pwd`/repos wc
# Add two files
cd wc
touch file1; touch file2
svn add file1; svn add file2
svn commit -m "Add two files and tags dir".
# Put wc at revision 1.
svn up
# Delete file1.
svn rm file1
svn commit -m "Delete file1."
# Change file2.
echo "blah" >> file2.
svn ci -m "Change file2".
# Change file2 again.
echo "blah again" >> file2
# "Gee whiz, I want to make a snapshot of my wc."
# User is ignorant that wc is still at r1 with a 'deleted' file1 entry.
cd ..
svn cp wc file://`pwd`/repos/sometag -m "Tag my wc"
# Now checkout the tag.
svn co file://`pwd`/repos/sometag tagwc
# Hey, look at that! My tag has 'file1' in it!
# But I thought I deleted that file... it wasn't in my wc when I tagged!
Bug
Major