Apache Subversion 1.15 Release Notes

New Feature Compatibility Table ¶

New Feature	Minimum Client1	Minimum Server	Minimum Repository	Notes

Upgrading the Working Copy ¶

Subversion 1.15 supports the working copy formats used by Subversion 1.0 and newer, as follows:

• Before using Subversion 1.15 with an existing Subversion 1.7 or older working copy, users will be required to run the svn upgrade command to upgrade working copy metadata to the new format. This command may take a while in some cases, and for some users, it may be more practical to simply checkout a new working copy.
• Subversion 1.15 can read and write existing Subversion 1.8 through 1.14 working copies in-place, without upgrading them. Subversion 1.8 through 1.15 can be used interchangeably on such working copies. These working copies are termed "format 31" working copies.
• Additionally, Subversion 1.15 adds a new working copy format that cannot be read by Subversion 1.14 and older. This format is called "format 32".

Both svn checkout and svn upgrade will produce format-31 working copies unless explicitly instructed otherwise.

To instruct Subversion to use a particular working copy format, pass the new --compatible-version=1.15 command-line option to these commands. If you use multiple Subversion clients, pass the version number of the oldest client that should be able to operate on the working copy.

Document what's new in format 32

Note: Subversion 1.15 cannot upgrade working copies that a 1.6 client would have refused to operate upon before an svn cleanup was run (with a 1.6 client). In other words, before upgrading to 1.8 or newer, a 1.6 or older client must be used to run svn cleanup on all 1.6 or older working copies that require cleanup. Likewise, Subversion 1.15 cannot upgrade corrupt working copies. Unfixable problems can arise from missing or corrupt meta-data inside .svn directories. Such damage to the working copy is permanent, and cannot be fixed even if svn cleanup is run prior to the upgrade.

If your working copy does not upgrade cleanly, please check out a new one.

Pristines On Demand ¶

Point to the "User Guide" in notes/i525/. Regenerate /docs/i525-user-guide.html from the source markdown.

At the user's option, the storage space requirement of a Subversion working copy can be reduced by up to 50%.

All Subversion working copies require extra storage space in addition to the size of the checked out files. By default, the total storage space required is slightly more than double the size of the checked out files.

Subversion uses most of that extra space to cache each file's BASE revision ("pristine") so that operations such as diff and revert can work offline, and commit can send just the modified portions of a file to the repository server rather than the whole file. This design optimises the speed and availability of these operations on the assumption that network connectivity to the repository may be a bottleneck while local storage is cheap.

In some use cases, it may be more sensible to fetch one or more pristines from the repository server when needed ("on demand"), rather than to cache all pristines all the time. Some example use cases:

• Very large files that change infrequently. In this case, the pristine is usually not needed but takes up space, doubling the storage requirement and providing little or no benefit.
• Working copies on storage-constrained devices with a fast, always-on connection to the repository server. In this case, network bandwidth is more readily available than local storage, inverting the original design assumption that local storage is cheap.
• Working copies on the same device as the repository.

As of Subversion 1.15, users can opt for Pristines On Demand at checkout time. This applies to the entire working copy:

$ svn checkout --store-pristine=no $REPO $WC

The command to check out a normal working copy is unchanged, but users may explicitly write:

$ svn checkout --store-pristine=yes $REPO $WC

When using Pristines On Demand, instead of caching pristines for all files all the time, Subversion will only fetch and cache those of individual files when needed, and will eliminate them when no longer needed.

Note that the space savings come at a tradeoff of requiring a connection to the repository for more operations as compared to a normal working copy and may, depending on network speeds and file sizes, introduce a perceptible delay when a pristine is downloaded.

The following table lists the Subversion commands that behave differently when using Pristines On Demand. For each command, it shows the difference in how that command accesses the repository.

	Working Copy Type
Command	Normal	Pristines On Demand
cat (BASE)	No	Hydrate
commit	Send-Delta	Send-Full
conflict resolving (resolve/merge/up/sw)	Sometimes	Sometimes (...)
diff (BASE)	No	Hydrate
revert	No	Hydrate
update/switch	Always	Always + Hydrate

Legend:

• Never: Does not contact the repository server.
• Always: Always contacts the repository server.
• Hydrate: This operation downloads and keeps the pristine for each file that has a local content modification (i.e., when svn status shows M in the 1st column) when its pristine is not already stored in the working copy. See notes 1 and 2 below.
• Send-Delta: Sends just the locally modified parts of each file's content.
• Send-Full: Sends the complete content of each locally modified file.

Additional Details:

Once downloaded, Subversion keeps a file's pristine locally cached in the working copy, so that further operations on the file will not download it from the repository again. It keeps the pristine until one of these operations either restores the file to an unmodified state or detects that the file is no longer modified. For example, commit and revert will immediately discard the pristine of each file they operated on, because that file will no longer be locally modified, whereas diff will discard the pristine only if it finds there are no differences.

Note 1: At the beginning of a given operation, Subversion will download missing pristines of at least the files that this particular operation will use. It may download those of other files too, that this particular operation will not use. For example, in the initial implementation of this feature, Subversion considers all potential files in the smallest subtree that spans all the target files of the operation. The details of this behaviour are subject to change before and after the feature is released.

Note 2: In evaluating differences between a file's working text and its BASE text, Subversion takes into account the "EOL style" and "keywords" settings. (See the svn:eol-style and svn:keywords properties.) Just as svn status does not show M in the first column for such differences, neither will these cause the pristine to be downloaded from the repository.

Limitations and Future Possibilities:

Currently, this feature applies to an entire working copy. That is, either all working files have their pristines cached (the default) or all working files use pristines on demand (--store-pristine=no). In the future, this feature may be enhanced to give users more granular control, such as by allowing the --store-pristine switch to apply to individual files.

Streamy Checkouts ¶

This new feature delivers a noticeable speed-up for svn checkout and svn update while addressing reports of network connection timeouts that could occur in the middle of these operations.

Previous versions of the Subversion client would fetch files from the server into the working copy's administrative directory, where each file's BASE revision is cached, and then separately "install" them to their proper location in the working copy. The "install" step involves copying and possibly translating the files to account for things like svn:eol-style and svn:keywords. This step was done per-directory and during that time, the client would hold the connection to the server open without reading anything through it. If this communication silence went on for too long, the server would eventually timeout and close the connection from its end, leading to annoying errors on the client side.

For example, assuming a 60 second HTTP timeout (the default in httpd 2.4.x) and reasonably fast storage on the client side, timeouts could be expected to occur while installing any directory about 6 GB in size or larger. (This value varied significantly based on numerous interrelated factors.)

This issue is addressed by making the checkout stream data to both the administrative directory and the projected working file simultaneously, reducing the actual "install" to an atomic rename. As a result, the svn checkout and svn update operations no longer hold the connection open without reading from it, eliminating the timeouts.

Clients will enjoy a noticeable speed-up due to improved network performance and reduced storage-level I/O.

Note: Streamy Checkouts are not yet implemented for svn export.

Command-line client improvements (client) ¶

Server-side improvements ¶

Client- and server-side improvements ¶