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/09/25 01:48:44 UTC
Recommended UI tweaks for depth selection and filtering
I was talking with Karl about the UI around working copy depth selection and
subsequent operations. He explained the status quo as so:
'svn up' (with no --depth specified) should update your working items,
preserving their current depth setting.
'svn up --depth D' is a way to limit the scope of the update data
delivered by the server. For portions of your working copy shallower
than D, this means you might get update information that doesn't apply
to items in your working copy. The result of this will be that
those areas of your working copy will be changed to now have a depth
of D. For portions of your working copy already at depth D or deeper,
only the subset of those items at or shallower than depth D will be
updated.
In other words, the way to make a shallow part of your working copy less
shallow, you 'svn update' it to a depth value that's ... less shallow. In
order to do the reverse -- aha, well, there's no nice way to do so, just
some hackish workarounds (he didn't describe those).
I proposed the following to Karl, and he seemed to like it.
Make 'svn up' only ever honor the depth selections of your working
copy. With no --depth specified, this means, "Update all my stuff."
With --depth, this becomes a filter applied *after* "Update all my
stuff", rather like "Update all my stuff that's within the specified
depth."
Make 'svn co --depth' the way you tweak a working copy item's
depth setting to a new value.
In other words, say I want to build a working copy from a project where all
I every really do is mess with the project website and ALLCAPS files. I
checkout the top-level directory with depth immediates:
$ svn co http://.../project --depth immediates wc
A wc
A wc/README
A wc/LICENSE
A wc/src
A wc/www
A wc/build
Checked out revision 14.
$
I then checkout the www directory with depth infinity:
[The following is my ideal syntax ... it might not pass community muster,
though.]
$ svn co wc/www ## maybe "svn co --depth infinity wc/www"?
A wc/www/index.html
A wc/www/logo.png
Checked out revision 14.
$
From here on, I can run 'svn up wc' and only ever see (a) changes to the
top-level files, (b) creations of top-level subdirs sans their contents, and
(c) adds/deletes/modifies inside www. If I run 'svn up --depth immediates
wc', though, I won't get the stuff in (c) there.
Later, I need to make a quick fix to the build system:
$ svn co wc/build
A wc/build/Makefile.in
A wc/build/doit.bat
Checked out revision 18.
$
I make my tweaks, commit them up, then:
$ svn co --depth empty wc/build ## wc/build is emptied!
$
The gist of the idea is that "checkout" becomes not just "make a working
copy where none exists", but "create and depth-adjust working copies".
Unfortunately, I admit that I haven't had the time to fully flesh out these
thoughts. I was primarily concerned about the sort of
dual-role-but-not-quite that 'svn up --depth' was playing in the current
plans, and encouraged by Karl's recognition of that as a potential problem
(and seeming support of what portion of this proposal was baked).
Thoughts?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Recommended UI tweaks for depth selection and filtering
Posted by Jack Repenning <jr...@collab.net>.
On Sep 28, 2007, at 2:29 PM, David Glasser wrote:
> Actually, I thought Mike's proposal was to let you use "checkout
> --depth SomethingShallower" even on an existing wc...
Ah, you're right, he did say that.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Recommended UI tweaks for depth selection and filtering
Posted by David Glasser <gl...@davidglasser.net>.
On 9/28/07, Jack Repenning <jr...@collab.net> wrote:
> Despite the fact that I can't see much sense in a depth-limited
> 'status' on a deep working copy, I think the use case "make this
> working copy shallower" is very real. It also can be spelled "oh,
> no, not that crap!" Or even "done with that, now refocus on
> something else." So this ill-supported operation does interest me.
>
> Now it's true enough that, if you run ever farther down Mike's
> proposed road of making only checkout able to diddle depth, then you
> lose any chance to "shallow things up." But if, instead, you finish
> the path already started, things are not so bleak. The most natural
> command for "make this shallower" would be
Actually, I thought Mike's proposal was to let you use "checkout
--depth SomethingShallower" even on an existing wc...
--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: Recommended UI tweaks for depth selection and filtering
Posted by Jack Repenning <jr...@collab.net>.
Well, so, for the record, I don't like Mike's suggestions.
I would like "update --depth D" to cause all affected objects to
reach depth D. If they were formerly shallower, they should deepen;
if they were formerly deeper, their nether regions should be
removed. If there are mods in the nether regions, exception behavior
should kick in (perhaps unmanaging stuff but leaving the modded
files, perhaps simply rejecting the operation).
In making the proposal, Mike appears to be appealing to a kind of
symmetry argument, preserving the pattern that most commands treat "--
depth D" as meaning "don't change any depth settings, but be willing
to reach as far down as D to do your thing, if the current WC is that
deep in a given area." Only checkout, he suggests, should work
otherwise, being able to change the depth. That is, his argument is
either "a single exception is less confusing than several," and/or
"checkout is already special anyway, so making it handle depth
differently at least aligns with more elemental asymmetries."
I challenge all those lines of thinking, and I introduce a third as
well.
First off, while I can easily understand the effect of "xxx --depth
D" in a deeper-than-D context for any command besides checkout (that
is, Mike's "usual" cases), I can't for the life of me think of a use
case. I'm not, therefore, very powerfully motivated to preserve this
symmetric yet apparently useless property.
Second, while I agree that checkout is "special" in some inchoate
sense that might well justify its exception from the pattern, I think
update is just as "special," to the same degree and in the same way.
And so is 'switch,' by the way. It's not only the inner secrets of
the protocol that know that checkout and update and switch are
practically the same thing; even the users know that. To the extent
that this specialness justifies anything, it applies to update (and
to switch) just as much to checkout: they all mean "download."
For my third and new line of thought, I will actually illustrate from
the original post:
On Sep 24, 2007, at 6:48 PM, C. Michael Pilato wrote:
> In other words, the way to make a shallow part of your working copy
> less
> shallow, you 'svn update' it to a depth value that's ... less
> shallow. In
> order to do the reverse -- aha, well, there's no nice way to do so,
> just
> some hackish workarounds (he didn't describe those).
Despite the fact that I can't see much sense in a depth-limited
'status' on a deep working copy, I think the use case "make this
working copy shallower" is very real. It also can be spelled "oh,
no, not that crap!" Or even "done with that, now refocus on
something else." So this ill-supported operation does interest me.
Now it's true enough that, if you run ever farther down Mike's
proposed road of making only checkout able to diddle depth, then you
lose any chance to "shallow things up." But if, instead, you finish
the path already started, things are not so bleak. The most natural
command for "make this shallower" would be
update --depth SomethingLessThanItIsNow
It wouldn't be "checkout," because I already have the files I'm
trying to get rid of.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
Re: Recommended UI tweaks for depth selection and filtering
Posted by Karl Fogel <kf...@red-bean.com>.
Jack Repenning <jr...@collab.net> writes:
>> I officially recant my suggestion that 'svn checkout
>> --depth' affect change on an existing working copy, and further
>> suggest that
>> 'svn update --depth' and 'svn switch --depth' handle that task,
>> telescoping
>> working copies both more deeply and more shallowly as indicated by the
>> requested depth.
>
> +1 on both those, noting that the current code doesn't "telescope
> more shallowly", though you can:
> rm -fr subdir
> svn update --depth not-so-deep subdir
I'd been neglecting this thread, because I'd been busy exploring the
code for this issue and coming to exactly the same conclusion as
y'all. Accordingly, I've closed the issue now, see
http://subversion.tigris.org/issues/show_bug.cgi?id=2949#desc4
for details.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Recommended UI tweaks for depth selection and filtering
Posted by Jack Repenning <jr...@collab.net>.
On Oct 1, 2007, at 11:46 AM, C. Michael Pilato wrote:
> I officially recant my suggestion that 'svn checkout
> --depth' affect change on an existing working copy, and further
> suggest that
> 'svn update --depth' and 'svn switch --depth' handle that task,
> telescoping
> working copies both more deeply and more shallowly as indicated by the
> requested depth.
+1 on both those, noting that the current code doesn't "telescope
more shallowly", though you can:
rm -fr subdir
svn update --depth not-so-deep subdir
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
Re: Recommended UI tweaks for depth selection and filtering
Posted by "C. Michael Pilato" <cm...@collab.net>.
Jack Repenning wrote:
> The idea of "consistency" that leads you to propose this change is
> myopic and pedantic. "Consistency" of user experience operates as a
> sort of average over many axes: within the command set, over history,
> within the work flows, etc. The idea that update can, like checkout,
> change the depth is entirely consistent with the user experience, and
> apparently (given that it was the initial implementation) with at least
> Karl's hind-brain as well (not to mention my own).
I've had some time to think about this, and realize where my logical error
was: compatibility.
I placed some priority on allowing 'svn update -N' and 'svn switch -N' to
continue meaning exactly what they do today. But I'm not sure the effects
of those operations are use-cases worth preserving, and suspect they exist
only as artifacts of a previous deficiency in Subversion.
Why do we have 'svn update -N' today? Probably because 'svn checkout -N'
was non-sticky. Same for 'svn switch -N'. I think we all would agree that
if 'svn checkout -N && svn update' would have worked as expected, only
updating the items already present in the shallow working copy which
resulted from the checkout, we'd have no real need of a -N flag to update or
switch.
So, recognizing what I believe to have been a misstep in the past with the
introduction of -N flags to 'update' and 'switch', and standing now
unwilling to preserve their prior meanings even at the risk of making an
incompatible change, I officially recant my suggestion that 'svn checkout
--depth' affect change on an existing working copy, and further suggest that
'svn update --depth' and 'svn switch --depth' handle that task, telescoping
working copies both more deeply and more shallowly as indicated by the
requested depth.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Recommended UI tweaks for depth selection and filtering
Posted by Jack Repenning <jr...@collab.net>.
On Sep 24, 2007, at 6:48 PM, C. Michael Pilato wrote:
> I then checkout the www directory with depth infinity:
> [The following is my ideal syntax ... it might not pass community
> muster,
> though.]
>
> $ svn co wc/www ## maybe "svn co --depth infinity wc/www"?
Since you're going for "consistency," svn co should consistently do
"--depth infinity" if given no more explicit guidance. So the two
alternatives you present here should be equivalent.
But in as much as you're going for "consistency," neither should be
allowed, because co ordinarily requires an URL. Of course, requiring
an URL here is ridiculous:
$ svn co --depth immediates http://blah/blah/... newtop
$ cd newtop/subdir
$ svn info
<copy URL>
$ svn co --depth infinity <paste-URL>
Perhaps this should be coupled with two extensions to "info":
- "svn info --field=XXX" (XXX being, say, "URL")
- "svn info --quiet" (transforming, say, "URL: http://..." into
merely "http:.//...")
... enabling
$ svn co --depth immediates http://blah/blah/... newtop
$ cd newtop/subdir
$ svn co --depth infinity `svn info --field=URL --quiet`
But this is scope creep to rescue what may have been a bad idea in
the first place (and back-ticking a subcommand is a pretty extreme
measure for rescuing something touted as the primary purpose of the
whole "--depth" initiative). It would be far more "consistent" to
use the command that already accepts a working-copy object and
figures out its URL:
$ svn co --depth immediates http://blah/blah/... newtop
$ cd newtop/subdir
$ svn up --depth infinity
The idea of "consistency" that leads you to propose this change is
myopic and pedantic. "Consistency" of user experience operates as a
sort of average over many axes: within the command set, over history,
within the work flows, etc. The idea that update can, like checkout,
change the depth is entirely consistent with the user experience, and
apparently (given that it was the initial implementation) with at
least Karl's hind-brain as well (not to mention my own).
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
Re: Recommended UI tweaks for depth selection and filtering
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> I like these suggestions. I have to admit that I find the current svn
> up --depth a little confusing in exactly the ways that you describe.
>
> I also think it makes a certain degree of sense for svn co to be the
> command that makes these changes to the wc.
Just for the record, I'm in favor of Mike's proposal too. I think I
could probably implement it pretty quickly. I'd like to finish #695
and friends first, but when I get a chance I'll file an issue for this
one (that'll be tomorrow evening -- feel free to beat me to it). This
shouldn't take too long, since checkout and update are really the same
thing under the hood.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Recommended UI tweaks for depth selection and filtering
Posted by Mark Phippard <ma...@gmail.com>.
On 9/24/07, C. Michael Pilato <cm...@collab.net> wrote:
> I was talking with Karl about the UI around working copy depth selection and
> subsequent operations. He explained the status quo as so:
>
> 'svn up' (with no --depth specified) should update your working items,
> preserving their current depth setting.
>
> 'svn up --depth D' is a way to limit the scope of the update data
> delivered by the server. For portions of your working copy shallower
> than D, this means you might get update information that doesn't apply
> to items in your working copy. The result of this will be that
> those areas of your working copy will be changed to now have a depth
> of D. For portions of your working copy already at depth D or deeper,
> only the subset of those items at or shallower than depth D will be
> updated.
>
> In other words, the way to make a shallow part of your working copy less
> shallow, you 'svn update' it to a depth value that's ... less shallow. In
> order to do the reverse -- aha, well, there's no nice way to do so, just
> some hackish workarounds (he didn't describe those).
>
> I proposed the following to Karl, and he seemed to like it.
>
> Make 'svn up' only ever honor the depth selections of your working
> copy. With no --depth specified, this means, "Update all my stuff."
> With --depth, this becomes a filter applied *after* "Update all my
> stuff", rather like "Update all my stuff that's within the specified
> depth."
>
> Make 'svn co --depth' the way you tweak a working copy item's
> depth setting to a new value.
>
> In other words, say I want to build a working copy from a project where all
> I every really do is mess with the project website and ALLCAPS files. I
> checkout the top-level directory with depth immediates:
>
> $ svn co http://.../project --depth immediates wc
> A wc
> A wc/README
> A wc/LICENSE
> A wc/src
> A wc/www
> A wc/build
> Checked out revision 14.
> $
>
> I then checkout the www directory with depth infinity:
> [The following is my ideal syntax ... it might not pass community muster,
> though.]
>
> $ svn co wc/www ## maybe "svn co --depth infinity wc/www"?
> A wc/www/index.html
> A wc/www/logo.png
> Checked out revision 14.
> $
>
> From here on, I can run 'svn up wc' and only ever see (a) changes to the
> top-level files, (b) creations of top-level subdirs sans their contents, and
> (c) adds/deletes/modifies inside www. If I run 'svn up --depth immediates
> wc', though, I won't get the stuff in (c) there.
>
> Later, I need to make a quick fix to the build system:
>
> $ svn co wc/build
> A wc/build/Makefile.in
> A wc/build/doit.bat
> Checked out revision 18.
> $
>
> I make my tweaks, commit them up, then:
>
> $ svn co --depth empty wc/build ## wc/build is emptied!
> $
>
> The gist of the idea is that "checkout" becomes not just "make a working
> copy where none exists", but "create and depth-adjust working copies".
>
> Unfortunately, I admit that I haven't had the time to fully flesh out these
> thoughts. I was primarily concerned about the sort of
> dual-role-but-not-quite that 'svn up --depth' was playing in the current
> plans, and encouraged by Karl's recognition of that as a potential problem
> (and seeming support of what portion of this proposal was baked).
>
> Thoughts?
I like these suggestions. I have to admit that I find the current svn
up --depth a little confusing in exactly the ways that you describe.
I also think it makes a certain degree of sense for svn co to be the
command that makes these changes to the wc.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org