[PATCH] Hackathon project: Dumping viewspec

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Hackathon project: Dumping viewspec

Bert Huijben-5
        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
]]
I can now see output like
[[
svn checkout https://ctf.open.collab.net/svn/repos/sharpsvn/trunk@4003
/SharpSvn/trunk
svn update -r 4004
/SharpSvn/trunk/imports/patches/openssl/201603-capi-sha-openssl-1.0.2.patch
svn switch ^/branches/1.800x/contrib@4004 /SharpSvn/trunk/contrib
svn update -r 0 /SharpSvn/trunk/LICENSE.txt
svn update -r 4004 /SharpSvn/trunk/src/SharpPlink --set-depth files
svn update -r 4004 /SharpSvn/trunk/src/SharpSvn --set-depth files
svn update --set-depth files /SharpSvn/trunk/src/SharpSvn/Commands
svn update --set-depth exclude /SharpSvn/trunk/build.info
]]

So this new command spits out the shell commands necessary to create a new
working copy with exactly the same layout and revisions as the existing
working copy.

This could be the starting point for an improved format, or for creating
scripts that transform this in something more useful, e.g. by filtering out
unnecessary details.


I put the current code in a patch file attached to this message to allow
discussing this feature before putting it on trunk.

        Bert



viewspec-dump.patch (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Hackathon project: Dumping viewspec

Stefan Fuhrmann
Very nice, well done, sir!

-- Stefan^2.

On 24.11.2017 14:42, 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
> ]]
> I can now see output like
> [[
> svn checkout https://ctf.open.collab.net/svn/repos/sharpsvn/trunk@4003
> /SharpSvn/trunk
> svn update -r 4004
> /SharpSvn/trunk/imports/patches/openssl/201603-capi-sha-openssl-1.0.2.patch
> svn switch ^/branches/1.800x/contrib@4004 /SharpSvn/trunk/contrib
> svn update -r 0 /SharpSvn/trunk/LICENSE.txt
> svn update -r 4004 /SharpSvn/trunk/src/SharpPlink --set-depth files
> svn update -r 4004 /SharpSvn/trunk/src/SharpSvn --set-depth files
> svn update --set-depth files /SharpSvn/trunk/src/SharpSvn/Commands
> svn update --set-depth exclude /SharpSvn/trunk/build.info
> ]]
>
> So this new command spits out the shell commands necessary to create a new
> working copy with exactly the same layout and revisions as the existing
> working copy.
>
> This could be the starting point for an improved format, or for creating
> scripts that transform this in something more useful, e.g. by filtering out
> unnecessary details.
>
>
> I put the current code in a patch file attached to this message to allow
> discussing this feature before putting it on trunk.
>
> Bert
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Hackathon project: Dumping viewspec

Stefan Sperling-9
In reply to this post by Bert Huijben-5
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 ;)
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Hackathon project: Dumping viewspec

Stefan
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

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Hackathon project: Dumping viewspec

Johan Corveleyn-3
On Sun, Nov 26, 2017 at 11:50 PM, Stefan <[hidden email]> wrote:

> 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".

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.

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)

Maybe the viewspec could also be read from standard input (by using '-'):

    svn info -R --viewspec WC1 | svn update WC2 --viewspec -

?

A separate 'viewspec' subcommand might also be interesting, but I'm
not sure what we'll be using it for exactly (only for exporting
viewspecs from WCs?).
I think we need to think about two different things:

(1) Export / describe the viewspec of a specific working copy.
(2) Apply a viewspec to a working copy (or when creating a working copy)

IMHO, the "applying" needs to be part of several commands that create
/ modify working copies (checkout, update, switch, perhaps export).

--
Johan