Hi all,
I have a preliminary implementation of the deselection interface now, in the
issue-2843-dev branch. The current state is like this: The code passes two
test case suites (out of four). It should work in most situations while may
fail at some corner cases. You can try it out using the usual 'svn up
--set-depth' interface. I may provide a separate interface that performs local
operation only when the code is more stable later.
Any comment will be appreciated.
There are two known problems left in current state.
1. I designed the cropping logic to remove the target itself when the
requested depth is empty and the parent does not require sub-dirs (empty or
files). On the other hand, if the parent does require sub-dirs, the target
itself will be retained. I believed that this design is reasonable. However, I
now really knock into a hard situation: What is it *REALLY* supposed to do in
the command 'svn up --set-depth=empty target' if the parent is depth-empty?
The command traditionally has the meaning of "explicitly pull in target at
depth empty". If we take the cropping into consideration, should we left the
target intact or remove it all-together? This is a semantics conflict.
The cropping logic is independent of the updating logic. And I put the
cropping logic prior to the updating logic now. As a result, the above command
will result in deleting the target first and re-add it later. This causes me
to doubt whether it is a good idea to incorporate the deselection interface
into 'svn update'.
2. When cropping the target, modified items will be removed from the revision
control but have their contents left on disk. Should I simply report a
'D' as usual in such a situation?
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-06-04 14:26:51 CEST