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
