Philip Martin wrote: > Julian Foad <julian.f...@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?) >
