Subversion sparse checkout depth and merge behavior

Question

Apache Subversion supports sparse checkouts via the --depth option, allowing a working copy to track only a subset of the repository tree. This is typically managed using svn update --set-depth to toggle between empty, files, immediates, and infinity.

A challenge arises when performing merges into a working copy configured with sparse depth settings. Because the merge process may encounter changes in directories or files that are intentionally excluded from the local disk, the interaction between the merge engine and the working copy metadata requires clarification.

Specifically, it is unclear how SVN handles merge conflicts or property changes for paths that exist in the repository but are marked as excluded in the sparse checkout.

Does a merge automatically trigger the retrieval of excluded files if they are targets of a change?
  How does the svn status command differentiate between a file missing due to a sparse checkout and a file deleted during a merge operation?

Siddharth · Answer

Direct answer
No. A merge does not automatically materialize paths excluded by sparse depth. Subversion applies merge only to nodes that exist in the working copy. Changes to paths outside the current sparse depth are skipped and not brought to disk.
Confirmed facts

Depth is stored per directory in working copy metadata. Valid levels are empty, files, immediates, infinity. Set with svn checkout --depth and changed with svn update --set-depth.
svn merge applies changes only to nodes present in the working copy. Paths outside the current sparse depth are not materialized, so additions or modifications in excluded directories are skipped.
Changing depth with svn update --set-depth after a merge does not retroactively apply skipped changes; a subsequent svn update or a re-run of the merge with increased depth is required to bring in previously excluded content.
svn status and svn info --show-item depth can be used to inspect current sparse depth per directory before deciding on merge strategy.

Likely explanation
Merges that introduce new files or directories under a sparsely checked-out parent will not create those items locally. The merge may complete with skipped items reported, or in some client versions it can surface obstructed/missing path errors depending on merge options and the nature of the change.
Rename/move operations crossing sparse boundaries can appear as delete+add in the working copy, increasing risk of conflicts if the target path is not checked out.
Steps for this case

Check current depth before merging:svn info --show-item depth .
svn info --show-item depth path/to/dir

Run the merge in a disposable copy first to see what is skipped:svn merge -r BASE:HEAD URLReview output for "skipped" or "missing" paths.
If you need changes from excluded paths, increase depth first, then merge:svn update --set-depth infinity path/to/parent
svn merge -r BASE:HEAD URL

Verify status:svn status
svn status -uDeleted by merge shows D. Sparsely excluded paths simply do not appear.

Depth changes are local to the working copy and do not affect repository history. Merging without sufficient depth can silently omit changes, leading to incomplete integration that is hard to detect later.
One diagnostic detail that changes the recommendation: Subversion client and server version. Merge reporting for missing sparse paths is version-sensitive between 1.5 to 1.14+. If you can share svn --version output, the exact skip/obstructed behavior can be confirmed.

Subversion sparse checkout depth and merge behavior

1 answer

0 question comments

Direct answer

Confirmed facts

Likely explanation

Steps for this case

Your perspective belongs here.