You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Rui, Guo" <ti...@mail.ustc.edu.cn> on 2008/07/11 14:41:50 UTC
Behavior of svn remove on sparse directory.
Hi all,
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?
Thanks.
Rui
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by Karl Fogel <kf...@red-bean.com>.
"Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
> Never mind. But, please take sometime to fill in the mid term evaluation of
> gsoc if you have not done it yet.
I did it the first day it went online, no need to worry :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
On Fri, Jul 11, 2008 at 12:21:09PM -0400, Karl Fogel wrote:
> "Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
> > 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.
>
> Yes. Interface conservatism, basically :-).
>
> By the way, Guo Rui, I have seen your recent commits. I'm still plowing
> through issue #2489, but you're next on my list.
Never mind. But, please take sometime to fill in the mid term evaluation of
gsoc if you have not done it yet. According to the timelime, this should be
done before 14th.
Rui
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by Karl Fogel <kf...@red-bean.com>.
"Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
> 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.
Yes. Interface conservatism, basically :-).
By the way, Guo Rui, I have seen your recent commits. I'm still plowing
through issue #2489, but you're next on my list.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by David Glasser <gl...@davidglasser.net>.
On Mon, Jul 14, 2008 at 7:13 AM, C. Michael Pilato <cm...@collab.net> wrote:
> 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)?
I think that would be a good idea, since currently there's no nice
(recursive) way to find out "what stuff in my working copy isn't
depth=infinity", but if it's in "svn status", it should require some
extra --show-shallow flag to display. Otherwise we're replicating the
ugliness of externals where a perfectly normal part of your long-term
wc setup shows up in every single 'svn status' forever.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jul 14, 2008 at 10:13 AM, C. Michael Pilato <cm...@collab.net> wrote:
> 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)?
I'd just point out that even with a fully populated and up to date
subtree, a user could still delete a folder that other users did not
want them to delete. That is the great thing about version control,
no data is lost, the operation is full recoverable.
My objection is only that I do not feel this is worthy of special UI
or even special documentation in the book. The result of the svn rm
command matches any reasonable expectation of what should happen in
that situation.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> "Rui, Guo" <ti...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Behavior of svn remove on sparse directory.
Posted by Karl Fogel <kf...@red-bean.com>.
"Rui, Guo" <ti...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jul 11, 2008 at 11:50 AM, Rui, Guo <ti...@mail.ustc.edu.cn> wrote:
> On Fri, Jul 11, 2008 at 10:47:26AM -0400, Mark Phippard wrote:
>> Additionally, someone may have specifically used the sparse
>> directories feature so that they could do this sort of operation
>> without having to checkout a bunch of files and subdirectories.
> If you really want to rm the whole tree, just do it directly on the repository
> side. I don't think your sparse directory solution for this use case is better
> than direct repository operation.
A lot of Subversion users are very hung up on doing all related tasks
in one revision. You might want to combine the delete with some other
changes and do it in a single transaction.
All that said, I did not mean to use this example as the rationale for
my objection. My objections is merely that I think your solution is
worse than the problem it is trying to solve. I do not really think
there is a problem in this case.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
On Fri, Jul 11, 2008 at 10:47:26AM -0400, Mark Phippard wrote:
> Additionally, someone may have specifically used the sparse
> directories feature so that they could do this sort of operation
> without having to checkout a bunch of files and subdirectories.
If you really want to rm the whole tree, just do it directly on the repository
side. I don't think your sparse directory solution for this use case is better
than direct repository operation.
Rui
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
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 <ti...@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 <ti...@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 <ti...@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@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Jul 11, 2008 at 12:04 PM, Rui, Guo <ti...@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 <ti...@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 <ti...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
On Fri, Jul 11, 2008 at 11:17:28AM -0400, Mark Phippard wrote:
> On Fri, Jul 11, 2008 at 11:10 AM, Rui, Guo <ti...@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 <ti...@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.
Rui
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jul 11, 2008 at 11:10 AM, Rui, Guo <ti...@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 <ti...@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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
On Fri, Jul 11, 2008 at 10:47:26AM -0400, Mark Phippard wrote:
> On Fri, Jul 11, 2008 at 10:41 AM, Rui, Guo <ti...@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.
Rui
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behavior of svn remove on sparse directory.
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jul 11, 2008 at 10:41 AM, Rui, Guo <ti...@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?
Additionally, someone may have specifically used the sparse
directories feature so that they could do this sort of operation
without having to checkout a bunch of files and subdirectories.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org