1.7 write-through proxy to 1.6 master

[Philip Martin <ph...@wandisco.com>]

It's possible to setup a 1.7 write-through proxy to a 1.6 master.  This
works provided that the 1.7 proxy uses "SVNAdvertiseV2Protocol off",
but if the proxy doesn't disable V2 it forwards V2 requests to the
V1 master which results in ugly errors:

svn: E175002: Commit failed (details follow):
svn: E175002: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/repos/asf/!svn/me'

I'm not familiar with the proxy code.  I think a V2 proxy should check
whether the master advertises V2 support and return a more intelligible
error if it does not.  I suppose it only needs to do this if the client
is using V2 write commands, as a client using V1, or V2 read-only, will
work fine.  I suspect it is not possible for the proxy to switch to V1
automatically since I think the V2 support negotiated before the proxy
contacts the master.

Perhaps this is a valid use for the mythical "use V1" client switch :)

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Re: 1.7 write-through proxy to 1.6 master

[Philip Martin <ph...@wandisco.com>]

Another potential problem is in the 1.7 "atomic revprops" capability.
The 1.7 slave will proxy atomic revprop changes to the 1.6 master where
the atomic change is not implemented.  The master will do the old style
overwrite, and the client will not be aware that this happened.  The
revprop change does happen, but not in the atomic manner.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Re: 1.7 write-through proxy to 1.6 master

["C. Michael Pilato" <cm...@collab.net>]

On 07/14/2011 01:16 PM, Philip Martin wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
> 
>> Another less-obvious one was with the introduction of merge
>> tracking, where the repository format version dictated support (or lack
>> thereof) for a client-visible feature.  You might have had an existing 1.4
>> server (no merge tracking), popped up a 1.5 slave when that feature was
>> released, and now the clients are told that the server supports merge
>> tracking when it actually doesn't.
> 
> Does that matter?  The slave replies to all read requests from its own
> repository, and that does support mergeinfo.  Only write requests in a
> commit go through to the master and its repository.  Are there any write
> requests that depend on the server's support for mergeinfo?

Correction:  It's not strictly true that the slave replies to all read
requests.  The slave proxies any read requests aimed at commit transaction
resources to the master -- the only place where the commit transaction lives.

All that said, I don't think we query the mergeinfo of transaction
resources.  Maybe you're right and there's no immediate problem here.  I
mean, on the master, the svn:mergeinfo property would just look like a
property.  I suspect that if you later ran 'svnadmin upgrade' on the master
repository, the internal mergeinfo indexes would be all fouled up, but those
really just aid the performance and accuracy of read requests.  Any
post-commit hooks on the master which are dependent on accurate merge
tracking reporting may not behave as expected, either.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: 1.7 write-through proxy to 1.6 master

[Philip Martin <ph...@wandisco.com>]

"C. Michael Pilato" <cm...@collab.net> writes:

> Another less-obvious one was with the introduction of merge
> tracking, where the repository format version dictated support (or lack
> thereof) for a client-visible feature.  You might have had an existing 1.4
> server (no merge tracking), popped up a 1.5 slave when that feature was
> released, and now the clients are told that the server supports merge
> tracking when it actually doesn't.

Does that matter?  The slave replies to all read requests from its own
repository, and that does support mergeinfo.  Only write requests in a
commit go through to the master and its repository.  Are there any write
requests that depend on the server's support for mergeinfo?

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Re: 1.7 write-through proxy to 1.6 master

[Mark Phippard <ma...@gmail.com>]

On Thu, Jul 14, 2011 at 12:30 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 07/14/2011 12:01 PM, Philip Martin wrote:
>> It's possible to setup a 1.7 write-through proxy to a 1.6 master.
>
> It's also a really bad idea.

I think that opinion is overly extreme.  While it is certainly true
that you cannot just mix any two server versions, a blanket statement
that it is a bad idea to mix versions is not really true either.
People cannot always update every server at the same time so I do not
think this can or should be our position.

I plan on supporting 1.7 proxies with 1.6 masters by setting the
directive to not advertise the V2 protocol in this situation.  I am
comfortable doing this and do not see any problems with it.  Do you?

Could a proxy do some kind of negotiation with the master on startup
and then use that for its negotiations with clients?  In other words,
it seems like a proxy could self-configure itself and how it responds
to the OPTIONS request based on what it knows about its master.  In
the example above, it could turn off V2 itself if it knows the master
does not support it.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: 1.7 write-through proxy to 1.6 master

["C. Michael Pilato" <cm...@collab.net>]

On 07/14/2011 12:01 PM, Philip Martin wrote:
> It's possible to setup a 1.7 write-through proxy to a 1.6 master.

It's also a really bad idea.

The simple fact of the matter is that mixing and matching server versions in
a WebDAV proxy configuration doesn't work.  And it really never has without
caveats, despite claims to the contrary.  Feature negotiation happens at the
slave despite any undesirable consequences of the client acting on those
results when committing.  HTTP v1 vs. v2 is one obvious place where stuff
fails.  Another less-obvious one was with the introduction of merge
tracking, where the repository format version dictated support (or lack
thereof) for a client-visible feature.  You might have had an existing 1.4
server (no merge tracking), popped up a 1.5 slave when that feature was
released, and now the clients are told that the server supports merge
tracking when it actually doesn't.

Complicating all of this is the fact that, as with the client's handling of
the working copy library, the server code has no concept of gracefully
degrading to support older flavors of itself as a general rule.  Yeah, in
most cases stuff just kinda works okay.  But we've merely been lucky, if
we're honest about it.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: 1.7 write-through proxy to 1.6 master

[Daniel Shahaf <da...@apache.org>]

Philip Martin wrote on Thu, Jul 14, 2011 at 17:01:30 +0100:
> It's possible to setup a 1.7 write-through proxy to a 1.6 master.

Revisiting this thread: is it a fair conclusion that, in a write-through
proxy setup, the proxy shouldn't be newer than the master, but the
opposite is safe?