"Rui, Guo" <timmyguo_at_mail.ustc.edu.cn> writes:
> 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.
I'm reviewing the commits now. Thanks!
> 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.
No, I think it's all right. A parent directory can be depth-empty yet
still have certain entries (subdirectories or files) included on
purpose. In the command you gave, target should stay, but be at
depth-empty itself.
This does raise the question of how to get target to go away
completely. One way would be to have a new depth word "absent"; it
wouldn't necessarily need a corresponding svn_depth_absent enum, it
could just be parsed by the client, which would then DTRT.
I'm just speculating; I haven't looked at the code yet.
> 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'.
I'm not sure I understood this. Do you mean that an update is actually
happening (that is, the repository is being contacted)?
> 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?
We should do whatever 'svn up' normally does. If it prints 'D', then
that's what we should do here, I think.
-Karl
---------------------------------------------------------------------
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 18:10:04 CEST