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

Re: Behavior of svn remove on sparse directory.

From: Rui, Guo <timmyguo_at_mail.ustc.edu.cn>
Date: Sat, 12 Jul 2008 00:18:39 +0800

On Fri, Jul 11, 2008 at 12:01:32PM -0400, Karl Fogel wrote:
> 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).
The mistake may remain unawared until the remove is propgate to other
developers through update. They may surprisingly find that their working
directory is gone with only some local modifications left behind.

Annoying? But yes, no data is actually lost. And I don't think this will
become a widespread problem, since this is not a typical use case to remove a
large sparse tree. So, maybe you are right. Just leave things intact right
now and wait for the user feedback.

Rui

---------------------------------------------------------------------
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:18:55 CEST

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

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