"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.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-11 18:01:55 CEST