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

The purpose of this branch is to try to make the text-bases in the working
copy optional [1][2].


Description of the approach:
----------------------------

The core idea is that we start to maintain the following invariant: only the
modified files have their pristine text-base files available on the disk.

- To avoid having to access the text-base, the "is the file modified?" check
  is performed by calculating the checksum of a file and comparing that to
  what's recorded in the working copy.

- A text-base of the unmodified file is the file itself, appropriately
  detranslated.

- To get into the appropriate state at the beginning of the operation, we walk
  through the current text-base info in the db and check if the corresponding
  working files are modified.  The missing text-bases are fetched using the
  svn_ra layer.  The operations also include a final step during which the
  no longer required text-bases are removed from disk.

- The operations that don't need to access the text-bases (such as "svn ls"
  or the updated "svn st") do not perform this walk and do not synchronize
  the text-base state.


For the production-ready state, it would probably make sense to also:
---------------------------------------------------------------------

 1. Complete the work on ^/subversion/branches/multi-wc-format so that the
    client would work with both the new and old working copy formats, for
    a seamless user experience and better compatibility.

 2. For the new working copy format, incorporate a switch to a different
    checksum type without known collisions instead of SHA-1.

3. Fix the minor issues written down as TODOs in the code.


References:
-----------

[1] https://issues.apache.org/jira/browse/SVN-525
[2] https://lists.apache.org/thread.html/r40aa795b9e0c1aabb392c43b64e540432a31e22d8b0d9de7202b4950%40%3Cdev.subversion.apache.org%3E