I'm not sure what you are talking about here.
Whether or not you are using some kind of proxy doesn't matter at all, as
Subversion never passed the information to a server and never should start
doing that as it would introduce an inconsistency.
And the problem you describe is pure client side... the problem is caused by
invoking commands on the clients with a username (and potentially a
password) in the url.
I really hope that your proxy server isn't able to just invoke commands on
the individual client pc's as that would be a huge security problem in your
setup.
Our server protocol is completely described as relative to (and below) the
BASE url of the repository, so we don't even process the hostname there.
Some webbrowsers allowed passing user@ in their urls years ago and stopped
for very good (security) reasons. We never supported this on urls except for
the very specific svn+ssh://user@hostname/ cases where there is no other way
to pass a user (and you might actually use a different user for the SSH part
and the svnserve connection that we tunnel over it).
The problem is that we accidentally accepted and ignored these parts in our
URLs (because the libneon parse functions ignored it for us) and somehow
your code started relying on that.
As we rely on the repository root url being canonical, you are introducing
problems for yourself by adding details there that will make working copies
incompatible with clients that don't expect this.
E.g.
$ svn cp WC1/file WC2/file
Will never work if WC1 and WC2 are from different repositories... and the
way we check that is by comparing the repository root url and the UUID. If
either is different you will get errors that the repository is not the same.
The best thing I can think of is that we automatically redirect DAV
repositories with a username in their url to the location without the
username (as that would resolve the problem I just described for almost
every user that accidentally uses this), but I'm guessing that this will
break your use case even further.
Bert
>
> Thanks,
> Guido