"C. Michael Pilato" <cmpilato@collab.net> writes:
> 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:
If the proposal is that glasser wants to implement --depth=exclude on
the server side right now, that makes sense to me (though a detailed
description of what that means would be good). I totally agree that
we should punt the client-side UI issues to 1.6, though.
(Were there any other specific concerns that needed to be addressed in
this, or was it just a preservation of the transcript for posterity?)
-Karl
> <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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 21 21:11:28 2007