Design document for allowing alternative client side storage

Pierre-Yves David 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:

   https://www.mercurial-scm.org/wiki/CategoryNewFeatures

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
> well.
>
> 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.
>
> https://quip.com/TFR2Aw0lu0LB
>
> 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.
>
> Durham
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list