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