Greg Stein 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 nev
On Wed, Mar 9, 2011 at 06:43, Philip Martin wrote:
> Philip Martin writes:
>
>> Greg Stein writes:
>>
>>> The proxy is the one altering the request/response flow. From the
>>> server's standpoint, the client (in this case, the proxy) already
>>> knows the name. Why should the server tell it what
Philip Martin writes:
> Greg Stein writes:
>
>> The proxy is the one altering the request/response flow. From the
>> server's standpoint, the client (in this case, the proxy) already
>> knows the name. Why should the server tell it what it already knows?
>> Why should it put that useless informa
Greg Stein writes:
> The proxy is the one altering the request/response flow. From the
> server's standpoint, the client (in this case, the proxy) already
> knows the name. Why should the server tell it what it already knows?
> Why should it put that useless information onto the wire?
It's conve
On Wed, Mar 9, 2011 at 04:40, Philip Martin wrote:
> Greg Stein writes:
>...
>> Basically, the server is responding with somebody the requestor
>> already knows. So I wonder which approach is "best". It seems to be
>> kinda six-of-one/half-dozen-of-another. I suspect the server just
>> needs an i
Greg Stein writes:
> On Tue, Mar 8, 2011 at 11:08, Philip Martin
> wrote:
>> VTXN operation:
>>
>> - client sends POST
>> - proxy adds SVN-VTxn-Name:UUID
>> - server creates transaction called TXN-NAME
>> - server replies SVN-VTxn-Name:UUID
>> - proxy passes
>
> or:
>
> - proxy adds: SVN
On Tue, Mar 8, 2011 at 11:08, Philip Martin wrote:
> Greg Stein writes:
>
>> And to be clear: the server *could* just remain silent, and the proxy
>> would insert the SVN-VTxn-Name header in the response back to the
>> client, right? Would that be an improvement/simplification?
>
> I don't think
Greg Stein writes:
> And to be clear: the server *could* just remain silent, and the proxy
> would insert the SVN-VTxn-Name header in the response back to the
> client, right? Would that be an improvement/simplification?
I don't think so.
Normal operation:
- client sends POST
- server crea
On Sat, Mar 5, 2011 at 13:16, Philip Martin wrote:
> Greg Stein writes:
>
>>> If the client sends, or a proxy injects, an SVN-VTxn-Name header with
>>> the POST request it defines the transaction name to be returned to the
>>> client in the POST response. If the client recieves the new
>>> SVN-V
Philip Martin wrote:
> Julian Foad writes:
>
> > One thing that's not 100% clear from the protocol doc update is whether
> > the server sends *both* txn names in response, or just the "V" version.
> > If it sends both, then we need to specify whether the client has to use
> > the "V" version or c
Julian Foad writes:
> One thing that's not 100% clear from the protocol doc update is whether
> the server sends *both* txn names in response, or just the "V" version.
> If it sends both, then we need to specify whether the client has to use
> the "V" version or can choose to use either one, or c
On Fri, 2011-03-04, Philip Martin wrote:
> Extend Subversion's v2 HTTP protocol to include URIs that allow the
> client to define the transaction name visible in on the wire.
>
> If the client sends, or a proxy injects, an SVN-VTxn-Name header with
> the POST request it defines the transaction nam
Greg Stein writes:
>> If the client sends, or a proxy injects, an SVN-VTxn-Name header with
>> the POST request it defines the transaction name to be returned to the
>> client in the POST response. If the client recieves the new
>> SVN-VTxn-Name header it uses that name in the new URIs in the re
On Fri, Mar 4, 2011 at 07:29, Philip Martin wrote:
>...
> Extend Subversion's v2 HTTP protocol to include URIs that allow the
> client to define the transaction name visible in on the wire.
>
> If the client sends, or a proxy injects, an SVN-VTxn-Name header with
> the POST request it defines the
On 03/04/2011 07:29 AM, Philip Martin wrote:
> "C. Michael Pilato" writes:
>
>> Just a thought: Have you considered expanding the scope of the private
>> resource space rather than using the magic prefix hack? You could add
>> ".../!svn/vtxn/UUID" and ".../!svn/vtxr/UUID/..." to be alternate wa
"C. Michael Pilato" writes:
> Just a thought: Have you considered expanding the scope of the private
> resource space rather than using the magic prefix hack? You could add
> ".../!svn/vtxn/UUID" and ".../!svn/vtxr/UUID/..." to be alternate ways to
> address transactions and transaction roots (
16 matches
Mail list logo
