Initial checkout should scale well for large projects

Once an initial checkout has been made with Subversion, "switching" to a new
tag/branch is very efficient, using only the deltas between the two versions of
the remote repository, rather than a time-consuming fresh checkout.  This is a
great feature.

However, for very large projects the initial checkout from a remote repository
can be quite time consuming while all files are transferred to the local working
copy.

This initial checkout could be optimized using a modified version of a caching
DAV filesystem that transfers files either on-demand or predictively, and also
integrates the .svn directories used by the client.

From the client's perspective, such as command line, RapidSVN, TortoiseSVN, etc,
the filesystem appears identical to the copy-everything-first scenario.

From the user's perspective, initial checkout is a lot faster, and the real cost
of the initial checkout is amortized over many svn operation as the user
interacts with the working copy.

Exposure of this feature might be as simple as a single argument to the checkout
command.  For example:  svn co -dynamic ...

Of course, the initial checkout is pinned to a specific version of the
repository, so the contents of subdirectories is predictable, even if they are
requested much later.

As for implementation, the davfs module for mounting webdav servers on Linux
might provide a useful starting point.  On NTFS, reparse points are probably a
big part of the answer.

Original issue reported by jfallows