On Wed, Jun 04, 2008 at 12:09:35PM -0400, Karl Fogel wrote:
> > 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.
Yes, this is what I meant by the "traditional meaning of svn up".
>
> 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.
I doubt this. Since the cropping logic is inside libsvc-wc, we have to define
an enum for this if we adopt this idea. However, there is a svn-depth-exclude
which may serve this purpose.
We should support svn-depth-exclude in the long term. But it has a more
restrictive semantics, which should exclude the target entirely even if the
parent is in immediates/infinity. As a result, we may need to change the
format of 'entries' file (store the exclude information inside the parent
entries) and handles it properly in the existing depth code. Seems a big job,
huh?
Let's also consider this alternative. We assign the --set-depth semantics that
it only expands the wc as it currently does. We may rename it to --expand and
leave --set-depth for compatibility. On the other hand, we also introduce a
'svn crop' or what, which dedicates to cropping. We can make 'svn crop
--set-depth empty' remove the target. If the user really need it, he/she can
just bring it back by update. This is more a workaround than a solution.
However, why don't we do it, since the code suggests that cropping has no
relevance to update in essence.
>
> > 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)?
Yes, you are right. The code can explain it more clearly.
>
> > 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.
If that is the case, we can remove the XFail() mark in the last test case now.
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-05 05:23:35 CEST