You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@apache.org> on 2018/10/07 20:08:03 UTC
Re: svn commit: r1843076 - /subversion/branches/multi-wc-format/
On 07.10.2018 21:55, brane@apache.org wrote:
> Author: brane
> Date: Sun Oct 7 19:55:18 2018
> New Revision: 1843076
>
> URL: http://svn.apache.org/viewvc?rev=1843076&view=rev
> Log:
> * branches/multi-wc-format: New napshot branch for multiple WC format support from the better-pristines branch.
>
> Added:
> subversion/branches/multi-wc-format/ (props changed)
> - copied from r1843075, subversion/branches/better-pristines/
I created a copy of the better-pristines branch so that I can separate
the multiple-wc-format support and the compressed pristines support, for
easier review.
The multi-wc-format branch is ready for initial review now; it teaches
libsvn_client and libsvn_wc to support multiple versions of the working
copy schema in the same client, including checkouts with an older format
and partial working copy upgrades.
Still missing is a mechanism for the libsvn_wc (and possibly
libsvn_client) to determine the capabilities of the working copy at
runtime (this will be needed for deciding whether to use compressed
pristines).
Please take some time to review the changes on this branch:
svn diff http://svn.apache.org/repos/asf/subversion/trunk
http://svn.apache.org/repos/asf/subversion/branches/multi-wc-format
-- Brane
Re: multi-wc-format branch ready for initial review
Posted by Branko Čibej <br...@apache.org>.
On 19.08.2019 15:58, Julian Foad wrote:
> Brane, do I correctly understand the impact of this branch could be
> summarized as "API support to enable a future version of the client
> software to support multiple WC versions":
>
> * Enables future client software to detect, create, use without
> upgrading, and optionally upgrade any WC version in the supported range.
>
> * The supported range is initially just the current WC version; this
> does not add a new WC version to the supported range.
>
> * To actually support multiple WC versions, the client software will
> need explicit cases for each supported WC version in the handling of
> each feature that varies across versions.
Yes, this is all correct.
My initial plan was to implement support for compresseed/BLOB pristines
after this support is on trunk. But that went the way of so many plans,
i.e., into the no-time zone. :/
>
> That seems to match the branch description at
>
> http://svn.apache.org/repos/asf/subversion/branches/multi-wc-format/BRANCH-README
>
>
> Julian Foad wrote:
>> [...] > I assume Brane has tested it, but someone else testing too
>> would be
> good and I haven't. Then this looks likely to be ready to merge to trunk.
>
> Thinking again, we need an implementation of multiple WC versions to
> test it. It would be wise not to merge until we have tested with such
> an implementation.
Agreed. That's why I only asked for a review, to add eyes and see if I
was going in the right direction. There's some support on the branch to
actually test the multi-format support, but IIRC it sort of trips on a
hard-coded #define -- I'd have to look into that again, it's been a long
time.
> What is the most feasible way forward with this? Is the
> 'better-pristines' branch anywhere near providing at least "dummy"
> handling of a new WC format, sufficient to test these support APIs,
> even if it is not yet actually implementing better-pristines?
As I said, that was the plan, but it's not too close yet.
-- Brane
Re: multi-wc-format branch ready for initial review
Posted by Julian Foad <ju...@apache.org>.
Brane, do I correctly understand the impact of this branch could be
summarized as "API support to enable a future version of the client
software to support multiple WC versions":
* Enables future client software to detect, create, use without
upgrading, and optionally upgrade any WC version in the supported range.
* The supported range is initially just the current WC version; this
does not add a new WC version to the supported range.
* To actually support multiple WC versions, the client software will
need explicit cases for each supported WC version in the handling of
each feature that varies across versions.
That seems to match the branch description at
http://svn.apache.org/repos/asf/subversion/branches/multi-wc-format/BRANCH-README
Julian Foad wrote:
> [...] > I assume Brane has tested it, but someone else testing too would be
good and I haven't. Then this looks likely to be ready to merge to trunk.
Thinking again, we need an implementation of multiple WC versions to
test it. It would be wise not to merge until we have tested with such an
implementation.
What is the most feasible way forward with this? Is the
'better-pristines' branch anywhere near providing at least "dummy"
handling of a new WC format, sufficient to test these support APIs, even
if it is not yet actually implementing better-pristines?
- Julian
multi-wc-format branch ready for initial review [was: svn commit:
r1843076 ...]
Posted by Julian Foad <ju...@apache.org>.
I just noticed this old email that I had flagged but not acted on. Re-posting.
Branko Čibej wrote on 2018-10-07:
>> URL: http://svn.apache.org/viewvc?rev=1843076&view=rev
>> Log:
>> * branches/multi-wc-format: New napshot branch for multiple WC format
>> support from the better-pristines branch.
>
> I created a copy of the better-pristines branch so that I can separate
> the multiple-wc-format support and the compressed pristines support, for
> easier review.
>
> The multi-wc-format branch is ready for initial review now; it teaches
> libsvn_client and libsvn_wc to support multiple versions of the working
> copy schema in the same client, including checkouts with an older format
> and partial working copy upgrades.
>
> Still missing is a mechanism for the libsvn_wc (and possibly
> libsvn_client) to determine the capabilities of the working copy at
> runtime (this will be needed for deciding whether to use compressed
> pristines).
>
> Please take some time to review the changes on this branch:
The current diff is:svn diff http://svn.apache.org/repos/asf/subversion/trunk@1845414 http://svn.apache.org/repos/asf/subversion/branches/multi-wc-format
From a brief skimming review:
> +++ subversion/tests/cmdline/getopt_tests.py
> -warn_line_re = re.compile("WARNING: Plaintext password storage")
> +warn_line_re = re.compile("^WARNING: Plaintext password storage")
An unrelated change?
> Index: subversion/svn/info-cmd.c
> Index: subversion/svn/help-cmd.c
Looks like 'svn info' prints raw WC version numbers like "29" whereas 'svn help' prints svn version numbers like "1.12". Is there some way we could make that easier for normal folks to grok?
> Index: subversion/svn/svn.c
> + /* Check the latest supported version. */
> + /* FIXME: ### Should we return an error here instead? It seems
> + ### more friendly to issue a warning and continue with
> + ### the latest supported format. */
Not sure.
> Index: subversion/include/svn_wc.h
> + * The oldest supporter working copy format.
s/supporter/supported/g
> Index: subversion/libsvn_wc/wc.h
> * == 1.10.x shipped with format 31
> + * == 1.11.x shipped with format 31
and
> Index: subversion/libsvn_wc/upgrade.c
> +#ifdef SVN_TEST_MULTI_WC_FORMAT
> + case 32: return "1.12";
> +#endif
and other places in this file;
and everywhere:
> + * @deprecated ...
> + * @since New in 1.12.
Updates required since 1.12 was released.
I assume Brane has tested it, but someone else testing too would be good and I haven't. Then this looks likely to be ready to merge to trunk.
- Julian
Re: svn commit: r1843076 - /subversion/branches/multi-wc-format/
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Sun, 07 Oct 2018 22:08 +0200:
> svn diff http://svn.apache.org/repos/asf/subversion/trunk
> http://svn.apache.org/repos/asf/subversion/branches/multi-wc-format
Better:
svn diff http://svn.apache.org/repos/asf/subversion/trunk@r1843079 http://svn.apache.org/repos/asf/subversion/branches/multi-wc-format