On Wed, May 28, 2008 at 11:56:54AM -0400, Karl Fogel wrote:
> > Further consideration makes the crawler less optimal for the cropping
> > code either. The cropping may only happens at the target of
> > update/switch. The logic is simple and clear: crop the sub-tree
> > whenever the requested depth is shallower than the actual depth. It is
> > indeed possible to incorporate the cropping logic into the crawler, in
> > a way that provide a svn_wc_crop_to_empty() and call it at proper
> > positions of the crawler routines. However, the question is, does it
> > worth the complexity? The crawler is not designed for driving the
> > reporter, rather than cropping. [...]
>
> Did you mean the "not" in the last sentence quoted above?
Sorry, silly typo mistake. I was trying to say that the crawler is designed
for driving the reporter, which is already complex enough.
>
> > In summery, I consider the cropping procedure be rather independent to
> > update. And I would like to provide a full featured
> > svn_wc_crop_subtree() interface and call it before the crawler. This
> > solution make it easier to provide a separate cropping interface. I
> > think this is reasonable, since the user may ask: why do I have to
> > access the network/repository merely to fold the subtree for disk
> > space?
>
> Let me make sure I understand correctly: are you proposing an 'svn crop'
> subcommand?
I think I should say yes here. Since cropping the local wc does not
necessarily bundle with updating, and ideally should be a local only
operation. My analysis has led to an implementation that is relatively
independent to other part of the update logic. This can also support my
argument. However, 'svn crop', or whatever it will be called, is just a user
interface, and should be delayed until the feature is ready. Right?
>
> > ps: Do I have to log the deletion of entry before actually remove it
> > just as the do_entry_deletion() in update-editor does, or just call
> > svn_wc_remove_from_revision_control() directly? I'm not sure of this
> > yet.
>
> I think as long as you call svn_wc_remove_from_revision_control *after*
> setting the depth of the parent directory to the appropriate new depth,
> if any, it's fine. (You'll be passing the 'destroy_wf' flag, right?)
Just to be a little off topic. During the 'svn add' fix, I gained the
viewpoint that simply modify the depth of a directory entry without adjusting
the items it contains will not render the wc unusable. I mean, the depth logic
can work on it without producing error. I derived this statement from the fact
that the depth can be arbitrary mixed. Does this statement correct, or did I
missed something?
Rui, Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-29 05:36:11 CEST