On Fri, Jul 11, 2008 at 12:04 PM, Rui, Guo <timmyguo_at_mail.ustc.edu.cn> wrote:
> On Fri, Jul 11, 2008 at 11:17:28AM -0400, Mark Phippard wrote:
>> On Fri, Jul 11, 2008 at 11:10 AM, Rui, Guo <timmyguo_at_mail.ustc.edu.cn> wrote:
>> > On Fri, Jul 11, 2008 at 10:47:26AM -0400, Mark Phippard wrote:
>> >> On Fri, Jul 11, 2008 at 10:41 AM, Rui, Guo <timmyguo_at_mail.ustc.edu.cn> wrote:
>> >>
>> >> > 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.
>> >>
>> >> I personally do not agree this is a problem. If a user removes a
>> >> directory, what other expectation would they possibly have?
>> > He would probably just want to remove the files in that wc directory and
>> > forget that there are many more hidden in the repository. This may happen if
>> > he has been using the wc structure for a long time.
>>
>> Don't you think we might be "overthinking" this problem if we are
>> going to start doing things like telling the user "I know you told me
>> to delete these files, but I am not convinced you really want to do
>> that, so I am not going to. Use --force to tell me you really meant
>> it"
>>
>> I understand the problem you want to solve, but I think your solution
>> is worse than the problem and I am not sure the problem is truly
>> solvable. I also start thinking about graphical environments and
>> there are times where we want to run API's in response to some
>> action/event and not interrupt the user with additional UI. If I
>> cannot rely on delete doing a delete, then I either have to always add
>> the --force option when I call the API, or I do have to interrupt the
>> user with extra UI.
>>
>> I just do not think this problem rises to the level of something we
>> need to try to solve.
> You just worry about the safeguard will be interruptive. I understand your
> consideration. But I have to clarify that what I'm worrying about would not
> become a common use case. I think the sparse tree will typically happens near
> the wc root, or at least not within a set of logical coupled items. So, the
> user should not knock into the warning frequently during normal daily
> development.
Hi Rui,
I have to agree with Mark and Karl here. I think this falls into the
broad category of "bugs and desired enhancements" where we are trying
to think for the user rather than just doing what they asked. Now if
what they ask can do irreversible damage or recovering from it
requires Herculean efforts, then yes, we should warn them or otherwise
put in some sort of safety net. That is simply not the case here no?
Paul
---------------------------------------------------------------------
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:08:51 CEST