David Glasser wrote:
> This also raises an interesting question:
>
> UI-wise, one of the reasons that we didn't implement "depth shrinking"
> was that it just fundamentally didn't work with "svn up --depth".
> However, given "--new-depth" or "--set-depth", the UI for "depth
> shrinking" is obvious. So should we support it in 1.5? Note that
> this is non-trivial; we have to figure out what we do with the files
> on disk (delete them? leave them there in '?' mode?), if local mods
> affects it, etc.
>
> My vote: depth shrinking is definitely not a branch blocker and
> probably not a release blocker. If somebody happens to implement it
> in a solid way that addresses the above concerns well, then no
> complaints here, but it shouldn't be a short-term goal.
>
> --dave
In fact, this lack of support for ambient depth reduction was one of the
reasons I wanted to have both a --depth and a --new-depth for 'svn update'.
How surprising it would be for a user who has finally gotten the hang of
using 'svn update --depth' instead of 'svn update --non-recursive' to
upgrade from 1.5 to 1.6 and find that suddenly his shallow updates aren't
just operational scope limitations -- they start throwing away parts of his
working copy!
Implied in my previous paragraph is the timeline in which I expect to see
depth shallowing implemented: post-1.5. And I'm totally cool with that. In
fact, this change makes it much easier to raise a meaningful not-supported
error where such a depth reduction is requested.
-- C-Mike
PS: I like --set-depth better, too, and will make the change.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-01-14 16:31:15 CET