Philip, maybe you can give me a clue...
I'm almost done with issue #1090, whose goal is to make
svn_client_copy(URL, wc) notice different repository UUIDs. If the
UUIDs are different, then svn_wc_add() is called sans copyfrom history
(i.e. it's just a normal scheduled addition, not a scheduled copy.)
I'm witnessing some very strange behavior.
I have a situation where a directory ("boobah") from a foreign
repository has been exported into my current working copy (".") after
running 'svn cp URL .'. By "exported", I simply mean that all .svn/
areas have been removed from the checkout. repos_to_wc_copy() then
calls svn_wc_add(), intending to schedule the unversioned tree for
normal recursive addition.
svn_wc_add() is calling svn_wc_entry("boobah", parent_access) near the
very beginning. When I look at parent_access, it indeed represents
".", and I expect to get a NULL entry back.... because boobah is
definitely not an entry within ".". In fact, boobah is totally
unversioned.
Here's what happens, though: svn_wc_entry("boobah", parent_access)
starts out by calling svn_wc_adm_retrieve(). That function tries to
look up the path "boobah" within the access_baton's associated set and
*succeeds*. I don't understand why, since boobah is unversioned:
(gdb) p **adm_access
$14 = {path = 0x821a900 "boobah", type = svn_wc__adm_access_write_lock,
lock_exists = 1, set_owner = 0, wc_format = 2, set = 0x821a7b0,
entries = 0x821a9b8, entries_deleted = 0x821a9b8, pool = 0x8119018}
How is it possible to have a lock on an unversioned directory?
Stranger still... if I run 'svn add boobah' from the commandline and
do the same gdb trace, svn_wc_adm_retrieve() does what I expect. That
is, it can't find 'boobah' in the parent baton's associated set.
Do you have any ideas here? Am I misunderstanding something?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 31 21:36:17 2003