"Bert Huijben" <bert_at_qqmail.nl> writes:
> 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.
>
> svn_wc_entry_t
> 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).
That shows how complicated the update process can be. I'm not sure
how it answers my question about why it's wrong to query the database.
> But even in that case there can be different information in the parent stub
> and the child directory itself.
If I query the database I don't have to worry about parent stubs.
There aren't any.
>> 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.
The code that I want to change already understands 1.6 format. This
is the change in svn_wc__db_pdh_parse_local_abspath:
Index: ../src/subversion/libsvn_wc/wc_db_pdh.c
===================================================================
--- ../src/subversion/libsvn_wc/wc_db_pdh.c (revision 990126)
+++ ../src/subversion/libsvn_wc/wc_db_pdh.c (working copy)
@@ -526,7 +526,7 @@
five ancetors higher. We don't test for directory presence (just
for the presence of subdirs/files), so we don't know when we can
stop checking ... so just check always. */
- if (!moved_upwards || always_check)
+ if (!db->ignore_1_6 && (!moved_upwards || always_check))
{
SVN_ERR(get_old_version(&wc_format, local_abspath, scratch_pool));
if (wc_format != 0)
The ignore_1_6 flag is new, and I need a way to set it, but that's it.
When the flag is set the wc_db code is almost the same, it just won't
detect old 1.6 working copies.
>> 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.
I still don't understand your objections. I am not proposing that
svn_wc__db_t be used to read entries.
The upgrade process work as follows:
- read the 1.6 entries for a directory into svn_wc_entry_t in memory
- write nodes into the SQLite db for the directory and immediate children
- cleanup the old 1.6 files
- move on to the subdirectories
If we were to move the entries file after reading it but before
writing to the database then the single-db upgrade code would work.
The directory being upgraded would not look like a 1.6 directory and
the pdh code would skip over it an find the root. This is exactly
what happens once the old 1.6 files have been cleaned and we move on
to the subdirectories.
Moving the entries file is not a good solution because an interrupted
upgrade would be harder to handle. The change I want to make has the
same effect as moving the entries file: once we have started upgrading
the directory then give me a way to treat it as a wc-ng directory not
a 1.6 directory.
Another way to achieve what I want is to provide a way to insert an
appropriate pdh:
svn_error_t *
svn_wc__db_pdh_skip_1_6(svn_wc__db_t *db,
const char *local_abspath,
apr_pool_t *scratch_pool)
{
svn_wc__db_pdh_t *pdh;
const char *parent_abspath = svn_dirent_dirname(local_abspath, scratch_pool);
svn_wc__db_pdh_t *parent_pdh = apr_hash_get(db->dir_data, parent_abspath,
APR_HASH_KEY_STRING);
SVN_ERR_ASSERT(parent_pdh);
VERIFY_USABLE_PDH(parent_pdh);
pdh = apr_pcalloc(db->state_pool, sizeof(*pdh));
pdh->local_abspath = apr_pstrdup(db->state_pool, local_abspath);
pdh->parent = parent_pdh;
pdh->wcroot = parent_pdh->wcroot;
apr_hash_set(db->dir_data, pdh->local_abspath, APR_HASH_KEY_STRING, pdh);
return SVN_NO_ERROR;
}
and then call this from the upgrade_working_copy before making the
recursive call.
--
Philip
Received on 2010-08-27 15:57:51 CEST