Re: Behavior of svn remove on sparse directory.

Karl Fogel wrote:
> "Rui, Guo" <timmyguo_at_mail.ustc.edu.cn> writes:
>> I'm just considering the behavior of 'svn remove' on sparse directory
>> and find something bad in it. I just demonstrate the problem first.
>>
>> svn co --depth empty http://server/greek_tree wc
>> cd wc
>> svn up --depth files A
>> svn rm A
>>
>> In this example, I have a partial copy of A directory in the greek
>> tree. And then I remove the directory A. After commit, the entire A
>> tree will gone. This seems nature at first. However, after a second
>> thought, the remove operation will affect more than user can see,
>> which is quite dangerous. I know that nothing is really unrecoverable
>> in the circumstance of version management. But I think it will not be
>> a good user experience for the user to find out that him did something
>> bad just because subversion opened the dangerous door and did not
>> remind him.
>>
>> A more graceful way to handle this is just warn the user about
>> possible lost of additional data and let the user proceed by providing
>> a --force option. However, current implementation of sparse directory
>> can not figure out whether the remove operation will affect more items
>> than users can see, without communicate with the server, since the
>> working copy just do not bookkeeping items that reside in the
>> repository only.
>>
>> In the situation of excluded subtree, there will be an entry with
>> exclude flag in the working copy, which can serve as an indication of
>> dangerous remove operation. A more conservative way is to warn the
>> user whenever the wc depth is less than infinity.
>>
>> So, do you think what I'm arguing about is reasonable?
>
> I think you're right to be concerned, but in the end, the best behavior
> is probably to just remove the tree. The alternatives are worse:
>
> - Prompt the user with a question to which the answer will be, 90% of
> the time, "yes".
>
> - Disallow it, and force the user to do the operation on a URL.
>
> - Allow it but print a warning, which will only confuse most users.
>
> Meanwhile, what is the worst that can happen if we just do the removal
> the usual way? Someone removes more data in the repository than they
> expected to, learns it was a mistake, and reverts the change :-).
>
> The data will not be really lost. Meanwhile, users who remove sparse
> directories and later regret it will learn. Finally, if this problem
> turns out to be widespread, we can always add a config option later to
> warn or request confirmation (though the default should be off).
>
> So, I think the best thing is just to allow the removal as usual,
> because this is, after all, a version control system.

I'd just like to say first that I appreciate Rui's attention to detail and
forethought on this matter. This project values users' data, and values
those that value users' data.

I agree that there is a potential here for frustration. It's not hard to
imagine a scenario in which a user has a sparse directory containing a few
things he (and he alone) is working on, but whose repository reflection
contains quite a bit more. Then -- having decided one day not to work on
those things any more, and having been using this directory for so long that
he forgets it *really* has additional citizens -- he deletes the directory,
to the chagrin of his peers.

(Unless I'm mistaken, the same thing can happen today with directories that
are missing members due to authz restrictions.)

That said, I mostly agree that disallowing 'svn rm' might be a step too far
in the conservative direction (though I'm not fully convinced of it). So
would there be any value to having the Book and 'svn rm's' usage message
pointing out that you should be careful when using it on a directory that is
sparsely populated? Or how about a status indication that denotes sparsely
populated subtrees (depth!=infinity)?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand