Design document for allowing alternative client side storage
pierre-yves.david at ens-lyon.org
Fri Mar 11 11:13:22 EST 2016
Thanks for sharing this. Can we have a Plan page talking about it?
It might be fine to keep most of the actual content in the quip for now
if you really want to avoid the wiki, but a small page with summary and
a link to the quip would be nice. This will make you idea show up in:
On 03/11/2016 01:46 AM, Durham Goode wrote:
> We're going to be investigating alternative client side storage
> strategies for Mercurial at Facebook over the next few months. We've
> already moved off revlogs for our filelog storage (via remotefilelog),
> and will likely need to avoid revlogs when we move to tree manifests as
> As part of this, I've put together a design doc describing a high level
> idea that would let us experiment with different storage backends, and
> provides a path for migrating existing users over. It's currently
> focused on situations like ours, where you have parts of the repository
> on a central server and parts on the client, but the overall design may
> be of interest to the community.
> It's a bit light on concrete format details, since the main goal is to
> put abstractions in place that would let us break away from the existing
> formats and experiment.
> Feel free to comment on the doc (you have to sign in to Quip to
> comment), or respond by email.
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
More information about the Mercurial-devel