Greg Hudson <ghudson@MIT.EDU> writes:
> Here's a simple reproduction recipe for a bug:
>
> % svn cp filename existing-url
>
> svn_error: #21079 : <Item already exists in filesystem>
> file `file:///var/ghudson/svn-test/grows' already exists.
> % svn cp filename existing-url
>
> svn_error: #21044 : <Attempted to lock an already-locked dir>
> working copy locked: .
>
> I thought this would be easy to fix, but I can't quite understand how
> the WC code is supposed to work. wc_to_repos_copy() grabs a write
> lock and does a pile of operations under SVN_ERR(), although a few
> operations do a "goto cleanup" instead. Why?
For wc_to_repos_copy I don't know if locks are needed at all (see
comment at line 484). Does the wc get modified? The only reason they
are there is that when I put in the new locking code there was some
old locking code. The place that releases the locks is the same as for
the old code. I suspect that both svn_wc_adm_open and
svn_wc_adm_close could be removed from that function!
> If an SVN_ERR() occurs,
> then pool_cleanup() gets a chance to clean up the access baton, but it
> chooses not to clean up physical locks. Why?
At present an explict call to svn_wc_adm_close() removes locks, and
just abandoning them to pool cleanup leaves the locks in place. There
needs to be a way to exit without removing locks, unless we always
intend to do 'svn cleanup' processing as part of lock removal. Now
it's possible that the new locking code could do this (I haven't
thought it through fully), but it doesn't yet and neither did the old
code.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 16:50:35 2002