[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: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 13 Sep 2017 05:56:40 -0400

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 <paul_at_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
Received on 2017-09-13 11:56:48 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.