[PATCH 14 of 14 V3] streamclone: also stream caches to the client
Boris Feld
boris.feld at octobus.net
Thu Jan 25 08:37:07 UTC 2018
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.
More information about the Mercurial-devel
mailing list