Max Bowsher wrote:
> 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.
Glad to hear it!
> > 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
We can setup explicit flags, if you like. Perhaps 'svn viewspec'
should simply display the viewspec by default (instead of opening it
up in an editor).
In that case, we could use the following interface:
To display the viewspec, type: svn viewspec
To save the viewspec, type: svn viewspec > my-view.txt
To load a viewspec, type: svn viewspec -F my-view.txt
To edit the viewspec, type: svn viewspec --edit.
> > 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.
Good point. At the same time, though, it should also be possible to
checkout a directory with depth 0, without checking out the files in
its parent directory, or its contents. We can add a new syntax to
specifically support your case.
7. +foo/
This viewspec would download just the 'directory' foo, but none of its
contents. To support this feature, we'd also need to tweak the entries
file format to communicate this information.
Quoting my original mail:
>> The following modes are supported for directories:
>>
>> "+...": All children of this directory are included
>> by default.
>>
>> "-...": All children of this directory are excluded
>> by default.
>>
>> "+*": Immediate children of this directory are included
>> by default. Subdirectories are included by default.
>>
>> "-*": Immediate children of this directory are included
>> by default. Subdirectories are excluded by default.
We should also add a fifth mode for directories:
"+.": This directory is included by default, but its children
are not.
> > 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.
You'd propose the following syntax instead?
+foo/... foo/images
+bar/... bar/images
That's perfectly reasonable. I only included the "..." marker in both
places for consistency, but some folks might argue that it's just
redundant.
> > 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?
If the viewspec subcommand skips directories by default, svn viewspec
--remove * is the same as svn viewspec --remove '*', except that, if
you enclose the asterik in quotes, Subversion will also ignore files
that are added to the same directory in the future.
At the same time, I tend to agree with you, Max, that it is probably a
good idea to make 'svn viewspec' default to -R, because nearly every
Subversion command behaves that way. Also, it's not a bad thing if
you accidentally remove a directory from your viewspec, because you
can easily add it back later.
Here's a better proposal: If the user types svn viewspec --remove
somedir/*, and their shell has expanded the asterik, we should display
an error message which notes that the glob was expanded, and only
proceed if the user supplies the force option. (We can detect that the
user supplied a '*' glob by noting that *every* non-hidden file and
directory was supplied on the command line.)
In nearly every case where a user types 'svn viewspec --remove
somedir/*', I expect that the user intended to escape the asterik. For
that reason, I think it is a good idea to require the --force option
for this case.
> > 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.
Does it? In my WC, a regular recursive checkout of 'trunk' contains an
entry for every file and directory. If you perform a nonrecursive
checkout, the directory entries are excluded.
I'd like it to be possible to download the contents of a directory
without downloading all of the subdirectories (even as depth 0).
> 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.
Thanks!
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 16 20:35:06 2006