[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn commit: r1398863 - in /subversion/trunk/subversion: include/private/svn_subr_private.h include/svn_error_codes.h libsvn_subr/version.c tests/libsvn_subr/compat-test.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 16 Oct 2012 18:47:33 +0200

> -----Original Message-----
> From: cmpilato_at_apache.org [mailto:cmpilato_at_apache.org]
> Sent: dinsdag 16 oktober 2012 18:00
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1398863 - in /subversion/trunk/subversion:
> include/private/svn_subr_private.h include/svn_error_codes.h
> libsvn_subr/version.c tests/libsvn_subr/compat-test.c
>
> Author: cmpilato
> Date: Tue Oct 16 15:59:42 2012
> New Revision: 1398863
>
> URL: http://svn.apache.org/viewvc?rev=1398863&view=rev
> Log:
> Add private APIs for parsing Subversion release version strings and
> testing that they meet some minimum required version number. This is
> intended for use with a new SVNMasterVersion httpd.conf directive (to
> replace the plethora of per-feature toggles required to make
> version-mismatched proxy servers happy).
>
> That said, we might consider making these public and exposing them to
> hook authors who wish to use the ephemeral txnprops in start-commit
> and pre-commit to test and deny/allow commits based on client version
> pedigree. Just a thought.

Can we also use this for a more future proof svnadmin create --pre-1.6-compatible variant?

There is currently no way I can always create a Subversion 1.7 repository with either a 1.7 or a future client. (1.7 doesn't accept a pre-1.8 compatible version argument, etc.)

        Bert
Received on 2012-10-16 18:48:11 CEST

This is an archived mail posted to the Subversion Dev mailing list.