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

Re: Rejecting commits to a 1.5 server from clients < 1.5

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-10-23 22:48:10 CEST

On Tue, 23 Oct 2007, Mark Phippard wrote:

> On 10/23/07, Daniel Rall <dlr@collab.net> wrote:
> > On Tue, 23 Oct 2007, Jack Repenning wrote:
> >
> > > On Oct 23, 2007, at 11:17 PM, Blair Zajac wrote:
> > >
> > > >How are we going to do this for ra_svn?
> > >
> > > And what about ra_local? Do we assume that anyone with a local repo
> > > is smart enough to worry about their own versionitis?
> >
> > A pre-1.5 client cannot read a 1.5 repository (due to a repos format
> > number bump), so this is actually the safest case for us, and already
> > (de-facto) enforced.
> Isn't this only true if the repository is created with 1.5? I thought
> the bump was tied to the sharding. I thought Merge Tracking just
> silently added a SQLite DB and did not bump the format.

I don't recall -- I was just recounting experiences I ran into during
development, where I couldn't access a 1.5 repos with a pre-1.5
client. But, those cases were always new 1.5 repositories created for
testing, which means they were sharded FSFS repositories, which is in
line with what Mark says here.

Looking over the code base and history, I don't see a format bump
associated with the mergeinfo index. I think we were able to avoid a
format bump at that time, by simply automatically creating the index
if not already present.

So, if the FSFS and BDB backends will read pre-1.5 repositories
without automatically bumping their format (e.g. like libsvn_wc does
to the WC), we may not be protected from this case in all situations.

On a related note, I recall discussing making the
MERGE_INFO_INDEX_SCHEMA_FORMAT use the same format number as the FS.
Anyone recall why we didn't do so?

  • application/pgp-signature attachment: stored
Received on Tue Oct 23 22:48:19 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.