On 13.09.2017 12:40, 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. :)
>
>
> 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
How about something along the lines of this:
$ svn co svn://vcs/trunk --view foo
with:
$ svn propget svn:views svn://vsc/trunk
[foo]
bar/**
baz/qux
[bar]
baz/**
In other words: available views are defined in a svn:views property on
the directory, and the user selects which (if any) view to use during
checkout, update or switch. Obviously once the working copy structure is
set up it'd remain sticky unless explicitly changed.
For user-specific layouts, I can imagine having a --view-file or
--view-prop option to tell the client where to read the view definitions
from; but the svn:views property would be the default.
-- Brane
Received on 2017-09-14 03:43:54 CEST