On Tue, Aug 18, 2009 at 4:52 AM, Greg Stein<gstein_at_gmail.com> wrote:
> On Mon, Aug 17, 2009 at 18:44, Paul Burba<ptburba_at_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
> Also, db_kind_symlink would map to wc-1's svn_node_file.
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.
Received on 2009-08-19 01:19:19 CEST