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.
