You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2009/08/17 16:44:10 UTC
[PATCH] wc-ng task: Remove svn_wc_entry_t's obtained only to find
svn_node_kind_t.
wc-ng gurus:
While trying (fruitlessly) to track down a switch test segfault last
Friday I noticed that in several places we grab an svn_wc_entry_t
simply so we can find a path's svn_node_kind_t. This seems like an
obvious place to get rid of some entry structures, so here's a stab at
doing just that.
The only seeming difficulty/question in this task is deciding how we
map svn_wc__db_kind_t to svn_node_kind_t. The attached patch takes
this approach:
svn_wc__db_kind_dir (not hidden*) --> svn_node_dir
svn_wc__db_kind_dir (hidden*) --> svn_node_none
svn_wc__db_kind_file (not hidden*) --> svn_node_file
svn_wc__db_kind_file (hidden*) --> svn_node_none
svn_wc__db_kind_symlink --> svn_node_unknown
svn_wc__db_kind_unknown --> svn_node_unknown
svn_wc__db_kind_subdir --> svn_node_unknown
* As per svn_wc__db_node_hidden(). This is necessary because
svn_wc__db_check_node() might report that a path is a
svn_wc__db_kind_dir or svn_wc__db_kind_file, when in fact the path has
been deleted. This can happen if the path's parent is at an revision
at which the child path was not deleted.
Does that seem correct?
Debug build of trunk@38776 [ra_local] x [fsfs] passes all tests on Windows.
Paul
[[[
Stop getting svn_wc_entry_t's when all we want to know is the svn_node_kind_t.
* subversion/include/private/svn_wc_private.h
(svn_wc__node_get_kind): New.
* subversion/libsvn_wc/node.c
(svn_wc__node_get_kind): New.
* subversion/libsvn_client/export.c
(copy_versioned_files):
* subversion/libsvn_client/switch.c
(svn_client__switch_internal):
* subversion/libsvn_client/update.c
(svn_client__update_internal):
Remove calls to svn_wc__get_entry_versioned() or svn_wc_entry() when the
entry obtained is used only to determine svn_node_kind_t, use
svn_wc__node_get_kind() instead.
* subversion/libsvn_client/merge.c
(calculate_merge_inheritance): Remove entry parameter, add scratch_pool
parameter, and get kind with svn_wc__node_get_kind().
(get_mergeinfo_paths): Remove call to svn_wc__get_entry_versioned() and
update call to calculate_merge_inheritance().
]]]
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2384431
Re: [PATCH] wc-ng task: Remove svn_wc_entry_t's obtained only to
find svn_node_kind_t.
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Aug 18, 2009 at 4:52 AM, Greg Stein<gs...@gmail.com> wrote:
> On Mon, Aug 17, 2009 at 18:44, Paul Burba<pt...@gmail.com> wrote:
>> wc-ng gurus:
>>
>> While trying (fruitlessly) to track down a switch test segfault last
>> Friday I noticed that in several places we grab an svn_wc_entry_t
>> simply so we can find a path's svn_node_kind_t. This seems like an
>> obvious place to get rid of some entry structures, so here's a stab at
>> doing just that.
>>
>> The only seeming difficulty/question in this task is deciding how we
>> map svn_wc__db_kind_t to svn_node_kind_t. The attached patch takes
>> this approach:
>>
>> svn_wc__db_kind_dir (not hidden*) --> svn_node_dir
>> svn_wc__db_kind_dir (hidden*) --> svn_node_none
>> svn_wc__db_kind_file (not hidden*) --> svn_node_file
>> svn_wc__db_kind_file (hidden*) --> svn_node_none
>> svn_wc__db_kind_symlink --> svn_node_unknown
>> svn_wc__db_kind_unknown --> svn_node_unknown
>> svn_wc__db_kind_subdir --> svn_node_unknown
>>
>> * As per svn_wc__db_node_hidden(). This is necessary because
>> svn_wc__db_check_node() might report that a path is a
>> svn_wc__db_kind_dir or svn_wc__db_kind_file, when in fact the path has
>> been deleted. This can happen if the path's parent is at an revision
>> at which the child path was not deleted.
>>
>> Does that seem correct?
>
> Some of the calls to svn_wc_entry() or get_entry_versioned() pass
> show_hidden=TRUE, so the mapping to none shouldn't be done for those
> cases.
>
> Also, db_kind_symlink would map to wc-1's svn_node_file.
>
>>...
>
> Cheers,
> -g
Thanks for the look Greg. I added a show_hidden arg to
svn_wc__node_get_kind() and also mapped b_kind_symlink to
svn_node_file. Committed r38830.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2385038
Re: [PATCH] wc-ng task: Remove svn_wc_entry_t's obtained only to
find svn_node_kind_t.
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 17, 2009 at 18:44, Paul Burba<pt...@gmail.com> wrote:
> wc-ng gurus:
>
> While trying (fruitlessly) to track down a switch test segfault last
> Friday I noticed that in several places we grab an svn_wc_entry_t
> simply so we can find a path's svn_node_kind_t. This seems like an
> obvious place to get rid of some entry structures, so here's a stab at
> doing just that.
>
> The only seeming difficulty/question in this task is deciding how we
> map svn_wc__db_kind_t to svn_node_kind_t. The attached patch takes
> this approach:
>
> svn_wc__db_kind_dir (not hidden*) --> svn_node_dir
> svn_wc__db_kind_dir (hidden*) --> svn_node_none
> svn_wc__db_kind_file (not hidden*) --> svn_node_file
> svn_wc__db_kind_file (hidden*) --> svn_node_none
> svn_wc__db_kind_symlink --> svn_node_unknown
> svn_wc__db_kind_unknown --> svn_node_unknown
> svn_wc__db_kind_subdir --> svn_node_unknown
>
> * As per svn_wc__db_node_hidden(). This is necessary because
> svn_wc__db_check_node() might report that a path is a
> svn_wc__db_kind_dir or svn_wc__db_kind_file, when in fact the path has
> been deleted. This can happen if the path's parent is at an revision
> at which the child path was not deleted.
>
> Does that seem correct?
Some of the calls to svn_wc_entry() or get_entry_versioned() pass
show_hidden=TRUE, so the mapping to none shouldn't be done for those
cases.
Also, db_kind_symlink would map to wc-1's svn_node_file.
>...
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2384669