> -----Original Message-----
> From: Paul Burba [mailto:ptbu...@gmail.com]
> Sent: woensdag 22 februari 2012 17:42
> To: Nico Kadel-Garcia
> Cc: Philip Martin; C. Michael Pilato; Subversion Development; Alexey 0
> Moudrick; users@subversion.apache.org
> Subject: Re: Issue report: subversion 1.7.2 windows command line client
> cannot copy URL -> WC if URL contains externals
>
> On Fri, Feb 17, 2012 at 12:46 PM, Nico Kadel-Garcia <nka...@gmail.com>
> wrote:
> > On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin
> > <philip.mar...@wandisco.com> wrote:
> >> Paul Burba <ptbu...@gmail.com> writes:
> >>
> >>> I'm able to replicate this failure on my Windows box with my own
> >>> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
> >>> expected with 1.6.17, so this appears to be a regression. Moving back
> >>> to the dev list.
> >>>
> >>> Investigating...
> >>
> >>>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
> >>>> 'C:\t\wc\externals-container-copy': Access is denied.
> >>
> >> I suspect this is a directory move. Perhaps the wc.db file of the
> >> external is still open? Can a directory be renamed on Windows when one
> >> of the files inside it is still open?
> >
> > Not in my experience.
>
> I added an issue for this:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4123
> and a test also:
> http://svn.apache.org/viewvc?view=revision&revision=1292090
>
> The attached patch fixes this problem on Windows. Could any wc-ng
> gurus take a look and see if this seems reasonable?
>
> [[[
> Fix issue #4123 'URL-to-WC copy of externals fails on Windows'.
>
> * subversion/include/private/svn_wc_private.h
> (svn_wc__externals_close): New declaration.
>
> * subversion/libsvn_wc/externals.c
> (svn_wc__externals_close): New definition.
>
> * subversion/libsvn_client/copy.c
> (repos_to_wc_copy_single): Use new function to close handles to
> externals' DB files before trying to rename the whole temp WC.
>
> * subversion/tests/cmdline/externals_tests.py
> (url_to_wc_copy_of_externals): Remove XFail decorator and update
> comments
> re failure status.
> ]]]
I don't think the code should be conditional for Windows. On other platforms we
should also close databases that we are about to move as our references to it
(via abspath) are no longer valid anyway. (And who knows what sqlite does with
the path internally...)
I don't know what svn_wc__db_drop_root() does exactly, but the code should also
flush some of the svn_wc__db_t internal state which maps abspaths to db handles.
It might even be easier to resolve this problem this way: just release all
databases below a specific path?
Bert
>
> Even with this fix I'm still seeing odd behavior post-copy (the
> following example uses a WC-to-WC copy, but the same problem occurs
> with a URL-to-WC copy):
>
> ### We have a working copy at a uniform revision with an external:
>
> >svn up -q
>
> >svn st
> X A\C\external
>
> Performing status on external item at 'A\C\external':
>
> >svn pl -vR
> Properties on 'A\C':
> svn:externals
> ^/A/D/G external
>
> ### We copy the directory with the external definition:
>
> >svn copy A/C WC-to-WC-Copy-of-C
> A WC-to-WC-Copy-of-C
>
> ### But the external shows up as unversioned:
>
> >svn st
> X A\C\external
> A + WC-to-WC-Copy-of-C
> ? WC-to-WC-Copy-of-C\external
>
> Performing status on external item at 'WC-to-WC-Copy-of-C\external':
>
> Performing status on external item at 'A\C\external':
>
> ### Even if we commit an update the WC we see the same problem:
>
> >svn ci -m ""
> Adding WC-to-WC-Copy-of-C
>
> Committed revision 3.
>
> >svn up
> Updating '.':
>
> Fetching external item into 'WC-to-WC-Copy-of-C\external':
> External at revision 3.
>
>
> Fetching external item into 'A\C\external':
> External at revision 3.
>
> At revision 3.
>
> >svn st
> X A\C\external
> ? WC-to-WC-Copy-of-C\external
>
> Performing status on external item at 'WC-to-WC-Copy-of-C\external':
>
> Performing status on external item at 'A\C\external':
>
> >
>
> To fix this we need to remove the external via the OS then update to
> restore it (note that this problem occurs without my patch applied, so
> this is a separate issue).
>
> Paul
