subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florin Avram <flo...@sync.ro>
Subject Re: SVN 1.7 - can delete external files
Date Mon, 08 Apr 2013 09:22:54 GMT
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 
files.

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.

Mime
View raw message