a potential bug in svn_wc__db_wcroot_parse_local_abspath

Hello!

I've found a potential bug in
svn_wc__db_wcroot_parse_local_abspath
function.

Suppose the following directories structure:

working_copy_root
    |
   +----nested_working_copy_root
   +----not_versioned_symlink

Suppose also that not_versioned_symlink points to "nested_working_copy_root".

I want to find the working copy root to which "not_versioned_symlink" belongs, so I call
"svn_wc__db_wcroot_parse_local_abspath" with a path to "not_versioned_symlink".

There're 2 options.
1. if the cache (db->dir_data in this function) is empty the function will check the symlink's
parent (i.e. "working_copy_root") and will call "svn_wc__db_read_info_internal" on it,
so that "retry_if_dir" variable will be set to TRUE,
and "not_versioned_symlink" will be eventually found as working copy root (because it points to a
working copy root).

2. But if the cache already contains a record about "working_copy_root", the function will check the
symlink's parent (i.e. "working_copy_root"), discover it in the cache, and hence return
"working_copy_root" as a resulting root.

So the function depends on the cache contents.
The only reason why "svn add" find the correct (in the context of addition) root (i.e.
"working_copy_root") is that a record about "working_copy_root" gets into the cache while obtaining
a lock on "working_copy_root", so it's just a luck. And btw "svn info not_versioned_symlink" thinks
that "not_versioned_symlink" itself is a working copy, not "working_copy_root".

The question is what's the expected working copy root should this function return on this example?

To my opinion, it should return "not_versioned_symlink" without regarding the cache contents,
because the most of the commands (except "svn add") expect this behaviour. For "svn add" there
should be another code that processes symlink case separatedly.

Unfortunately I can't provide a reproducing code now, but I hope the algorithm's authors will easily
understand what I am writing about.
Received on 2012-03-14 21:54:24 CET