svn commit: r1905478 - /subversion/branches/pristines-on-demand-on-mwf/BRANCH-README

[ko...@apache.org]

Author: kotkov
Date: Wed Nov 23 11:11:55 2022
New Revision: 1905478

URL: http://svn.apache.org/viewvc?rev=1905478&view=rev
Log:
On the 'pristines-on-demand-on-mwf' branch:

* BRANCH-README: Remove the part related to the 'multi-wc-format' branch that
  has been merged to trunk in r1897946.  Update the high-level task list to
  reflect this merge.

Modified:
    subversion/branches/pristines-on-demand-on-mwf/BRANCH-README

Modified: subversion/branches/pristines-on-demand-on-mwf/BRANCH-README
URL: http://svn.apache.org/viewvc/subversion/branches/pristines-on-demand-on-mwf/BRANCH-README?rev=1905478&r1=1905477&r2=1905478&view=diff
==============================================================================
--- subversion/branches/pristines-on-demand-on-mwf/BRANCH-README (original)
+++ subversion/branches/pristines-on-demand-on-mwf/BRANCH-README Wed Nov 23 11:11:55 2022
@@ -1,72 +1,3 @@
-This branch is the rebase of the 'pristines-on-demand' branch on top
-of the 'multi-format-wc' branch, as part of resolving issue #525.
-
-Each of the two original branches had its own 'BRANCH-README' file;
-what follows is just those two files concatenated one after the other.
-(If this combined branch turns out to be long-lived, then we may do a
-more thoughtful merge of the two files at some point, but for now we
-expect this branch to be merged to trunk pretty soon anyway.)
-
-============================================================================
-BRANCH-README from 'multi-format-wc':
-============================================================================
-
-Client support for multiple working copy versions
--------------------------------------------------
-
-Currently the working copy code can use exactly one WC version at a
-time. This limitation is a problem for users who, for one reason or
-another, have to use multiple client versions at the same time. The
-fact that 1.8.x and 1.9.x use the same WC version was a boon to such
-users, and there's no good reason that the WC implementation couldn't
-have some leeway.
-
-To this end, we'll introduce the concept of "supported version" to the
-working copy. This is the minimum WC format supported by a particular
-client. By default, the client will create new working copies with the
-latest format[*], but will support a small range of older versions as
-well.
-
-The client should be able to not only use but also create working
-copies in an older, non-current format. To this end, certain client
-commands will get a new option, "--compatible-version", which behaves
-analogously to the option in "svnadmin create".
-
-For example:
-
-    svn checkout --compatible-version=1.8
-
-will create a new working copy with format 31. However,
-
-    svn checkout --compatible-version=1.7
-
-will fail, because we (currently) do not support 1.7 working copies in
-newer clients.
-
-Analogously,
-
-    svn upgrade --compatible-version=1.9
-
-will upgrade an older working copy to format 31.
-
-The "svn --version" command will display a list of compatible working
-copy versions.
-
-OPTIONAL: The "svn upgrade" command may grow an option to only show
-          the current and target working copy versions.
-
-
-[*] New externals working copies must inherit the format from their
-   parent working copy, because mixed-format working copies are a) a
-   Bad Thing, and b) defeat the purpose of this feature, which is
-   support for multiple versions of the client in the same working
-   copy.
-
-   
-============================================================================
-BRANCH-README from 'pristines-on-demand':
-============================================================================
-
 Pristines-on-Demand
 -------------------
 
@@ -105,6 +36,8 @@ For the production-ready state, it would
     client would work with both the new and old working copy formats, for
     a seamless user experience and better compatibility.
 
+    (Done in r1897946)
+
  2. For the new working copy format, incorporate a switch to a different
     checksum type without known collisions instead of SHA-1.