Description Neels Hofmeyr 2011-08-04 07:59:19 EDT

Build Identifier: 20110615-0604

If a file is locked (i.e. svn:needs-lock is set, so the WC file is read-only in the locked state), and if this file is part of a replace-with-revision operation, and if furthermore the current file content is *identical* to the content that should replace it, an Exception interrupts the operation.

This is a trivial situation: For example, a user chooses to roll back to, say, HEAD minus 1. Say only two or three (unlocked) files have changed, but here and there are a few binary files, with svn:needs-lock set, scattered around the working copy. The revision that should be rolled back has no modifications to any of those locked files, so they could simply be skipped altogether. If the user chooses 'Replace with revision', this is what currently happens:

- Subversive downloads the same binary file(s) from the repos (export to temp)
- Subversive tries to copy the downloaded file over the current WC file
- the current file is locked and read-only, the copy fails on fs level (Permission Denied).

This failure is completely unnecessary, as the locked files are not supposed to change at all anyway. If it weren't for the lock, they would merely be overwritten with identical content.

(If the files were different, the user should have to lock the files first and then do the replace with revision. But for non-changing files, this is annoying.)

There is a workaround, which is to use a single-URL reverse merge instead. But this is more complex to figure out for non-Subversion-proficient users. Ideally, the replace-with-revision should actually invoke a reverse merge, as this would also correctly treat all file properties and be more optimal, as unchanged file content is not even downloaded from the server.

But changing this behavior might have unwanted side effects and is harder to code. Instead, I've found a "dirty hack" kind of fix that discards exceptions that happen on files that are anyway identical (will attach).

Note that this is related to bug #294610, but this bug report is about *unmodified* locked files, while #294610 talks about any locked files in general.
( https://bugs.eclipse.org/bugs/show_bug.cgi?id=294610 )


Reproducible: Always

Steps to Reproduce:
1. First, create a simple testing repos. Here is a unix shell script:

svnadmin create /tmp/repos
svn co file:///tmp/repos /tmp/wc
cd /tmp/wc

# create a trivial text file
echo x > textfile
svn add textfile

# create a trivial binary file (simply copy the basename binary)
# and set it to needs-lock.
cp `which basename` binfile
svn add binfile
svn ps svn:needs-lock y binfile

svn ci -m"Files created"

# add a mod on the text file
echo y > textfile
svn ci -m"textfile mod"

2. Checkout the entire repos in Subversive.

3. Right-click on the working copy root ("repos") and choose
   Replace with --> Revision or URL

4. Choose Revision, enter number 1. 

5. Click OK and say yes, you really want to replace.

6. An error occurs complaining about Permission Denied on binfile. binfile is not supposed to change at all, there is only this one revision of it in the repos.