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