Philip Martin wrote:
> Julian Foad <julian.foad_at_wandisco.com> 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 can mix accesses
> > arbitrarily using either. I can't think of any reason the server would
> > need to send both, so can we keep things simple by specifying that it
> > doesn't?
>
> The server sends one or the other, not both.
Good.
> > Additionally, this response will contain some new URL stub values:
> >
> > SVN-Rev-Stub: /REPOS-ROOT/!svn/rev
> > SVN-Rev-Root-Stub: /REPOS-ROOT/!svn/rvr
> > SVN-Txn-Stub: /REPOS-ROOT/!svn/txn
> > SVN-Txn-Root-Stub: /REPOS-ROOT/!svn/txr
> >
> > Should it send "vtxn" and "vtxr" stubs too, or instead?
>
> Those are not in the POST response.
Yes - that's the OPTIONS response.
> The server already sends SVN-Txn-Stub and SVN-Txn-Root-Stub during
> capabilities negotiation, the patch makes it send SVN-VTxn-Stub and
> SVN-VTxn-Root stub as well.
OK, good. Just doc tweaks then.
Thanks.
- Julian
> > (I don't
> > understand why the protocol needs to send these stubs explicitly at all:
> > is there some reason why these cannot just be constructed by the
> > client?)
>
Received on 2011-03-07 14:49:40 CET