[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Recommended UI tweaks for depth selection and filtering

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-09-25 04:00:52 CEST

On 9/24/07, C. Michael Pilato <cmpilato@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
Received on Tue Sep 25 04:01:06 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.