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
<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
<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> 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 (email@example.com) 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
<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 <firstname.lastname@example.org>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Nov 21 18:53:34 2007