Greg Stein <gst...@gmail.com> writes: > Wait a minute. The svn client won't ever send this. So I'm not sure > what you mean by "client send path" here, or "requiring ... the use of > a proxy". > > Your request for this feature is entirely predicated on a proxy. So of > course you need a proxy. And the client is never sending this header.
By default a standard Subversion client won't send the header, but any client could send it -- it's part of the protocol. The patch includes some conditional code that causes the svn client to send the header. That code is not normally compiled, but if it is compiled it allows testing both the server behaviour to VTXN-NAME, and the svn client behaviour when it receives VTXN-NAME, without requiring a proxy that adds VTXN-NAME. The patch has also been tested within WANdisco using their proxy. >> And it may be more convenient for the proxy as well, but I've not looked >> at any proxy implementations so I can't say for certain. > > What?! You must be looking at a proxy implementation. That is why you > want this feature. Not me, other people do that. People who work on WANdisco's proxy described the problem in terms of the HTTP protocol. As far as I am concerned it is more convenient for the server to return the header, as I can test using a small amount of extra code to send VTXN-NAME. If the server doesn't return the header then I need more test code. -- Philip
