Storage format for remotenames.

[Gregory Szorc]

On Mon, Nov 6, 2017 at 4:34 AM, Pulkit Goyal <7895pulkit at gmail.com> wrote:

> Hey,
>
> I am working on porting functionalities from hgremotenames extension
> to core. The hgremotenames extensions pull the information about
> remote branches and remote bookmarks and store them to provide a
> better workflow.
>
> The current storage format which hgremotenames has is having a file
> `.hg/remotenames` in which each line is of the format `node nametype
> name`, where
>   - `node` refers to node where the remotename was last seen
>   -  `nametype` refers whether it's a bookmark or branch
>   - `name` consists of name of the remote and name of the remote
> bookmark/branch
>
> At sprint, Ryan suggested to split the file according to bookmark and
> branches so that we can read and write more easily which makes sense.
>
> While working on the patches, I found out that if the name of the
> remote contains a '/', then the current storage format is not good and
> we can fail to parse things correctly.
>
> Do you guys have any better ideas on how we can store remotenames?
>

I have somewhat strong feels that we should strive to use append-only file
formats as much as possible. This will enable us to more easily implement a
"time machine" feature that allows the full state of the repository at a
previous point in time to be seen. It also makes transactions lighter, as
we don't need to perform a full file backup: you merely record the offset
of files being appended to.

A problem with naive append-only files is you need to scan the entire file
to obtain the most recent state. But this can be rectified with either
periodic "snapshots" in the data stream (like how revlogs periodically
store a fulltext) or via separate cache files holding snapshot(s). The tags
and branches caches kinda work this way: they effectively prevent full
scans or expensive reads of changelog and/or manifest-based data.

A revlog may actually not be a bad solution to this problem space. A bit
heavyweight. But the solution exists and should be relatively easy to
integrate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20171106/a76856c5/attachment.html>