Sparse checkouts

Durham Goode durham at fb.com
Mon Jun 2 13:40:56 CDT 2014


I've been playing around with sparse checkouts in Mercurial and figured 
I'd send out a draft version before I go on vacation for a few weeks.  
By 'sparse' I mean: 'only certain parts of the working copy are laid 
out, but history is completely unaffected'.

The basic way it works is, there's a .hg/sparse file that contains a 
list of the included and exclude patterns for their checkout.  It is 
modified using 'hg sparse --include/--exclude/--delete PATTERNS...'.  
When rules are added, the checkout is immediately adjusted to reflect 
the new rule (no --refresh or anything necessary).

For large organizations, they can commit a .hgsparse file to the actual 
repository that contains 'profiles' that specify different sparse 
checkouts people can use.  For example, if I enable the 'frontend' 
profile ('hg sparse --enable-profile frontend'), I will always have the 
right files checked out to work on frontend code, so I never have to run 
'hg sparse'.  As other engineers change that profile, the user's working 
copy is automatically updated as they checkout newer (or older) revisions.

If a merge or a rebase encounters a conflict in part of the tree that is 
not in the checkout, we abort entirely and require them to add more 
files to the checkout.

The extension itself (all the mercurial integration/monkeypatching is in 
the first 130 lines):

https://bitbucket.org/DurhamG/hg/src/de9df54e2667d80f78b15e7b754033b550b6f1a8/hgext/sparse.py

The full commit, with tests:

https://bitbucket.org/DurhamG/hg/commits/de9df54e2667d80f78b15e7b754033b550b6f1a8

This is just me hacking around, so it hasn't been used in production 
anywhere.  But the tests pass! So it's probably bug free :p

Durham


More information about the Mercurial-devel mailing list