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

Re: SVN 1.7 - can delete external files

From: Florin Avram <florin_at_sync.ro>
Date: Mon, 08 Apr 2013 12:22:54 +0300

On 08.04.2013 11:01, Daniel Shahaf wrote:
> [CC += dev@, so fullquote; please drop users@ on replies]
> Florin Avram wrote on Mon, Apr 08, 2013 at 08:51:30 +0300:
>> On 05.04.2013 17:41, Stefan Sperling wrote:
>>> On Fri, Apr 05, 2013 at 05:12:10PM +0300, Syncro SVN Client Support wrote:
>>>> Hi,
>>>> I found that you can delete external files with SVN 1.7, which
>>>> should not be allowed. Below are some test I've done with SVN 1.6
>>>> and SVN 1.7 over external files and directories.
>>>> *I.**external file*
>>>> *1.**SVN 1.6* - neither "svn delete external.txt" or "svn delete
>>>> --keep-local external.txt" work (which is fine, according with the
>>>> SVN Book).
>>>> svn: E155030: Cannot remove the file external at 'external.txt';
>>>> please propedit or propdel the svn:externals description that
>>>> created itII. external dir
>>>> *2**. SVN 1.7.8* - "svn delete external.txt" throws same error (OK).
>>>> But, "svn delete --keep-local" works, file is removed and the
>>>> EXTERNAL status is lost.
>>>>> svn delete --keep-local external.txt
>>>> D external.txt
>>>>> svn status external.txt
>>>> D external.txt
>>>>> svn status . (on parent directory)
>>>> D external.txt
>>>>> svn commit -m "test" external.txt
>>>> Deleting external.txt
>>>> Committed revision 3128.
>>>> *
>>>> **II**.**external dir*
>>>> SVN 1.6.17 allows deleting external directories, but SVN 1.7 denies
>>>> deletion of external directories (an error like "cannot delete the
>>>> root of a working copy").
>>>> In the end, I assume "svn delete" should not work for an external
>>>> item, ignoring the SVN version, the item type (file or dir) and any
>>>> option for delete (like --force or --keep-local), no?
>>>> Regards,
>>>> Florin
>>> Yes, I agree.
>>> The trunk code had the same issue, but with slightly different output.
>>> Fixed in http://svn.apache.org/r1464992
>>> Do you think this is an important enough issue to warrant a backport to 1.7?
>> Hi,
>> Well, I don't know how often this situation can be seen, so it is up to
>> you (SVN developers) to decide what to do (I just signaled the issue).
> What happens after someone deletes (or deletes-and-commits) a file
> external? Would revert+cleanup restore the working copy to a valid
> state, or would he need to checkout a fresh wc?
> Daniel
>> Regards,
>> Florin

Another thing to have in sight: what happens if deleting a directory
containing EXTERNAL items?!
Testing with SVN 1.7.8, items are reported as DELETED and the EXTERNAL
state is lost, so, again, I can delete (and commit as deleted) EXTERNAL

And a last thing, regarding SWITCHED items: shouldn't they be treated
same as EXTERNAL ones in what regards the "svn delete" command?
What I mean is that either you delete and EXTERNAL item or a SWITCHED
item, you will commit (and remove from repository) an item which is not
from the branch you work on, but from a different location of the
repository (or a different repository, for EXTERNAL dirs).
Furthermore, deleting and committing a SWITCHED item can confuse you if
you don't pay attention: after committing it as deleted, and doing an
update on the parent directory, you get it back on your working copy,
but this time it is from the branch you work on (the original URL). And
you ask yourself: "Didn't I already deleted this item?!"

Looking at what happens with both SVN 1.6 and SVN 1.7, my conclusion is
that it should be better if "svn delete" should never work for EXTERNAL
and SWITCHED items (and only for them), but should work for their
children (since you can see the parent is from another repository
location). This is due to the fact that "svn delete" is a "destructive"
operation and should be performed only for items being on the same
branch as their parent directory (make users aware about where they work).
Consequently, replacing EXTERNAL and SWITCHED items would not be allowed.
Received on 2013-04-08 11:23:29 CEST

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

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