[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Hackathon project: Dumping viewspec

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 16 Mar 2018 13:08:14 +0100

On Thu, Mar 15, 2018 at 11:19 PM, Julian Foad <julianfoad_at_apache.org> wrote:
> Johan Corveleyn wrote:
>> On Sun, Nov 26, 2017, Stefan <luke1410_at_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?);


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

Received on 2018-03-16 13:08:46 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.