Re: Sparse checkouts suggestion

> > 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
Received on 2017-09-13 12:40:48 CEST