From dev-return-37346-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Tue Jan 9 22:30:24 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 52938180718 for ; Tue, 9 Jan 2018 22:30:24 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 42491160C2D; Tue, 9 Jan 2018 21:30:24 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 87E8F160C17 for ; Tue, 9 Jan 2018 22:30:23 +0100 (CET) Received: (qmail 24292 invoked by uid 500); 9 Jan 2018 21:30:22 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 24282 invoked by uid 99); 9 Jan 2018 21:30:22 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Jan 2018 21:30:22 +0000 Received: from [192.168.1.2] (unknown [81.174.159.228]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 2017F1A00A0 for ; Tue, 9 Jan 2018 21:30:21 +0000 (UTC) Subject: Re: A rational svn shelve/checkpoint CLI To: dev@subversion.apache.org References: <55bbde98-a3e2-e641-7c9b-f9dd1260cb29@apache.org> <2a218f04-c620-60d4-8eab-50de96f117ce@apache.org> <2682c902-868b-74ed-4038-9d9fb87704b5@apache.org> <20180108152322.GA21791@byrne.stsp.name> <37930828-4b4a-086c-48bd-e9ebc049109c@apache.org> <20180108153357.GB21791@byrne.stsp.name> <12ef4268-83b2-f1c0-02a4-8c2b12699824@apache.org> <1515506376.4046518.1229269056.3A686164@webmail.messagingengine.com> From: Julian Foad Message-ID: Date: Tue, 9 Jan 2018 21:30:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1515506376.4046518.1229269056.3A686164@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Julian Foad wrote on Tue, 09 Jan 2018 13:31 +0000: > Anyway the main point here is: we have in principle a set of tree > snapshots (no matter that each one is stored in the form of a difference > against the base); and we use revision specifiers to refer to the > working and base versions: Initial implementation: http://svn.apache.org/r1820696 "On the 'shelve-checkpoint' branch: Let revision specifiers access shelves." I think this proves the principle of using revision specifier syntax to refer to shelves. $ svn propset -r foo --revprop svn:log 'New log msg.' $ svn propget -r foo --revprop svn:log New log msg. where 'foo' is a shelf. 'propedit' and 'proplist' and 'propdel' work too. Only the svn:log revprop is stored in the shelf format so far; it will be easy to extend to support all revprops. We may well prefer some other syntax than simply "-r foo", such as "-r shelf:foo" or "-r [foo]" or whatever, but that's not the main point. The main point is how the rev spec is converted to an (extended) svn_opt_revision_t object and then passed in to the libsvn_client APIs, and to what extent we would need to modify the APIs to properly support this. Already I found, for example, that the revprop APIs take an svn_opt_revision_t structure as input but they also output a plain svn_revnum_t to tell what number a date or 'head' revspec was resolved to; with a shelved change, the output revision specifier cannot be represented as svn_revnum_t, and I set it to -1 which causes some ugly output: $ svn proplist --revprop -r foo Unversioned properties on revision -1: svn:log So we would want to change this to svn_opt_revision_t. This is just the first example I have come across of a change needed; some other APIs will likely require more extensive changes. Only revprop access is implemented so far, as it was the easiest part to implement. Providing unified access to a 'tree snapshot' view of the shelved version (svn list/cat/propget (versioned properties), etc.) and making modifications (svn add/cp/mv/rm/propset, etc.) and a 'difference' view (svn diff/status) will be cumbersome to implement, especially with patch file as the storage, although relatively straightforward in principle. This could be the trigger for a change in storage form. - Julian