Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: [PATCH] Hackathon project: Dumping viewspec
To: Bert Huijben <bert@qqmail.nl>, dev@subversion.apache.org
References: <006e01d3652a$0482f740$0d88e5c0$@qqmail.nl>
 <20171125151201.GA93424@jim.stsp.name>
From: Stefan <luke1410@posteo.de>
Message-ID: <2b365a6e-e40f-95d3-9fa5-601f0b648f43@posteo.de>
Date: Sun, 26 Nov 2017 23:50:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171125151201.GA93424@jim.stsp.name>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Content-Language: en-US
archived-at: Sun, 26 Nov 2017 22:50:33 -0000

On 25/11/2017 16:12, Stefan Sperling wrote:
> On Fri, Nov 24, 2017 at 02:42:05PM +0100, Bert Huijben wrote:
>> 	Hi,
>>
>> 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.
>>
>> Testing this on a test working copy with
>> [[
>> $ 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".

Regards,
Stefan