> > 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. :) >
So you're in favor of svn properties for this or against :-P > 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. > No. I would expect, like Googlers do/did, 'checkout --depth none' then run a script to populate that hidden file then do 'svn up' > 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. > Workflow for noob to the Adsense team (Perforce command changed to Subversion as you requested) 1. svn co svn://vcs/trunk --depth none 2. ./gcheckout.sh adsense 3. svn up Workflow for noob to the Adwords team: 1. svn co svn://vcs/trunk --depth none 2. ./gcheckout.sh adwords 3. svn up An eyeball comparison of the two workstation's working copy directories would discover that there were many directories/files in common, and many different (as you would expect for two different applications with different teams, release cadences etc). Google shares code internally at source level. Workflow for a senior engineer wanting to make a change to the common code between adsense and adwords: 1. cd to existing working copy in 'no pending changes' status 2. ./gcheckout.sh adwords+adwords 3. svn up - Paul
