You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2007/11/21 17:53:04 UTC
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Concerns and ideas around --depth
Posted by David Glasser <gl...@davidglasser.net>.
On Nov 21, 2007 3:11 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "C. Michael Pilato" <cm...@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?)
I think there was a glimmering of "design the API now but don't
implement the downgrade part of it", namely with the --set-depth
concept. Even after having hacked on it for a while, I still find
describing the behavior of "svn up --depth=FOO" to be tricky...
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Concerns and ideas around --depth
Posted by Karl Fogel <kf...@red-bean.com>.
"C. Michael Pilato" <cm...@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 <cm...@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