"svn cleanup" fails because it can't find a temp file

[Dave Huang]

I tried to roll back some changes to a file by doing a reverse merge,
but I had the file in question open and locked, so svn wasn't able to
complete the merge. However, this has left my working copy broken and
unrecoverable :( (I know I can do a clean checkout, but that's creating
a new WC... the old one remains unrecoverable by normal means).

Pretty much any operation on the WC, such as "svn log", fail with: svn:
E155037: Previous operation has not finished; run 'cleanup' if it was
interrupted

But "svn cleanup" doesn't work because: svn: E720002: Can't open file
'C:\Users\Dave\AppData\Local\Temp\svn-C09EC58D': The system cannot find
the file specified.

It's true that the file it's looking for isn't there, but why does it
expect it to be there? It's in the Temp directory, and svn shouldn't
expected things in there to stay around between different invocations of
svn. That said, I didn't delete it myself--I assume svn must've deleted it.

The .svn/wc.db's WORK_QUEUE table contains:

3399|(file-install Data/DemoCA.zip 1 0 1 0
C:/Users/Dave/AppData/Local/Temp/svn-C09EC58D)
3400|(sync-file-flags Data/DemoCA.zip)

Data/DemoCA.zip is the file I was trying to reverse merge. I deleted
those two rows and was able to do a "svn cleanup", but manually messing
with the wc.db doesn't sound like a good idea.

So, why does "svn cleanup" fail if a temp file can't be found, and can
something be done to remove that requirement? As I mentioned, I don't
think svn should depend on temp files being persistent.

This is with svn 1.7.5 on Windows 7.

[Johan Corveleyn]

This reminds me of this recent discussion:

http://svn.haxx.se/users/archive-2012-06/0074.shtml

In that case, a file-in-use was also blocking the completion of an
'update'. But there, the cleanup did work, and the user could continue
(the discussion was more about why 'cleanup' was needed at all in this
case, which is a bit of another issue). So maybe your problem is only
happening with 'merge'.

I think you should file an issue for the unrecoverable working copy
after a "blocked by file-in-use" reverse-merge (maybe also for a
normal merge?). It would be nice though if you could come up with a
nice reproduction recipe, starting from a clean repository (see here
[1] for a template for a reproduction script).

[1] http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs

--
Johan

[Philip Martin]

Johan Corveleyn <jco...@gmail.com> writes:

> I think you should file an issue for the unrecoverable working copy
> after a "blocked by file-in-use" reverse-merge (maybe also for a
> normal merge?). It would be nice though if you could come up with a
> nice reproduction recipe,

Just about any merge will do. repos_diff.c:get_file_from_ra passes NULL
when calling svn_stream_open_unique and that causes the system temporary
dir to be used--we should be passing the .svn temporary dir. (We should
probably continue to pass NULL if this is a diff, rather than a merge,
since the working copy might be read-only.)

--
Philip

[Johan Corveleyn]

Ok, so IIUC if 'merge' would use the internal .svn temporary dir this
would be fixed, right? Because we can assume that things won't
suddenly dissapear from .svn/tmp, even between invocations -- and if
they do, something/someone has messed with svn metadata internals,
which isn't allowed (except if you *want* to corrupt things of course
:-)).

Makes me wonder: what if some crap stays behind in .svn/tmp (for
whatever reason -- I just checked my working copies, and in one of
them there are two old svn-XXXXXX files in the tmp dir). Does cleanup
clean those up (after it has verified that they are not needed
anymore)?

--
Johan

[Philip Martin]

Johan Corveleyn <jco...@gmail.com> writes:

> Makes me wonder: what if some crap stays behind in .svn/tmp (for
> whatever reason -- I just checked my working copies, and in one of
> them there are two old svn-XXXXXX files in the tmp dir). Does cleanup
> clean those up (after it has verified that they are not needed
> anymore)?

cleanup_internal calls svn_wc__adm_cleanup_tmp_area.

--
Philip

[Johan Corveleyn]

Ok, cool. Just tested it on that working copy, and indeed the old temp
files are removed.

Strange though: during svn cleanup I had "Windows Explorer" open on
the .svn/tmp dir, and I could see a couple of new svn-XXXXXX being
created and removed while svn cleanup was running. Why would 'svn
cleanup' create svn-XXXXXX files (and remove them shortly after)? I'm
pretty sure the work_queue was empty so that can't be it. Maybe during
the removal of unused pristines or something?

--
Johan

[Bert Huijben]

Other part of this problem: shouldn't the install operation be ignored if
the to-be installed file cannot be found?

The workqueue operation should be restartable, which it won't be if the file
is already moved, but some later operation (like obtaining the timestamp)
fails.

Bert

[Bert Huijben]

The most likely cause for this issue (svn merge applying a 'trivial' merge),
is now fixed on trunk and the fix is nominated for backport in r1361119.

The less trivial merges already had a similar code path that 'fixed' this
problem.

Bert