Sparse working copy

[Matt Harbison]

Paul Boddie <paul.boddie <at> biotek.uio.no> writes:

> 
> On 16/11/12 12:43, Jan Vrany wrote:
> > I would need a "sparse" working copy, a handy feature of SVN. That 
> > means, a possibility to clone a repository and have only a part of the 
> > of the files checked out in the working copy (only subdirectory of 
> > whole tree and and not in full depth). I mean, lets say full structure 
> > is:
> >  p1
> >   - c1.st
> >   - c2.st
> >   - makefile
> >   - plugin1
> >     - data1
> >   - plugin2
> >     - data2
> >
> > To modify c1.st, i need to clone the repository sparsely, so
> > the working copy contains only c1.st, c2.st, makefile and possibly
> > empty plugin1 & plugin2. I do not need to have data1 and data2 in my
> > WC for they are HUGE (1GB, say) and I certainly won't touch them
> > from IDE.
> 
> As far as I know, and I'm sure corrections will follow, if you have 
> chosen to manage data1 and data2 in the repository then you would need 
> to have their history stored within the .hg directory structure, but you 
> could avoid having them "checked out" (in addition to occupying space in 
> the history) by doing something like this:
> 
> cd p1
> hg update null
> hg revert -r tip c1.st c2.st makefile

Be careful with this.  If you have updated to the null revision, *that* will be
the parent when you commit.  The commit won't be attached to tip (or whatever
revision you specified for revert), which I assume is the behavior you want.

If you have 1Gb files that need to be versioned and maven or the equivalent
won't work, I'd say you definitely want to use the largefiles extension (which
ships with hg), or a 3rd party equivalent.  Largefiles won't let you update to
a revision without also placing those files in the working directory though.


You might be able to do something with subrepos though.  If you can setup your
tree like this:

  p1
  - core
    - c1.st
    - c2.st
    - makefile
  - plugin1
    - data1
  - plugin2
    - data2

where 'core' is a repo with all the stuff you want to edit, and pluginX are
repos with all the big files.  p1 then ties those together as subrepos.  You
can then checkout 'core' whereever you want, edit, commit and push back.  Note
you probably still want the full p1 directory tree somewhere, so you can update
'core' there to the new revisions added, and do a commit on p1 to snapshot the
whole tree.

All that said, you should probably be pretty comfortable with hg before diving
into subrepos.   There are probably still sharp corners, and it is considered a
feature of last resort [1].  It won't work if the core files are in the same
repo that reference the big file subrepos (i.e. if you can't add the 'core'
directory), because subrepos are automatically updated when their parent repo
is (so it is equivalent to the problem you are having now).  For that, you
might want to search this ML a couple months back for the guestrepos extension,
which might be able to handle this.


--Matt

[1] http://mercurial.selenic.com/wiki/Subrepository