Subversion COPY/MOVE - File not found: transaction 'XXX-XX'

I'm attempting to create a branch in one of my subversion repositories and keep running into an error. No mater what is done, I keep getting the following:

File not found: transaction '3062-2e6', path '/Software/XXXXXX/branches/testbranch'

I've noticed that the first part of the '3063-3e6' in the above message is the last successful committed revision in the repository. My apache logs don't give much more information:

[Wed Nov 24 14:10:38 2010] [error] [client x.x.x.x] Could not MOVE/COPY /svn/p070361/!svn/bc/3049/Software/SXXXXXX/trunk.  [404, #0]
[Wed Nov 24 14:10:38 2010] [error] [client x.x.x.x] Unable to make a filesystem copy.  [404, #160013]
[Wed Nov 24 14:10:38 2010] [error] [client x.x.x.x] File not found: transaction '3059-2e2', path '/Software/XXXXXX/branches/testbranch'  [404, #160013]

This is all happening on a server with an nginx frontend that proxies to Apache for the subversion bits. Other repositories are able to branch fine and I was able to create the branch using file:/// from the command line on the server this is occurring on. The permissions on this repository match every other repository and disk space is not an issue.

Solution 1:

Probably your svn structure has no "Software/XXXXXX/branches" directory, it must exists in order to create "testbranch" here. You should make this directory ("branches") by hands and then do a branch.

Solution 2:

This unhelpful error message can occur if subdirectories on the destination path do not yet exist. Whilst you can manually create them (with svn mkdir) it is easier to use the --parents option.

    svn cp ^/trunk/bigproject ^/branches/experimental/bigproject -m 'test branch'

If branches or experimental did not exist then command would fail. This should work:

    svn cp --parents ^/trunk/bigproject ^/branches/experimental/bigproject -m 'test branch'

Solution 3:

We had exactly the same issue and it is a pity that here are only useless answers.

This is not an svn problem, it is a nginx issue. As the OP mentioned in a comment, this has to do with whitespace (or other chars that needs url encoding) in the path. There happens an overencoding, so that the path is wrong, when it reaches svn.

Old open bug at nginx

But there is a workaround in the nginx rewrite rule, that avoids this additional wrong encoding:

Wrong encoding happens:

if ( $http_destination ~* ^(.*)$ )
{
    set $fixed_destination $1;
}

no additional encoding:

if ( $http_destination ~* ^(?<fix>.*)$ )
{
    set $fixed_destination $fix;
}    

The solution here is to use a named group, that is the difference that makes nginx behave differently in this case, but we did not found any documentation explaining this.