Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 294610

Summary:	'Replace with Revision' action fails if svn:needs-lock property is set
Product:	[Technology] Subversive	Reporter:	Stefan Sperling <stsp>
Component:	Core	Assignee:	Igor Burilo <igor.burilo>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Stefan Sperling

2009-11-09 09:46:50 EST

User-Agent:       Mozilla/5.0 Firefox
Build Identifier: M20080221-1800

The 'Replace with Revision' operation can error out if files in the working
copy are marked 'read-only'.

The code exports files from the repository to a temporary area, and then
copies those on top of the files in the working copy. This fails if files
in the working copy are read-only, e.g. due to requiring a lock (i.e. they have the svn:needs-lock property set) but being in unlocked state.

Subversive should ensure that the destination is indeed writable before copying
a temporary file on top of it.

Reproducible: Always

Steps to Reproduce:
Set up a project containing a binary file 'file1.bin' with the property svn:needs-lock.
This will cause Subversion to mark the file as read-only, unless the file
is locked. Commit the file to create revision 1.

Do several unrelated changes, such as adding a new file 'file2.txt'
(does not need properties set on it), committing the file, creating revision2,and delete the file again, creating revision 3.

Now, with file1.bin unlocked(!), with your project updated to the HEAD
revision (r3), try:
 Right click on the project's working copy root
-> Replace With
-> Revision or URL ...
 Pick "[x] Revision", enter revision 2 (i.e. HEAD - 1)
 Answer 'Yes' to the "Are you sure ..." prompt.

The operation will start, and an error will be reported:
"Replace with Revision operation failed
SVN: 'Replace' operation finished with error: file1.bin (Access is denied)"

Comment 1 Igor Burilo

2010-05-07 10:11:33 EDT

> Subversive should ensure that the destination is indeed writable before copying a temporary file on top of it.
From one side, adding such a verification will require to check properties on every file, which for big working copies can take much time. From the other side, if replace operation fails because of locks on files, you can always revert all changes.

Comment 2 Stefan Sperling

2010-05-07 10:51:54 EDT

The property check does not need to be done for every file (and even if, I'd rather have a feature that works well but performs less well than a feature that does not really work).

What about doing the property check inside a handler of the "access denied" exception, and if the svn:needs-lock property exists on the file, tweak file permission to writable, and do the copy?

I don't recall the details, but assuming the copy transfers properties correctly (I hope it does), check for the svn:needs-lock property again (the old version of the file might not have it), and if the svn:needs-lock property is still present, make the file to read-only again.

I don't understand how reverting changes will help here. There are no local changes in the working copy being replaced with the state of another revision.

Comment 3 Igor Burilo

2010-05-17 05:07:03 EDT

I think it's quite complicated what you proposed also taking into account that using locks in SVN isn't widely used.
The solution I proposed is: run replace action, if you have error because some file needs locking you revert all changes (if needed), lock that file and run replace action once again.