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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-11 16:42:20 CEST