The bug: SvnBridge will not accept a change to a filename using multi byte format.
Let us start figuring out what is going on, shall we?
Hm... looks like when TortoiseSVN is PUT-ing the file, it uses the directory name instead of the actual file name. Obviously, this is a client bug, and I can close this bug and move on to doing other things. Except that I am pretty sure that SVN can handle non ASCII characters...
Let us compare the network trace from SVN and SvnBridge and see what is going on...
Oh, I got the problem. TortoiseSVN is requesting a CHECKOUT, and we return the wrong URL. Obviously I did something astoundingly stupid there when I processed that request. Indeed, taking a look at what is going on there is... interesting.
Finally I realize that the problem is that while TortoiseSVN sends the URL in seemingly reasonable format, it is obviously being read wrongly by SvnBridge. It is using ASCII encoding to read this, while it probably should use UTF8. Because of that, the URL looks something like /tfsrtm08/test/????.txt, and ? is the query string terminator, no wonder I have issues.
But, how does it work for standard SVN servers. Hm, looks like when TortoiseSVN uses Url Encoding for the URL when taking to a standard SVN server. Why is it doing this?
Hm... looks like the URL that TortoiseSVN uses when it is request a CHECKOUT is the one that is returned in the response to a PROPFIND request.
Sure, that is easy to fix, we will just Url Encode the response from the PROPFIND handler.
Except that it doesn't work...
Oh, we also handle some of that in the file node class, so we will fix it there.
Except that it still doesn't work!
Grr! Looks like the way we handle Url Encoding is too invasive, we need to only UrlEncode non ASCII characters, this means that we should not encode characters such as '/', for example.
Let us try this again, shall we?
Hm... it still doesn't work. What is going on.
Oh! When we send the response to the CHECKOUT request, we send the URL for the PUT request in the location header, and we haven't Url Encoded that yet.
And now it works... :-D
Let us run the test and commit...
We have a broken test.
Well, okay, that is actually a test that is supposed to be broken (it is testing the way we Url Encode urls, after all).
Number of code lines changed, less than 20.
Number of hours spent of this bug: over eight hours.
Conclusion, I am not really being productive today. I am off to visit the code generation wizard...