[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: Branko Čibej <brane_at_apache.org>
Date: Wed, 13 Sep 2017 11:42:59 +0200

On 13.09.2017 09:25, Paul Hammant wrote:
>
> This is an old idea. If you want to implement it, a file is not the
> right place for the view definition; a property on a directory
> might be.
>
>
> A Svn property that sets for the user and workspace only, and retains
> no history, right?  Meaning if the user had two checkouts of the same
> Svn URL, then they could maintain two different sparse mappings, right?

That would be sort of hard to do. :)

> That would make it like Perforce's implementation. The perforce
> commands for export a client spec, and import again:
>
> p4 client -o > .p4_clientspec_mappings.txt
>
> # modify something
>
> p4 client -i < .p4_clientspec_mappings.txt
>
> Judicious use of this in Google is part of their economic miracle and
> one of the dynamics of their scaling Trunk-Based Development to 25,000
> developers in one trunk in one repo, with 9 million source files at
> HEAD revision :)

Hmm. What exactly are you proposing anyway? I'd like to see this
described in terms of Subversion workflows, not Perforce workflows. Are
you suggesting that every user first checks out a working copy, selects
the view spec, and updates to make it sparse? Because that, whilst of
course possible, is hardly optimal.

I find it hard to believe that every user would want a different view of
the tree. Certainly that's not the way we used the equivalent ClearCase
feature in a previous $dayjob.

-- Brane
Received on 2017-09-13 11:43:07 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.