Hi Paul,
Thanks for your concern. I think I have been persuaded by all of you.
Rui
On Fri, Jul 11, 2008 at 12:08:37PM -0400, Paul Burba wrote:
> 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
>
---------------------------------------------------------------------
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:23:17 CEST