I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
following `svn up` it would *remember the current view*, it would be good.
> I'm not sure about listing the "available views" in a default
> property, but okay, it's a possibility. I think it would be nice to be
> able to read it from a file, a url or a property (chosen by the user).
> In theory I'd say it would be nice to read it from a pipe, so you can
> 'cat', 'svn cat' or 'svn propget' the viewspec as input.
>
Google's 9-million* source files at HEAD revision: When checking out the
trunk, and going on to subset down to your expected checkout, there's so
many applications and services in the trunk that their `gcheckout`
technology makes a custom include/exclude set for each developer need based
on a traversal of the Blaze BUILD files. You're mentioning "list" as a sub
command, yet it's not needed at all.
I never saw the source for gcheckout, and it's long gone given Perforce was
replaced by Piper in 2012, and a FUSE took over developer working copy, but
it is still worth understanding to a deeper level.
> gcheckout adsense:tests,adwords:tests,others
The last line ofthe script would invoke
p4 client -i < "$P4_CLIENTSPEC_TEMP"
And you would do `p4 sync` on the command line following that.
The number of permutations == factorial for (num of modules * packages or
namespaces * build targets)
Don't aim for a concise list of view-specs, or "available" views. Leave it
completely open for globbing include and excludes (as Perforce/Google) to
be generated by smart script techs, and only verify the spec for
correctness on ingestion, IMO.
- Paul
