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