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

RE: Two svn_wc__db_t for single-db upgrade

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 27 Aug 2010 12:05:13 +0200

> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: vrijdag 27 augustus 2010 11:50
> To: Bert Huijben
> Cc: 'Greg Stein'; dev_at_subversion.apache.org
> Subject: Re: Two svn_wc__db_t for single-db upgrade
> "Bert Huijben" <bert_at_vmoo.com> writes:
> > The hard cases, like missing and obstructions of metadata are not
> handled
> > and cannot be handled by the single-db WC-DB api as these cannot
> occur there
> > . (There are no tests for this, and anything that looks like a test
> for this
> > is disabled for some 4th tree reason). You can't even see that data
> is
> > missing from most of the wc-db apis at they fall back to the parent
> stub.
> > (And the wc-db api doesn't allow annotating a node that it misses
> some
> > information)
> >
> > I don't think we can ever handle all the upgrade state with just the
> > single-db optimized API.
> > E.g. by just using the API you can't look through child-of-copy
> deletions,
> > nor do we need any apis for this for 1.7. But svn_wc_entry_t just has
> this
> > information directly.
> The upgrade code only ever needs to use the database to look at
> parents. If the parent information in the database is not correct
> then the upgrade has already failed.
> I don't understand your child-of-copy deletion example. That's one
> case the the existing multi-db upgrade code gets wrong, it creates a
> base_node where there should only be a working_node. It gets it wrong
> because svn_wc_entry_t does not have the copied information. The
> information is in the database and can be obtained by calling
> _read_info. Or we could make our own in-memory database of entries
> and query that, but I don't see why that is better.

In case of a delete of copy you can have

BASE normal (checked out N levels up)
NODE_DATA normal (descendant of copy 2 levels up)
NODE_DATA normal (child of copy 1 level up)
WORKING: deleted (node itself)

_read_info() will give you the information from working (It is deleted). And
_base_get_info() shows you there was a base in the repository. So you see a
normal base delete using the wc-db api. But actually you have 3 deletes in
one place (one inherited).

The current DB code can only represent the information you get from
_read_info and _base_get_info(), so the rest is lost.

however can represent one intermediate layer. Not the two from this example,
but just one. (The other case cannot be created by libsvn_wc. It will say
that you have to commit first).

But even in that case there can be different information in the parent stub
and the child directory itself.

> > So you are suggesting that we change the DB API's to provide this
> > information (or keep providing this multi-db specific information
> like the
> > obstruction statee that really have to be removed to get back at 1.6
> speed),
> > while we will never need these functions and statee after this
> conversion to
> > single-db?
> >
> > Using the db api for intermediate storage during update is making
> things
> > harder for future api users that never want to look back at the
> > pre-single-db era.
> >
> > And it slows down common code paths just to support upgrading from a
> version
> > that is hopefully ancient for us in a few months.
> >
> > And then we can only fix the api by fixing this problem later... or
> by
> > moving to wc-ng-NG.
> I'm not proposing to change any APIs. I introduce a new API to allow
> the creation of svn_wc__db_t that ignores 1.6 .svn directories when
> constructing pdhs. That's the only change. It allows the existing
> upgrade code to work in single-db just as it works in multi-db, with
> the same features and bugs.

So, we have to add at least one IF that always evaluates to one case for all
future Subversion versions except for upgrading for <= 1.6?

In my book, that is changing APIs just for upgrade.

> Just had a thought. Do you think I am proposing that we extract
> svn_wc_entry_t structures from the database during upgrade? That's
> not what I am proposing. Upgrade will read the 1.6 .svn/entries to
> get svn_wc_entry_t structires, but when we need information about the
> parent we use the existing wc-ng API to get things like
> svn_wc__db_status_t.

        No, (No!)

I already suggested dropping all upgrade support for formats
13-(SINGLE_DB-1) from libsvn_wc and leave that to some hacky python script.

Why would you ever want to use the entry read code via wc__db_t?

You can just read the entry files recursively and insert in the db as
needed. The wc_db api doesn't have to care about entries files at all; only
for detecting that WCs must be upgraded.

Received on 2010-08-27 12:07:11 CEST

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.