On Wed, Sep 13, 2017 at 12:45 PM, Paul Hammant <paul_at_hammant.org> wrote:
> I see you posted a StackOverflow answer on that too, Mark -
> I'm one of those people that's blind to a lib or framework until I see
> examples of how to use (can't read tutorials, can't read ref docs). I found
> too which gets me halfway there.
> The svn-viewspec script is implicitly include-centric, right? Perforce's
> choice back in the 90's was to allow excludes and includes which is more
> powerful even if it is dangerous.
I'd like more powerful "viewspec" features in (core) Subversion too.
The svn-viewspec.py script (and it's viewspec format) is already quite
useful, but I miss a couple of things (I know, this is open source and
patches are welcome, but I'm not able to dig deeper atm, so just
listing some ideas here):
1. Interaction with 'update'. I should be able to 'svn update
--set-depth $viewspec' or something like that, making an existing WC
sparse like in the viewspec.
2. Create a viewspec file out of an existing sparse WC (serialization
of the sparseness, if you will). This also touches on another missing
feature: there is currently no command to view / examine the
sparseness of a working copy.
3. Excludes should be possible in the viewspec format, analogous to
the "--set-depth exclude" working copy depth. So we have parity
between the viewspec format and WC sparseness.
4. With svn-viewspec.py, the "base url" is part of the viewspec file.
It would be nice to be able to give a "base url" by other means,
independent of the viewspec file -- so I can apply the same viewspec
on a branch as on trunk (assuming a multi-project trunk which is
sparsely checked out).
5. Commands handling a viewspec file: should they read/write the
viewspec from a property, a file, a pipe, ...?
I think Brane already suggested a good approach for those last two
On Thu, Sep 14, 2017 at 3:43 AM, Branko Čibej <brane_at_apache.org> wrote:
> How about something along the lines of this:
> $ svn co svn://vcs/trunk --view foo
+1, this shows the "base url" being independent of the viewspec.
> $ svn propget svn:views svn://vsc/trunk
> In other words: available views are defined in a svn:views property on
> the directory, and the user selects which (if any) view to use during
> checkout, update or switch. Obviously once the working copy structure is
> set up it'd remain sticky unless explicitly changed.
> For user-specific layouts, I can imagine having a --view-file or
> --view-prop option to tell the client where to read the view definitions
> from; but the svn:views property would be the default.
I'm not sure about listing the "available views" in a default
property, but okay, it's a possibility. I think it would be nice to be
able to read it from a file, a url or a property (chosen by the user).
In theory I'd say it would be nice to read it from a pipe, so you can
'cat', 'svn cat' or 'svn propget' the viewspec as input.
Received on 2017-09-19 00:14:27 CEST