Reviving an old thread: has anyone evaluated the possibility of having the
slave ask the master for its version at runtime?
Currently we require an "SVNMasterVersion 1.7" directive in the slave's
httpd.conf, but the problem is that the value of that directive can get out of
date as the master is upgraded (or downgraded).
The actual use-case driving this is Philip's workflow. He commits to
svn.apache.org via a DAV proxy on his workstation; but when his proxy runs 1.8,
he needs to set "SVMasterVersion 1.7" in his config --- which would get out of date as soon as svn.apache.org is upgraded.
(sidebar: do we promise forward compatibility here? i.e., is
"SVNMasterVersion 1.7" against an in-fact-1.8 master *guaranteed* to work?)
On Mon, Oct 15, 2012 at 08:19:16AM -0400, Mark Phippard wrote:
> On Mon, Oct 15, 2012 at 7:59 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>
> > What solutions do we have?
> >
> > - Something automated? Can a slave server contact a master server with
> > a custom feature negotiation request and cache the results?
>
> Is this possible? Could we try to contact the master at server
> startup or something and cache the version somewhere? That said, I do
> not believe the server currently provides any easy way to know this.
> It might even be a security hole if it did.
>
> We needed to know the version of the master in SVN Edge. With 1.7,
> this was relatively easy to do because we just had to see if the
> server supported HTTPv2. As we start to get to more obscure features
> it seems like it will be more difficult.
>
> This would be the ideal though. Maybe this "cache process" could go
> through the same feature negotiation that a client would normally go
> through and figure it out from that?
>
> > - Make the configuration fit the audience? What if instead of a (growing)
> > list of httpd.conf directives which mean nothing to the typical
> > administrator, we simply have one: SVNMasterVersion ${VERSION_NUMBER}?
> > We know which features showed up in which releases, and should be able
> > to do the right thing.
>
> I think this would be the next best option.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
Received on 2013-02-19 15:09:47 CET