Concerns and ideas around --depth

A discussion just occurred on #svn-dev about some concerns with --depth --
it's interpretation in certain contexts, it's current inability to reduce
the depth of a working copy item, and so on. Here's the transcript, for
posterity:

 <glasser> My current plan (and I'm about to email dev@)
 <glasser> is that we continue to have no UI for "downgrading" WC
           depth in 1.5 (but implement it in 1.6, as has been planned
           for a while)
     <dlr> glasser: That's what I figured. Sounds fine to me.
 <glasser> *but* that I reinstate svn_depth_exclude
 <glasser> and write support for it in the repos reporter
     <dlr> With no UI.
         * dlr nods
 <glasser> that will have no UI in 1.5
 <glasser> right
     <dlr> So that 1.6 clients will be able to get the most out of a
           1.5 server, right?
 <glasser> because the hard part for exclude is dealing with the wc
           (making things disappear, etc)
 <glasser> not just skipping an entry in the delta
 <glasser> yup
 <glasser> dlr: though note that the specific situation you describe
           wouldn't use the hypothetical depth=exclude
 <glasser> it would just remove the subdirectory from the entries of
           the depth=empty directory
 <glasser> depth=exclude is only useful if the parent is a "recursive" depth
     <dlr> My example used a file *shrug*. But, how to remove that
           file? Would that be something separate?
 <glasser> Well, the way that the entries file works now is
 <glasser> $ svn co $URL --depth=empty
 <glasser> now we have a .svn/entries with .-depth empty and *no
           information about any children*
 <glasser> $ svn up $URL/A --depth=infinity
 <glasser> now .svn/entries still has .-depth empty, but it has an
           entry for A too
 <glasser> so to get rid of that A, you just need to remove its entry.
           no exclude necessary
 <glasser> on the other hand, if you wanted 'everything *but* A' you
           would have to make the parent be infinity and A be "exclude"
     <dlr> What's the UI for removing its entry, then?
     <dlr> A's entry.
     <dlr> (We don't have one yet, but I thought exclude might supply one.)
 <glasser> Presumably it would be some subcommand "svn exclude"
 <glasser> (which would remove the entry if the parent is depth-empty
           (or depth-files if it's a directory), and "exclude" it if
           the parent is more recursive)
     <dlr> Rather than 'svn up --depth=exclude A'
 <glasser> OK, I think it should be possible to add a repos-tests.c
           test to confirm that this works
     <dlr> since that retains a WC entry?
 <glasser> the problem is that passing --depth to 'up' is schizophrenic
 <glasser> it does two things:
 <glasser> it determines "how far" the actual "update" crawl will go
           in the tree
 <glasser> and also, if it's bigger than what is found on disk,
           "upgrades" the depth
 <glasser> thus "svn up --depth=empty" never manages to make anything
           empty; it just does a very shallow update
 <glasser> it's a pretty wacky UI. one proposal had been to make "svn
           co" change depths and "svn up" never do so
     <dlr> People were hot about that for a while, then it was discarded.
 <glasser> i'm somewhat inclined to think that we should just have a
           "--set-depth=" or something. I dunno. It is hairy.
     <dlr> For 'update'?
     <dlr> A modal 'update' would be much less schizophrenic.
         * jackr (n=jrepenni@nat1.sp.collab.net) has joined #svn-dev
<cmpilato> glasser: i think the going line of thought was that there
           was no real use-case for 'svn up --depth" determing how far
           the crawl will go.
<cmpilato> and here's jackr, who voiced opinions along those lines.
 <glasser> cmpilato: Hmm. That may be true
<cmpilato> that we had 'svn up -N' at all was, I believe, only because
           update was too stupid to recognize a shallow checkout.
 <glasser> cmpilato: In any case, I think there's a good call for
           fixing the UI to be saner
 <glasser> but actually making downgrades happen should wait to 1.6
 <glasser> since there's a lot of hairy wc transformations involved
<cmpilato> i like the --set-depth idea. make things very clear.
<cmpilato> in fact, it could just a be a flag: 'svn up --depth
           immediates --set-depth'
 <glasser> cmpilato: Hmm. So what if --depth does control the crawl
           (like it does for status, diff, etc etc) but you can also
           use --set-depth, but it fails to do downgrades?
         * dlr nods
 <glasser> oh, that's not bad
 <glasser> so um, without --set-depth the --depth arg controls the crawl
<cmpilato> (or maybe just a more-generic --sticky flag)
 <glasser> with --set-depth does the crawl go infinite?
         * cmpilato looks forward to one day being able to pin
           files/dirs based on revision, too.
<cmpilato> with --set-depth, the crawl matches the new depth setting
           (as indicated by --depth)
<cmpilato> well, i guess it has to go deeper if its to prune, but...
     <dlr> Do we actually build SQLite in-tree? INSTALL says we do,
           but I must be missing it in the autoconf/Makefile stuffs.
 <glasser> cmpilato: well
 <glasser> cmpilato: that's kind of a matter of semantics
 <glasser> cmpilato: it would only be pruning, say, A
 <glasser> but the prune operatoin on A would involve looking at A/D
           and so on
 <glasser> (and looking for local mods, etc etc)
         * glasser needs to go eat, but these are good ideas... can
           somebody email the list?
<cmpilato> i'll send a transcript from IRC

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand