You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2012/09/18 17:11:39 UTC
working copy format bump on trunk this week?
Bert says he is done implementing the new conflict storage
scheme, and that it needs a format bump to be enabled by default.
It seems the necessary upgrade code is already in place.
I'd like to do some work on top of the new conflict storage so
it would be nice to see it enabled soon (this week).
There are some additional ideas queued up for this format bump:
/* TODO: Rename the "absent" presence value to "server-excluded". wc_db.c
and this file have references to "absent" which still need to be changed
to "server-excluded". */
/* TODO: Un-confuse *_revision column names in the EXTERNALS table to
"-r<operative> foo@<peg>", as suggested by the patch attached to
http://svn.haxx.se/dev/archive-2011-09/0478.shtml */
/* TODO: Remove column parent_relpath from EXTERNALS. We're not using it and
never will. It's not interesting like in the NODES table: the external's
parent path may be *anything*: unversioned, "behind" a another WC... */
AFAIK we'll also need to bump the format for inherited properties.
Should we try to get all of this into a single format bump?
We could also burn a couple of format numbers before releasing the
final 1.8 format, couldn't we? If so, I'd like to perform a format
bump including the new conflict storage and the absent -> server-exluded
rename (which I suggested), and leave the other items for others
to handle in one or more separate bumps. Any objections?
Re: working copy format bump on trunk this week?
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Sep 19, 2012 at 08:26:43PM +0100, Julian Foad wrote:
> Paul Burba wrote:
> On Wed, Sep 19, 2012 at 10:43 AM, Stefan Sperling <st...@elego.de> wrote:
> >> If Paul is travelling this week and thus won't get to integrating
> >> his branch this week, then why should I have to wait in order to
> >> start comitting code on trunk that is based on Bert's new conflict
> >> storage? :) Cause right now I'm already hacking in a local working
> >> copy with a patched client that is already over the bump (with a
> >> format 30 that's different to Paul's!
> >
> > Don't let my branch stop you from bumping Stefan, have at it. This is
> > great IMHO, it may make people more appreciative of the auto upgrade
> > issues.
>
> For the record, sounds good to me too: that is, we shouldn't be too afraid of doing format bumps, despite the minor inconveniences.
I've committed the bump in r1387742, and then fixed some test fallout
in subsequent revisions (forgot about checking on the authz tests before
commit...). As of r1387787 we should be in good shape. Thanks all!
Re: working copy format bump on trunk this week?
Posted by Julian Foad <ju...@btopenworld.com>.
Paul Burba wrote:
On Wed, Sep 19, 2012 at 10:43 AM, Stefan Sperling <st...@elego.de> wrote:
>> If Paul is travelling this week and thus won't get to integrating
>> his branch this week, then why should I have to wait in order to
>> start comitting code on trunk that is based on Bert's new conflict
>> storage? :) Cause right now I'm already hacking in a local working
>> copy with a patched client that is already over the bump (with a
>> format 30 that's different to Paul's!
>
> Don't let my branch stop you from bumping Stefan, have at it. This is
> great IMHO, it may make people more appreciative of the auto upgrade
> issues.
For the record, sounds good to me too: that is, we shouldn't be too afraid of doing format bumps, despite the minor inconveniences.
- Julian
Re: working copy format bump on trunk this week?
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Sep 19, 2012 at 10:43 AM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Sep 19, 2012 at 06:36:04AM -0700, C. Michael Pilato wrote:
>> On 09/19/2012 02:33 AM, Stefan Sperling wrote:
>> > No responses so far. Does that mean there are no objections?
>>
>> The US/Europe CollabNet committers are all traveling this week for meetings,
>> so expect a slower response rate from us.
>
> Fine. BTW, I just talked to Bert on IRC, he's fine with me bumping
> the format as proposed, tonight CEST.
>
>> Paul's 'inheritable-props' branch work expects to make changes in format 30,
>> too, and that work has not (as far as I know) been merged to trunk. I think
>> it would be a shame to "go live" with format 30 today and then force Paul to
>> introduce a format 31 when he later merges his branch (which is, IMO, almost
>> ready for reintegration).
>
> I tried to address this point in my original mail, but allow me
> to elaborate:
>
> I know Paul has already bumped to 30 on his branch.
> This now means that either everyone else is blocked from bumping
> and has to wait, or that Paul will have to perform another bump
> after merging from trunk (and perhaps deal with the fallout of having
> working copies labeled '30' that now aren't the official trunk '30').
>
> If Paul is travelling this week and thus won't get to integrating
> his branch this week, then why should I have to wait in order to
> start comitting code on trunk that is based on Bert's new conflict
> storage? :) Cause right now I'm already hacking in a local working
> copy with a patched client that is already over the bump (with a
> format 30 that's different to Paul's!
Don't let my branch stop you from bumping Stefan, have at it. This is
great IMHO, it may make people more appreciative of the auto upgrade
issues.
-- I guess that's collective
> poor planning on our part...)
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
> I could of course go on a branch, too, and perform a local bump there.
> However that doesn't solve the problem that we'll have to bump anyway
> at some point, and that we'll have to agree on the feature set of
> format 30. And I might not have much time for this next week.
>
> It would of course be best to integrate this all in one go.
> However, I don't think we should be afraid of format bumps to the
> point where people are waiting for each other for several days
> to make progress.
>
> I don't want to force this down anyone's throat though. I can deal
> with this locally as well, and wait for Paul's changes to be merged
> to trunk. However, if Paul's merge is to be a clean one, then *his*
> format 30 will be used, and I'll have to make my changes in 31.
>
>> Oh. I also still abhor the fact that we auto-upgrade working copies. But I
>> suppose that's a different rant for a different thread/sympathic_audience.
>
> Agreed and agreed. It also makes development harder in situations
> like these, since it forces people with different format '30' working
> copies to remember which client they used on it... :(
format bumps in branches Re: working copy format bump on trunk this
week?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Wed, Sep 19, 2012 at 16:43:39 +0200:
> storage? :) Cause right now I'm already hacking in a local working
> copy with a patched client that is already over the bump (with a
> format 30 that's different to Paul's! -- I guess that's collective
> poor planning on our part...)
So... feature branches should always bump on-disk format numbers to 99?
Re: working copy format bump on trunk this week?
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Sep 19, 2012 at 06:36:04AM -0700, C. Michael Pilato wrote:
> On 09/19/2012 02:33 AM, Stefan Sperling wrote:
> > No responses so far. Does that mean there are no objections?
>
> The US/Europe CollabNet committers are all traveling this week for meetings,
> so expect a slower response rate from us.
Fine. BTW, I just talked to Bert on IRC, he's fine with me bumping
the format as proposed, tonight CEST.
> Paul's 'inheritable-props' branch work expects to make changes in format 30,
> too, and that work has not (as far as I know) been merged to trunk. I think
> it would be a shame to "go live" with format 30 today and then force Paul to
> introduce a format 31 when he later merges his branch (which is, IMO, almost
> ready for reintegration).
I tried to address this point in my original mail, but allow me
to elaborate:
I know Paul has already bumped to 30 on his branch.
This now means that either everyone else is blocked from bumping
and has to wait, or that Paul will have to perform another bump
after merging from trunk (and perhaps deal with the fallout of having
working copies labeled '30' that now aren't the official trunk '30').
If Paul is travelling this week and thus won't get to integrating
his branch this week, then why should I have to wait in order to
start comitting code on trunk that is based on Bert's new conflict
storage? :) Cause right now I'm already hacking in a local working
copy with a patched client that is already over the bump (with a
format 30 that's different to Paul's! -- I guess that's collective
poor planning on our part...)
I could of course go on a branch, too, and perform a local bump there.
However that doesn't solve the problem that we'll have to bump anyway
at some point, and that we'll have to agree on the feature set of
format 30. And I might not have much time for this next week.
It would of course be best to integrate this all in one go.
However, I don't think we should be afraid of format bumps to the
point where people are waiting for each other for several days
to make progress.
I don't want to force this down anyone's throat though. I can deal
with this locally as well, and wait for Paul's changes to be merged
to trunk. However, if Paul's merge is to be a clean one, then *his*
format 30 will be used, and I'll have to make my changes in 31.
> Oh. I also still abhor the fact that we auto-upgrade working copies. But I
> suppose that's a different rant for a different thread/sympathic_audience.
Agreed and agreed. It also makes development harder in situations
like these, since it forces people with different format '30' working
copies to remember which client they used on it... :(
Re: working copy format bump on trunk this week?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 09/19/2012 02:33 AM, Stefan Sperling wrote:
> No responses so far. Does that mean there are no objections?
The US/Europe CollabNet committers are all traveling this week for meetings,
so expect a slower response rate from us.
Paul's 'inheritable-props' branch work expects to make changes in format 30,
too, and that work has not (as far as I know) been merged to trunk. I think
it would be a shame to "go live" with format 30 today and then force Paul to
introduce a format 31 when he later merges his branch (which is, IMO, almost
ready for reintegration).
Oh. I also still abhor the fact that we auto-upgrade working copies. But I
suppose that's a different rant for a different thread/sympathic_audience.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: working copy format bump on trunk this week?
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Sep 19, 2012 at 11:33:46AM +0200, Stefan Sperling wrote:
> No responses so far. Does that mean there are no objections?
>
> Here is the diff I'm planning to commit.
Better diff, documenting format 30 changes and fixing test fallout.
Index: subversion/libsvn_wc/wc-metadata.sql
===================================================================
--- subversion/libsvn_wc/wc-metadata.sql (revision 1387535)
+++ subversion/libsvn_wc/wc-metadata.sql (working copy)
@@ -32,7 +32,7 @@
* the PRESENCE column in these tables has one of the following values
* (see also the C type #svn_wc__db_status_t):
* "normal"
- * "absent" -- server has declared it "absent" (ie. authz failure)
+ * "server-excluded" -- server has declared it excluded (ie. authz failure)
* "excluded" -- administratively excluded (ie. sparse WC)
* "not-present" -- node not present at this REV
* "incomplete" -- state hasn't been filled in
@@ -367,7 +367,7 @@ CREATE TABLE NODES (
current 'op_depth'. This state is badly named, it should be
something like 'deleted'.
- absent: in the 'BASE' tree this is a node that is excluded by
+ server-excluded: in the 'BASE' tree this is a node that is excluded by
authz. The name of the node is known from the parent, but no
other information is available. Not valid in the 'WORKING'
tree as there is no way to commit such a node.
@@ -773,14 +773,18 @@ PRAGMA user_version = 29;
/* ------------------------------------------------------------------------- */
-/* Format 30 currently just contains some nice to haves that should be included
- with the next format bump */
+/* Format 30 creates new NODES indices for move information and for the
+ md5_checksum column. Most importantly, it activates use of skel-based
+ conflict storage -- see notes/wc-ng/conflict-storage-2.0.
+ It also renames the "absent" presence to "server-excluded". */
-- STMT_UPGRADE_TO_30
CREATE UNIQUE INDEX IF NOT EXISTS I_NODES_MOVED
ON NODES (wc_id, moved_to, op_depth);
CREATE INDEX IF NOT EXISTS I_PRISTINE_MD5 ON PRISTINE (md5_checksum);
+UPDATE nodes SET presence = "server-excluded" WHERE presence = "absent";
+
/* Just to be sure clear out file external skels from pre 1.7.0 development
working copies that were never updated by 1.7.0+ style clients */
UPDATE nodes SET file_external=1 WHERE file_external IS NOT NULL;
@@ -818,9 +822,6 @@ WHERE wc_id = ?1 and local_relpath = ?2
number will be, however, so we're just marking it as 99 for now. */
-- format: 99
-/* TODO: Rename the "absent" presence value to "server-excluded". wc_db.c
- and this file have references to "absent" which still need to be changed
- to "server-excluded". */
/* TODO: Un-confuse *_revision column names in the EXTERNALS table to
"-r<operative> foo@<peg>", as suggested by the patch attached to
http://svn.haxx.se/dev/archive-2011-09/0478.shtml */
Index: subversion/libsvn_wc/wc.h
===================================================================
--- subversion/libsvn_wc/wc.h (revision 1387535)
+++ subversion/libsvn_wc/wc.h (working copy)
@@ -157,7 +157,7 @@ extern "C" {
* Please document any further format changes here.
*/
-#define SVN_WC__VERSION 29
+#define SVN_WC__VERSION 30
/* Formats <= this have no concept of "revert text-base/props". */
Index: subversion/libsvn_wc/wc_db.c
===================================================================
--- subversion/libsvn_wc/wc_db.c (revision 1387535)
+++ subversion/libsvn_wc/wc_db.c (working copy)
@@ -293,9 +293,7 @@ static const svn_token_map_t kind_map[] = {
of all the status values. */
static const svn_token_map_t presence_map[] = {
{ "normal", svn_wc__db_status_normal },
- /* ### "absent" is the former name of the "server-excluded" presence.
- * ### We should change it to "server-excluded" with a format bump. */
- { "absent", svn_wc__db_status_server_excluded },
+ { "server-excluded", svn_wc__db_status_server_excluded },
{ "excluded", svn_wc__db_status_excluded },
{ "not-present", svn_wc__db_status_not_present },
{ "incomplete", svn_wc__db_status_incomplete },
Index: subversion/tests/cmdline/resolve_tests.py
===================================================================
--- subversion/tests/cmdline/resolve_tests.py (revision 1387535)
+++ subversion/tests/cmdline/resolve_tests.py (working copy)
@@ -106,7 +106,6 @@ def automatic_conflict_resolution(sbox):
# Test for issue #3707 'property conflicts not handled correctly by
# svn resolve'.
@Issue(3707)
-@XFail()
def prop_conflict_resolution(sbox):
"resolving prop conflicts"
Index: subversion/tests/libsvn_wc/db-test.c
===================================================================
--- subversion/tests/libsvn_wc/db-test.c (revision 1387535)
+++ subversion/tests/libsvn_wc/db-test.c (working copy)
@@ -107,7 +107,7 @@ static const char * const TESTING_DATA = (
" null, null, 'symlink', null, null, null, null, null, null, null,"
" null, null, null, null);"
"insert into nodes values ("
- " 1, 'C', 0, '', 1, 'C', null, 'absent',"
+ " 1, 'C', 0, '', 1, 'C', null, 'server-excluded',"
" null, null, 'unknown', null, null, null, null, null, null, null,"
" null, null, null, null);"
"insert into nodes values ("
@@ -459,7 +459,7 @@ test_getting_info(apr_pool_t *pool)
SVN_TEST_ASSERT(target == NULL);
SVN_TEST_ASSERT(lock == NULL);
- /* Test: unknown kind, absent presence. */
+ /* Test: unknown kind, server-excluded presence. */
SVN_ERR(svn_wc__db_base_get_info(
&status, &kind, NULL,
NULL, NULL, NULL,
@@ -681,7 +681,7 @@ test_inserting_nodes(apr_pool_t *pool)
NULL, NULL,
pool));
- /* Replace an incomplete node with an absent file node. */
+ /* Replace an incomplete node with an server-excluded file node. */
SVN_ERR(svn_wc__db_base_add_excluded_node(
db, svn_dirent_join(local_abspath, "N/N-b", pool),
"N/N-b", ROOT_ONE, UUID_ONE, 3,
@@ -705,7 +705,7 @@ test_inserting_nodes(apr_pool_t *pool)
NULL, NULL,
pool));
- /* Create a new absent unknown-kind node. */
+ /* Create a new server-excluded unknown-kind node. */
SVN_ERR(svn_wc__db_base_add_excluded_node(
db, svn_dirent_join(local_abspath, "R", pool),
"R", ROOT_ONE, UUID_ONE, 3,
Index: subversion/tests/libsvn_wc/entries-compat.c
===================================================================
--- subversion/tests/libsvn_wc/entries-compat.c (revision 1387535)
+++ subversion/tests/libsvn_wc/entries-compat.c (working copy)
@@ -106,7 +106,7 @@ static const char * const TESTING_DATA = (
" null, null, 'symlink', null, null, null, null, null, null, null,"
" null, null, null, null);"
"insert into nodes values ("
- " 1, 'C', 0, '', 1, 'C', null, 'absent',"
+ " 1, 'C', 0, '', 1, 'C', null, 'server-excluded',"
" null, null, 'unknown', null, null, null, null, null, null, null,"
" null, null, null, null);"
"insert into nodes values ("
Index: subversion/tests/libsvn_wc/op-depth-test.c
===================================================================
--- subversion/tests/libsvn_wc/op-depth-test.c (revision 1387535)
+++ subversion/tests/libsvn_wc/op-depth-test.c (working copy)
@@ -3383,7 +3383,7 @@ test_copy_of_deleted(const svn_test_opts_t *opts,
SVN_ERR(svn_test__sandbox_create(&b, "copy_of_deleted", opts, pool));
SVN_ERR(add_and_commit_greek_tree(&b));
- /* Recreate the test scenario from copy_tests.py copy_wc_url_with_absent */
+ /* Recreate the test scenario from copy_tests.py copy_wc_url_with_server_excluded */
/* Delete A/B */
SVN_ERR(wc_delete(&b, "A/B"));
@@ -3673,21 +3673,21 @@ copy_file_externals(const svn_test_opts_t *opts, a
}
static svn_error_t *
-copy_wc_wc_absent(const svn_test_opts_t *opts, apr_pool_t *pool)
+copy_wc_wc_server_excluded(const svn_test_opts_t *opts, apr_pool_t *pool)
{
svn_test__sandbox_t b;
nodes_row_t before[] = {
{0, "", "normal", 1, ""},
{0, "A", "normal", 1, "A"},
{0, "A/B", "normal", 1, "A/B"},
- {0, "A/B/E", "absent", 1, "A/B/E"},
+ {0, "A/B/E", "server-excluded", 1, "A/B/E"},
{0}
};
nodes_row_t after[] = {
{0, "", "normal", 1, ""},
{0, "A", "normal", 1, "A"},
{0, "A/B", "normal", 1, "A/B"},
- {0, "A/B/E", "absent", 1, "A/B/E"},
+ {0, "A/B/E", "server-excluded", 1, "A/B/E"},
{1, "X", "normal", 1, "A"},
{1, "X/B", "normal", 1, "A/B"},
{1, "X/B/E", "incomplete", 1, "A/B/E"},
@@ -3695,7 +3695,7 @@ static svn_error_t *
};
svn_error_t *err;
- SVN_ERR(svn_test__sandbox_create(&b, "copy_wc_wc_absent", opts, pool));
+ SVN_ERR(svn_test__sandbox_create(&b, "copy_wc_wc_server_excluded", opts, pool));
SVN_ERR(insert_dirs(&b, before));
SVN_ERR(check_db_rows(&b, "", before));
SVN_ERR(disk_mkdir(&b, "A"));
@@ -5054,8 +5054,8 @@ struct svn_test_descriptor_t test_funcs[] =
"revert_file_externals"),
SVN_TEST_OPTS_PASS(copy_file_externals,
"copy_file_externals"),
- SVN_TEST_OPTS_PASS(copy_wc_wc_absent,
- "test_wc_wc_copy_absent"),
+ SVN_TEST_OPTS_PASS(copy_wc_wc_server_excluded,
+ "test_wc_wc_copy_server_excluded"),
SVN_TEST_OPTS_PASS(incomplete_switch,
"incomplete_switch (issue 4040)"),
SVN_TEST_OPTS_PASS(nested_moves_child_first,
Re: working copy format bump on trunk this week?
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 18, 2012 at 05:11:39PM +0200, Stefan Sperling wrote:
> Bert says he is done implementing the new conflict storage
> scheme, and that it needs a format bump to be enabled by default.
> It seems the necessary upgrade code is already in place.
> I'd like to do some work on top of the new conflict storage so
> it would be nice to see it enabled soon (this week).
>
> There are some additional ideas queued up for this format bump:
>
> /* TODO: Rename the "absent" presence value to "server-excluded". wc_db.c
> and this file have references to "absent" which still need to be changed
> to "server-excluded". */
> /* TODO: Un-confuse *_revision column names in the EXTERNALS table to
> "-r<operative> foo@<peg>", as suggested by the patch attached to
> http://svn.haxx.se/dev/archive-2011-09/0478.shtml */
> /* TODO: Remove column parent_relpath from EXTERNALS. We're not using it and
> never will. It's not interesting like in the NODES table: the external's
> parent path may be *anything*: unversioned, "behind" a another WC... */
>
> AFAIK we'll also need to bump the format for inherited properties.
>
> Should we try to get all of this into a single format bump?
> We could also burn a couple of format numbers before releasing the
> final 1.8 format, couldn't we? If so, I'd like to perform a format
> bump including the new conflict storage and the absent -> server-exluded
> rename (which I suggested), and leave the other items for others
> to handle in one or more separate bumps. Any objections?
No responses so far. Does that mean there are no objections?
Here is the diff I'm planning to commit.
So far, I've verified that working copies containing server-excluded
nodes and text conflicts auto-upgrade fine (as of r1387503).
Index: subversion/libsvn_wc/wc-metadata.sql
===================================================================
--- subversion/libsvn_wc/wc-metadata.sql (revision 1387482)
+++ subversion/libsvn_wc/wc-metadata.sql (working copy)
@@ -32,7 +32,7 @@
* the PRESENCE column in these tables has one of the following values
* (see also the C type #svn_wc__db_status_t):
* "normal"
- * "absent" -- server has declared it "absent" (ie. authz failure)
+ * "server-excluded" -- server has declared it excluded (ie. authz failure)
* "excluded" -- administratively excluded (ie. sparse WC)
* "not-present" -- node not present at this REV
* "incomplete" -- state hasn't been filled in
@@ -367,7 +367,7 @@ CREATE TABLE NODES (
current 'op_depth'. This state is badly named, it should be
something like 'deleted'.
- absent: in the 'BASE' tree this is a node that is excluded by
+ server-excluded: in the 'BASE' tree this is a node that is excluded by
authz. The name of the node is known from the parent, but no
other information is available. Not valid in the 'WORKING'
tree as there is no way to commit such a node.
@@ -785,6 +785,9 @@ CREATE INDEX IF NOT EXISTS I_PRISTINE_MD5 ON PRIST
working copies that were never updated by 1.7.0+ style clients */
UPDATE nodes SET file_external=1 WHERE file_external IS NOT NULL;
+/* The former "absent" presence is now called "server-excluded". */
+UPDATE nodes SET presence = "server-excluded" WHERE presence = "absent";
+
PRAGMA user_version = 30;
-- STMT_UPGRADE_30_SELECT_CONFLICT_SEPARATE
@@ -818,9 +821,6 @@ WHERE wc_id = ?1 and local_relpath = ?2
number will be, however, so we're just marking it as 99 for now. */
-- format: 99
-/* TODO: Rename the "absent" presence value to "server-excluded". wc_db.c
- and this file have references to "absent" which still need to be changed
- to "server-excluded". */
/* TODO: Un-confuse *_revision column names in the EXTERNALS table to
"-r<operative> foo@<peg>", as suggested by the patch attached to
http://svn.haxx.se/dev/archive-2011-09/0478.shtml */
Index: subversion/libsvn_wc/wc.h
===================================================================
--- subversion/libsvn_wc/wc.h (revision 1387482)
+++ subversion/libsvn_wc/wc.h (working copy)
@@ -157,7 +157,7 @@ extern "C" {
* Please document any further format changes here.
*/
-#define SVN_WC__VERSION 29
+#define SVN_WC__VERSION 30
/* Formats <= this have no concept of "revert text-base/props". */
Index: subversion/libsvn_wc/wc_db.c
===================================================================
--- subversion/libsvn_wc/wc_db.c (revision 1387482)
+++ subversion/libsvn_wc/wc_db.c (working copy)
@@ -293,9 +293,7 @@ static const svn_token_map_t kind_map[] = {
of all the status values. */
static const svn_token_map_t presence_map[] = {
{ "normal", svn_wc__db_status_normal },
- /* ### "absent" is the former name of the "server-excluded" presence.
- * ### We should change it to "server-excluded" with a format bump. */
- { "absent", svn_wc__db_status_server_excluded },
+ { "server-excluded", svn_wc__db_status_server_excluded },
{ "excluded", svn_wc__db_status_excluded },
{ "not-present", svn_wc__db_status_not_present },
{ "incomplete", svn_wc__db_status_incomplete },