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

Sparse checkouts suggestion

From: Paul Hammant <paul_at_hammant.org>
Date: Tue, 12 Sep 2017 22:22:36 -0400

Compared to Perforce's client-spec, Subversion's sparse checkouts are quite

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:


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://

4. And the expanding contracting kind here: https://

So, in the tradition of the Subversion project, I'd like to discuss this
here, then go on to raise a JIRA ticket.

- Paul
Received on 2017-09-13 04:22:49 CEST

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