On 9/6/07, David James <james@cs.toronto.edu> wrote:
> On 9/6/07, Karl Fogel <kfogel@red-bean.com> wrote:
> > Issue #2843 is about fact that there's no way to get rid of stuff
> > after you've pulled it into a (maybe mixed-depth) working copy.
> >
> > For example:
> >
> > $ svn co --depth=empty greek-tree
> > $ cd greek-tree
> > $ svn up A
> > [...pulls in all of A/, recursively...]
> > $ vi A/D/gamma
> > $ vi A/D/G/tau
> > $ vi A/D/H/omega
> > $ svn commit -m "Okay, done with A/ now."
> > $ svn how-do-I-get-rid-of-subdir-A-now-that-I'm-done-with-it?
> >
> > It seems reasonable that one might want to get rid of a subdir, or at
> > least "fold it up" to be empty, after one were done working with it.
> > Either behavior would probably require a new subcommand, though. We
> > can't just make 'svn update --depth=empty SUBDIR' fold up SUBDIR, for
> > example, because 'svn update --depth=empty' already means "update the
> > things you can reach with depth=empty, and touch nothing else".
> >
> > But I'm loathe to add a new subcommand for a feature we're not
> > positive people will really need, and for which we have no real-world
> > experience. So I think we should defer issue #2843 until 1.6. That
> > will give the sparse-directories feature some time in the wild, and
> > then we can see if a new subcommand is really needed -- or if nothing
> > is needed, or if clever workarounds are available, or if someone
> > thinks up another solution entirely.
>
> I've already solved this problem in my viewspec proposal. See
> http://svn.haxx.se/dev/archive-2006-07/0624.shtml for more details.
>
> Personally, I'd recommend implementing exclusion and inclusion as
> options on the viewspec command.
>
> I've included some examples below. These examples are slightly
> different from those I originally proposed in the first viewspec
> thread, because I've edited them to use explicit operation selection,
> as suggested by Max Bowsher.
>
> # Remove a directory from the viewspec
> svn viewspec --remove blah
>
> # Add a new directory to the viewspec
> svn viewspec --add blah --depth=empty
>
> # Display the current viewspec
> svn viewspec
>
> # Edit the viewspec in your editor
> svn viewspec --edit
>
> # Export the viewspec to a file
> svn viewspec > viewspec.txt
>
> # Update your viewspec to reflect changes you've made on disk
> svn viewspec -F viewspec.txt
>
> # Checkout a repository using a viewspec
> svn checkout --viewspec viewspec.txt svn://server/trunk
>
> If you want to stick with the 'depth' theme, the output of the
> viewspec command could even just include the depth information as it
> is displayed on the command line. Here's an example:
>
> $ svn checkout svn://server/repository wc --depth=empty
> $ cd wc
> $ svn viewspec --add bar --depth=infinite
> $ svn viewspec --remove bar/baz
> $ svn viewspec --add bar/bah --depth=empty
> $ svn viewspec > viewspec.txt
> $ cat viewspec.txt
> --add . --depth=empty
> --add bar --depth=infinite
> --remove bar/baz
> --add bar/bah --depth=empty
> $ svn viewspec --add . --depth=infinite
> $ svn viewspec
> --add . --depth=infinite
> $ svn viewspec -F viewspec.txt
> $ svn viewspec
> --add . --depth=empty
> --add bar --depth=infinite
> --remove bar/baz
> --add bar/bah --depth=empty
>
> This output isn't as pretty as the Perforce-like syntax I suggested in
> the original thread, but it is definitely more explicit. UI
> suggestions welcome.
FWIW, it is ideas like this one that makes me almost convinced adding
an explicit subcommand today in 1.5 is the right approach. We ought
to let the basic functionality get out in the wild and see what comes
back. David's idea of a feature that tackles this an holistic manner
like he has proposed might be the better solution. An explicit
subcommand might be the better solution too. Let's get this out there
and see.
It'd be nice if there was a function in the library to remove
something so someone could implement svn viewspec using Python, or
some other language, and 1.5. Just as svnmerge.py helped define the
merge tracking feature, something similar could work here.
--
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 Fri Sep 7 01:24:11 2007