BUG: revert fails on binary files without svn:needs-lock property on Win32

Tested with: TortoiseSVN 1.4.0, Build 7501 - 32 Bit, should be
repeatable on svn command line client also.
OS: Windows XP SP2

Summary: When a file is kept open by other software during
an update and/or revert is not handled gracefully. Without the
svn:needs-lock-property you
might end up with binary files that svn claims to be the latest but
really are not.

Steps to reproduce:

1) create an microsoft excel file and put it to a svn repository (file.xls)
2) make a couple of revisions of it (say revisions 1-10)
3) right click on file in explorer, select "update to revision",
select some old revision like "4"
4) open the file in excel
5) do a svn update on the file
6) you'll get conflict window
7) close the file in excel (keep excel still open)
8) do a svn revert on the file (you'll get an empty dialog saying
"revert finished")
9) see the explorer properties of the file, it'll show that it is the
latest revision
10) rename the file to file2.xls (don't do svn rename, just regular one)
11) do a svn update in the folder so that file.xls gets recreated
12) compare file.xls and file2.xls, they are not the same file

If you have the svn:needs-lock property set on the file, it works bit
differently:

1 - 7) the same

8) you get dialog saying that the revert actually succeeded
9) show the properties on the file, it is the latest revision
10) rename to file2.xls
11) do svn update in the folder so that the file.xls gets recreated
12) compare file.xls and file2.xls, they are the same file

So which one is the correct way?
This was originally reported to tortoisesvn dev-list but was redirected here.

-- 
Jarmo Torvinen
"Even he, to whom most things that most people
would think were pretty smart were pretty dumb,
thought it was pretty smart."  Douglas Adams
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org