> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: dinsdag 16 oktober 2012 20:11
> To: Bert Huijben
> Cc: dev@subversion.apache.org
> Subject: 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
>
> On 10/16/2012 12:47 PM, Bert Huijben wrote:
> >> 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.)
>
> So, you're thinking something along the lines of:
>
> $ svnadmin create --compat-version=MAJOR.MINOR
Something like that.
I really dislike the existing pattern here, of just adding a new argument on
new versions for making the repository compatible with an old version. This
only makes us compatible one version after breaking compatibility.
Bert
