Have you seen: http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py
> On Sep 12, 2017, at 10:22 PM, Paul Hammant <p...@hammant.org> wrote: > > Compared to Perforce's client-spec, Subversion's sparse checkouts are quite > cumbersome: > > svn checkout http://svn.apache.org/repos/asf/subversion --depth=immediates > cd subversion/trunk > svn update --set-depth infinity > cd ../tags > svn update --set-depth immediates > cd 1.7.7 > svn update --set-depth infinity > > .. and similar. > > Could Subversion follow Perforce and allow an alternate mechanism that > leveraged include and exclude globbing paths? > > Maybe in the root of working copy, the contents of a special file could be > honored: > > .sparse_mappings.txt > > Sample contents: > > exclude **/* > include trunk/**/* > include tags/* > include tags/1.7.7/**/* > > Where the end user to do svn-up from root (after that file changed), and > assuming 'svn st' were 'clean', the working copy would reshape itself. > Specifically directories would appear and disappear, and that NOT necessarily > be subversion adds or deletes - it'd feel the same as permission changes > within the directory tree. Of course different teammates with the same > checkout may see entirely different things (depending on the lines within > their .sparse_mappings.txt > > When I say special file, I mean Subversion isn't going to mark it as > candidate for svn-add when it sees it. Meaning, it is set on the client side > by tooling and left there. Tooling may include expand/contract scripts > similar to what Google have for their monorepo. > > Elsewhere i have documented Google's fu and the need for it for scaled > Trunk-Based Development in a few places: > > 1. https://paulhammant.com/2014/01/06/googlers-subset-their-trunk/ (based on > 2009 memories). Yes I know they are in Piper now and out of Perforce. > > 2. Previously I forked a medium-sized Monorepo on Github, and did the the > complete expand/contract work for it - > https://github.com/paul-hammant-fork/jooby-monorepo-experiment - in Python. > > 3. I have generally written about monorepos here: > https://trunkbaseddevelopment.com/monorepos/ > > 4. And the expanding contracting kind here: > https://trunkbaseddevelopment.com/expanding-contracting-monorepos/ > > So, in the tradition of the Subversion project, I'd like to discuss this > here, then go on to raise a JIRA ticket. > > - Paul
