On Wed, Mar 3, 2010 at 12:52 PM, Giulio Troccoli
> Linedata Services (UK) Ltd
> Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
> Registered in England and Wales No 3027851 VAT Reg No 778499447
> -----Original Message-----
>> From: Andy Levy [mailto:andy.levy_at_gmail.com]
>> Sent: 03 March 2010 11:31
>> To: Giulio Troccoli
>> Cc: users_at_subversion.apache.org
>> Subject: Re: Update failed with "is not a working copy"
>> message on externals
>> On Wed, Mar 3, 2010 at 05:14, Giulio Troccoli
>> <Giulio.Troccoli_at_uk.linedata.com> wrote:
>> > Hello,
>> > We are starting using externals to publish some
>> documentation for our customer. The repository contains test
>> files and documentation about the testing. Some of these
>> files and docs need to be made available to our customer. So
>> I thought of creating a Public folder and define the
>> svn:external property to pull down only the bits that we need.
>> > As part of the process however we decided to also reorganise the
>> > documents, especially because some of the original file are buried
>> > into 5 or more directories. An example of svn:external would be
>> > ^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/5.11.23
>> > 5.31/5.11.23
>> > This works very well, creating the 5.31 and 5.11.23
>> directories. However, if we want to pull down a single file, e.g.
>> "5.31/basic data cleansing/End To End _basic data cleansing.xls"
>> > then svn update fails with the message
>> > Fetching external item into '5.31\basic data cleansing\End
>> To End _basic data cleansing.xls'
>> > svn: warning: '5.31\basic data cleansing' is not a working copy
>> > I thought I couldn't pull down a single file but only
>> directories but
>> > the manual says I can, and if I change the external as
>> "End To End _basic data cleansing.xls"
>> > then the file is retrieved.
>> > I have looked in the archive and the only related message I
>> found is a
>> > very old one about subversion 1.2.3
>> > http://svn.haxx.se/tsvnusers/archive-2005-12/0068.shtml
>> > So, it seems to me this is a bug. I was able to write a
>> little ksh script (attached) to reproduced the problem.
>> Not only does it seem like a bug, it seems like this one.
> I don't know about that. I tried the reproduction script at the top of that bug report and it works, which is not surprising since the report says it has been fixed in 1.6.6 (and I'm using 1.6.9).
The problem is that you're using file externals combined with putting
the external locally in a directory which is not already a working
copy. That's not supported for file externals.
Somewhere near the end it says:
While directory externals can place the external directory at any
depth, and any missing intermediate directories will be created, file
externals must be placed into a working copy that is already checked
So I don't think this really qualifies as a bug, more as a "known
limitation" (possibly there is already some "enhancement" request in
the issue tracker for this, but I haven't looked). The reason for this
limitation is probably that file externals are implemented quite
differently from directory externals (file externals are implemented
internally with the "switch" functionality, so that's probably why it
needs a working copy directory to begin with).
I guess you have a couple of options:
- use a dir external instead of a file external
- put the file external locally directly under the current dir (which
is already a working copy path), or in a subdir of which you are sure
that it's already a working copy path
- "enhance" subversion to support this :)
Received on 2010-03-03 14:00:33 CET