Re: svn.collab.net is now running Subversion 0.23.

Branko ÄŒibej <brane@xbc.nu> writes:

> Here's another beauty. I thought that had been fixed?
>
> Updating:
> U wcstress.2708\trunk\bar1\foo1
> G wcstress.2708\trunk\bar1\foo2
> G wcstress.2708\trunk\foo2
> G wcstress.2708\trunk\bar2\foo2
> Updated to revision 741.
> Committing:
> svn: A problem occurred; see later errors for details
> svn: Commit succeeded, but other errors follow:
> svn: Access is denied.
> svn: Error bumping revisions post-commit (details follow):
> svn: svn_io_file_rename: can't move 'r:/wcstress.2708/trunk/bar2/.svn/tmp/entries' to 'r:/wcstress.2708/trunk/bar2/.svn/entries'

Does this fail because of permissions, or because the destination
already exists, or what?

It's very odd, all the commits by stress.pl are more or less the same,
and there doesn't appear to be anything pathological about the
filenames in this commit. For a failure like this I would expect
nearly every commit to be affected. Perhaps there is a filesystem
race somewhere?

Did the previous commit by this instance of the script succeed or
fail? If it failed, did that leave the working copy in a state that
caused the above failure? If you run a single instance of stress.pl
(use -n to increase the number of commits) then there should be no
conflicting commits and so every commit should succeed, does the
problem still occur?

> Sending wcstress.2708\trunk\bar1\foo2
> Sending wcstress.2708\trunk\bar2\foo1
> Sending wcstress.2708\trunk\bar2\foo2
> Sending wcstress.2708\trunk\foo2
> unexpected commit fail: exit status: 256

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org