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

Re: Sparse checkouts suggestion

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 19 Sep 2017 00:13:56 +0200

On Wed, Sep 13, 2017 at 12:45 PM, Paul Hammant <paul_at_hammant.org> wrote:
>> http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py
> Excellent!
> I see you posted a StackOverflow answer on that too, Mark -
> https://stackoverflow.com/questions/7481860/create-folder-structure-based-on-file
> 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
> https://prabhugs.wordpress.com/2010/10/11/effective-and-easy-sparse-checkouts-svn-viewspec-py-script/
> 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
points elsethread:

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.

> with:
> $ svn propget svn:views svn://vsc/trunk
> [foo]
> bar/**
> baz/qux
> [bar]
> baz/**
> 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

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