[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 'svn update --depth'

From: David Glasser <glasser_at_davidglasser.net>
Date: Mon, 14 Jan 2008 18:04:42 -0500

On Jan 14, 2008 5:46 PM, Branko ╚ibej <brane_at_xbc.nu> wrote:
>
> C. Michael Pilato wrote:
> > 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.
>
> Just trying to understand what would happen in a partially-checked-out
> working copy; say we checked out with --depth=3, making that sticky. If
> we introduce a --set-depth option for update, then on such a working
> copy, I'd expect "svn up --depth=4" and "svn up --set-depth=4" do behave
> differently -- the first would effectively ignore the depth param and
> not add new items, the second would change the sticky depth. In other
> words, one would use --set-depth for both depth reduction and depth
> extension.
>
> Is that right?

Yes. However, the former wouldn't be *completely* ignored. Imagine
that we have:

wc/ at depth empty
wc/A at depth infinity

then you could do

$ svn up wc --depth=immediates

which would update properties on A without changing any depths. This
(arguably contrived and pointless) scenario wasn't possible before.

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
Received on 2008-01-15 00:05:10 CET

This is an archived mail posted to the Subversion Dev mailing list.