On Thu, Mar 15, 2018 at 11:19 PM, Julian Foad <julianf...@apache.org> wrote: > Johan Corveleyn wrote: >> >> On Sun, Nov 26, 2017, Stefan <luke1...@posteo.de> wrote: >>> >>> On 25/11/2017, Stefan Sperling wrote: >>>> >>>> On Fri, Nov 24, 2017, Bert Huijben wrote: >>>>> >>>>> At the Aachen hackathon I promised to write some code to spit out the >>>>> sparse >>>>> definition of a working copy, or in other words some initial dumb >>>>> viewspec >>>>> output. >>>>> $ svn switch --list \SharpSvn\trunk >>>> >>>> >>>> Has a new 'svn viewspec' been subcommand considered? >>>> 'switch --list' reminds me of our 'switch --relocate' mistake >>>> from the past ;) >>> >>> >>> Indeed it was. FWIW I agree there are good arguments for a new viewspec >>> subcommand. >>> >>> The alternative would be to use "svn list --generate-viewspec" and "svn >>> switch/checkout --use-viewspec < viewspecfile" or something like this. >>> The obvious downside would be that one subcommand would be used to >>> generate the viewspec while another one would be used to apply it. I >>> think Bert brought up other arguments against adding it to "svn list". >> >> >> I prefer adding the "export the viewspec info from this WC" to "svn >> info", because that's what we already use to obtain info from a >> working copy (including depth and working revision). Perhaps "svn info >> -R --viewspec". Let's say this would generate some structured >> information in a well defined syntax. > > > I have committed Bert's patch, with the command modified to be "svn info > --viewspec", in http://svn.apache.org/r1826864 > > Let's see where it leads.
Awesome! Thanks Julian (and Bert of course). > First I'd like to 'clean up' the formatting a bit to make it easier to read, > and add some tests. > >> The exported info can then be used as optional input for several commands: >> >> svn checkout $URL --apply-viewspec vspecfile.txt >> svn update . --apply-viewspec vspecfile.txt >> svn switch . --apply-viewspec vspecfile.txt (perhaps the >> viewspec contains switched subtrees, which necessitates the 'switch' >> command to execute) > > > We need to look at using the viewspec as input next. Semantically speaking, > these sorts of things: > > * a way to check out a new WC to match the spec; > * a way to modify an existing WC to match the spec; > * a way to modify/checkout a WC of a *different* branch, to match the spec > except for its URLs (maybe switch URLs pointing inside this 'branch' or WC > get adjusted as if they are relative, and other switch URLs stay absolute?); Ack. FWIW, the viewspec format of svn-viewspec.py [1] (which can serve as inspiration I guess) requires the viewspec to have a "Url", and then a series of path rules. The Url serves as a base url, the path rules are relative to that base url. So here too, I suppose a viewspec can contain a "base url", but the user should be able to override that base url when applying the viewspec (with checkout, update, switch, export, ...). [1] http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py -- Johan
