[PATCH 14 of 14 V3] streamclone: also stream caches to the client

[Boris Feld]

On Sat, 2018-01-20 at 20:30 +0900, Yuya Nishihara wrote:
> On Sat, 20 Jan 2018 19:48:41 +0900, Yuya Nishihara wrote:
> > On Sat, 20 Jan 2018 00:47:19 +0100, Boris Feld wrote:
> > > # HG changeset patch
> > > # User Boris Feld <boris.feld at octobus.net>
> > > # Date 1516233012 -3600
> > > #      Thu Jan 18 00:50:12 2018 +0100
> > > # Node ID d44178c3fd9576e6ca6ab6e92b9823f117141079
> > > # Parent  9c2889f5050bea9d33be5f501eaf1ecf2d9617d3
> > > # EXP-Topic b2-stream
> > > # Available At https://bitbucket.org/octobus/mercurial-devel/
> > > #              hg pull https://bitbucket.org/octobus/mercurial-de
> > > vel/ -r d44178c3fd95
> > > streamclone: also stream caches to the client
> > > +        for name in cacheutil.cachetocopy(repo):
> > > +            if repo.cachevfs.exists(name):
> > > +                totalfilesize +=
> > > repo.cachevfs.lstat(name).st_size
> > > +                entries.append((_srccache, name, _filefull,
> > > None))
> > 
> > rbc-names and -revs files may be appended on write, so they
> > shouldn't be
> > hardlinked.
> 
> This comment seems a bit cryptic.
> 
> 'append' should be fine if we capture the file size while the store
> is locked,
> but we don't. Another possible problem is rbc-revs may be truncated,
> but I
> don't know if that's happen without stripping revisions.

Good spot, this is something we can improve in the next cycle. If some
cache files are append-only, I'm not sure of their locking and update
scheme, so doing full copy seems safer for now.