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