[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals

From: Paul Burba <ptburba_at_gmail.com>
Date: Wed, 22 Feb 2012 11:42:04 -0500

On Fri, Feb 17, 2012 at 12:46 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin
> <philip.martin_at_wandisco.com> wrote:
>> Paul Burba <ptburba_at_gmail.com> writes:
>>
>>> I'm able to replicate this failure on my Windows box with my own
>>> builds of trunk_at_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.
]]]

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

Received on 2012-02-22 17:42:40 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.