David James wrote:
> It's often true that users want to checkout some, but not all, of a
> large repository. Currently, it's easy to checkout a single subdirectory
> using Subversion. However, if you want to checkout a group of
> subdirectories, and manage this group as a single working copy, you're
> going to run into some major challenges.
>
> In the past year, we've seen two proposals for managing large working
> copies. Last year, Ben Reser proposed creating two new subcommands,
> called 'svn include' and 'svn exclude', which allow you to configure
> which directories are pulled in by 'svn update' [1]. This year, Eric
> Gilespie proposed to instead add a depth parameter to the 'update'
> command [2].
>
> Both Ben and Eric's proposals suffer from a similar problem: they don't
> actually make it easy to checkout a group of subdirectories. With either
> proposal, you're forced to execute a long series of commands (or a long
> series of options) in order to check out a group of subdirectories as a
> single working copy.
This is a really important feature, I think. We already have a limited
amount of difficult-to-backup-and-restore saved in a WC - switching of
paths. That information grows with the addition of a filtering
capability, and with it, manually saving and restoring that information
gets harder.
> I'd like to propose we add full-fledged viewspecs to Subversion. Here's
> how such a feature might work:
>
> To checkout a working copy from the server, which only includes the
> specified files:
> svn checkout --viewspec my-view.txt svn://server/trunk
> Edit the current viewspec (in your favourite editor):
> svn viewspec
>
> Save the current viewspec to a file:
> svn viewspec > my-view.txt
>
> Load a viewspec from a file:
> svn viewspec < my-view.txt
Can you truly implement this proposed interface? If so, can you do it
portably? Even if you can, the amount of automagical behaviour detection
here makes me worried. I think we'd be better off with more explicit
operation selection.
> Add the 'contrib' directory to the viewspec:
> svn viewspec --add contrib -R
>
> Remove contrib/client-side/svnmerge.py from the viewspec:
> svn viewspec --remove contrib/client-side/svnmerge.py
>
> ===================================================================
> HOW TO SPECIFY WHAT FILES ARE CHECKED OUT USING A VIEWSPEC:
>
> 1. +foo/... --> Checkout 'foo', and all subdirectories.
> 2. +foo/* --> Checkout the immediate children of 'foo'. Don't
> download subdirectories.
> 3. -foo/... --> Don't download anything inside 'foo'
> 4. -foo/* --> Don't download the immediate children of 'foo'.
> 5. +bar --> Download the file 'bar'. (If 'bar' is a directory,
> an error will be reported.)
> 6. -bar --> Don't download the file 'bar'. (If 'bar' is a
> directory, an error will be reported.)
It should be possible to check out a directory with depth 0, for
example, to tweak its properties without getting any of its files.
I'd suggest that depth 1 processing of a directory should include its
subdirs being processed with depth 0.
> ===================================================================
> REORGANIZING TREES USING VIEWSPECS
>
> In some cases, users will want to reorganize their tree to have a
> different structure from the one in the repository. Currently,
> users can reorganize their trees using switch. I'd like to allow
> users to also be able to save and restore this kind of reorganization
> using a viewspec.
>
> If you'd like to switch a directory in a viewspec, simply list
> the directory you'd like to download right after the directory
> in your WC. For example, if you wanted to download
> 'foo/images/...' and 'bar/images/...' into the directories 'foo'
> and 'bar' in your WC, you could do so using the following
> viewspec.
>
> +foo/... foo/images/...
> +bar/... bar/images/...
>
> If you've already run 'svn switch' on a directory in your
> working copy, this switch will show up in the viewspec.
> If you checkout a brand new working copy using the same
> viewspec, the same switches will be performed.
Mostly good, but seems weird that the '...' shows up twice in the line -
that seems redundant at best, confusing at worst.
> ===================================================================
> EDITING VIEWSPECS ON THE FLY
>
> To bring up the viewspec in an editor, simply type svn viewspec. Your
> current viewspec will be displayed in your favourite editor.
>
> If you've just performed a regular checkout, your viewspec will show up
> as simply "+...". If you've performed a nonrecursive checkout, your
> viewspec will show up as "+*".
>
> If you've performed switches on your WC, these operations will also
> show up in your viewspec.
>
> Viewspecs are always displayed and parsed relative to the specified
> directory. If your viewspec states '+foo/images/...' for the root
> directory, the viewspec for 'foo' will be 'images/...', and the
> viewspec for 'foo/images' will be '...'. Everything is relative.
Could be rather difficult to code the transitioning from one arbitrary
viewspec to another.
> ===================================================================
> QUICK SHORTCUTS FOR EASY EDITING
>
> It's not always convenient to edit viewspecs as a text file. If you
> just want to add or remove a file or directory from the viewspec,
> you can simply type:
>
> svn viewspec --add foo.txt
> svn viewspec --remove bar.txt baz.txt
>
> To add or remove directories, you must either specify the '-N' or
> '-R' options, so as to clarify whether you want to recursively
> add or remove descendents of these directories. If you do not specify
> either of these options, directory targets will be skipped, and a
> warning message will be printed.
What's the logic for requiring -R or -N? Why not let it default to -R as
almost all our commands do?
> ===================================================================
> IMPLEMENTATION
>
> This proposal can be implemented in libsvn_wc using the following
> steps.
>
> a) The .svn/entries file should have entries for all directories and
> files, regardless of whether the checkout is recursive or not.
This implies that directories themselves cannot be excluded, since they
need to exist to contain their .svn directory.
> ===================================================================
Nitpicks aside, I think this is a great idea! The ability to backup and
restore the structure of a complex WC would be very nice to have.
Max.
Received on Sun Jul 16 18:38:13 2006