Shrink Large Subversion Working Copies with Sparse Checkouts

Start with a smaller working copy

A recursive Subversion checkout downloads every top-level directory in a repository, including documentation, legacy code, and dependencies you never build. On a large repository that means wasted disk space, slower updates, and more noise in svn status.

The practical takeaway is to use sticky sparse depth. Check out only the names you need, then expand individual subtrees when a task requires them. Depth changes what is materialized on your disk; it does not change the scope of a commit, so commits remain repository-wide and atomic.

How sticky depth works

svn checkout --depth creates a working copy whose directories are only partially populated. The depth setting is sticky per directory and stored in working-copy metadata, so Subversion remembers it across updates.

Common depth keywords:

• empty: the directory exists, but no children are present.
• files: only files in the directory, no subdirectories.
• immediates: files and immediate child directories, but no grandchildren.
• infinity: the full recursive tree.

Use svn update --set-depth to expand or prune an existing working copy. For example, --set-depth infinity restores a full tree, while --set-depth exclude marks a subtree so Subversion does not fetch it.

Depth is a local working-copy behavior, not a security boundary. Repository operations that accept URLs, such as branch or tag copies, are unaffected by the depth of your working copy. Behavior can vary by client release, so check svn --version and svn help update before adopting this pattern.

Worked example: expand only what you build

Run these commands in a terminal on a machine with network access to the repository and read permission for ^/trunk. Replace ^/trunk and the local path with values for your repository.

svn checkout --depth immediates ^/trunk monorepo
svn update --set-depth infinity monorepo/service-a monorepo/shared/lib
svn update --set-depth exclude monorepo/docs monorepo/legacy

The first command creates monorepo with top-level entries but no populated children. The next two commands expand service-a and shared/lib to full depth while marking docs and legacy as excluded. You can then build from monorepo/service-a without downloading the rest of the repository.

Verify the shape before you depend on it:

• svn status monorepo should list only the paths you expanded.
• du -sh monorepo shows disk use for the sparse tree.
• find monorepo -type f | wc -l counts materialized files.

Do not copy these numbers as expected results; your repository will differ. If a build depends on an excluded shared input, it will fail locally even though the repository is intact. Intentionally exclude one shared input once to observe that failure mode before you codify the recipe.

Because changing depth modifies working-copy state, you can roll back to a full tree with:

svn update --set-depth infinity monorepo

Trade-offs and limitations

• A build can pass on your machine and fail in CI if CI uses a full checkout or a different sparse shape.
• Switching branches with svn switch can be slower or surprising when many directories are excluded; re-run your depth recipe after switching.
• If the repository uses svn:externals, test whether externals under excluded parents are fetched; missing external content is a common build failure.
• Depth recipes should be role-based, not personal. Do not encode individual directory preferences in a shared script.

Make it a team contract

Publish a checked-in script such as sparse-checkout.sh that runs the checkout and update sequence for a role, and require CI to validate that the script produces a buildable tree. Keep ad hoc local tweaks out of the shared script.

Before you roll this out, run svn --version on your client, test the sequence in a disposable repository, and compare a full checkout against the sparse recipe using du -sh and find . -type f | wc -l. Once the recipe is stable, commit the script, not your personal directory preferences.