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.
-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 probably make sense to also:
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.
