sorry, forgot to reply-all
-Brad
-------- Original Message --------
Subject: Re: delete dir shows deleted files
Date: Fri, 18 Aug 2006 14:51:24 -0400
From: Brad Kittenbrink <brad@windwardmark.net>
To: Martin Furter <mf@rola.ch>
References: <Pine.BSO.4.62.0608181805140.1702@uruz.rola.ch>
<44E5EB58.6070905@windwardmark.net>
<Pine.BSO.4.62.0608181837210.1702@uruz.rola.ch>
Martin Furter wrote:
> But that's not what I'm complaining about. I also like that it shows
> which files it deletes. What I was wondering is why it is able to
> delete a file twice.
>
> Your version of the script shows the following output:
>
> status before delete dir
>
> D a/file2.txt
> D a/file1.txt
> A + b/file2.txt
>
> delete dir
>
> D a/file2.txt
> D a/file3.txt
> D a/file1.txt
> D a
>
> But file1.txt and file2.txt were already deleted so I would not expect
> them to show up when deletting the directory.
>
That's not the way that I've understood that svn rm works. file1.txt
and file2.txt were not deleted; they were marked as pending deletions
which will be deleted from the repository on the next commit. (Yes I
know that files do get deleted from the visible area of the working
copy, but if you peek into the .svn dirs, you'll see that there's still
a lot of work left to do in deleting those files, and directories don't
even get removed from the visible area.)
> If I do the same thing with Unix commands i get the following output:
>
>> mkdir a
>> touch a/file1.txt a/file2.txt a/file3.txt
>> rm -vf a/file1.txt
> removed `a/file1.txt'
>> rm -vf a/file2.txt
> removed `a/file2.txt'
>> rm -vrf a
> removed `a/file3.txt'
> removed directory: `a'
>
> Here the delete of the directory shows only the remaining files, the
> deleted files don't show up anymore.
>
> Shouldn't subversion do the same thing ?
>
> Martin
No, I don't think it should, because a subversion working copy is more
complicated than a plain file system (and this complication becomes
particularly evident when deleting or moving directories). It happens
to have a lot of operations that are similar to a file system, but
fundamentally its purpose is slightly different. The subversion working
copy is intended to facilitate the preparations of changesets which are
atomically applied to the repository with the svn ci command. In my
opinion, the output of svn rm should be interpreted in this context:
it's saying when you commit this action to the repository, this is what
it would cause to happen. The fact that two of your requested changes
merge into one change when committed to the repository, is potentially
confusing to the user. In the face of this potential confusion, the svn
client program errs on the side of providing more information, rather
than omitting potentially redundant information in its output, which I
think is a GoodIdea(TM).
-Brad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 18 21:02:41 2006