Ben Collins-Sussman <sussman@collab.net> writes:
> Philip, maybe you can give me a clue...
Are you copying from HEAD? Does it work if you specify a numeric
revision?
> 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.
If there are access batons open when the .svn/ directories are
deleted, the deletion will not close the batons.
> 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?
The current repos_to_wc_copy uses the checkout editor to retrieve the
new directory from the repository. The checkout editor will open
access batons as the checkout proceeds and should close these when the
editor's close_edit method is called. If you are copying from HEAD I
see that the the current repos_to_wc_copy then opens another set of
access batons on the new directories in order to get the the
src_revnum, and these access batons are not closed explicitly. It
also looks like svn_wc_add might ignore the existing access batons if
copyfrom history is passed in, but svn_wc_add is extremely complicated
and I have never really understood all the tests it makes or doesn't
make.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 31 23:41:56 2003