> On Nov 10, 2017, at 17:46, Gregory Szorc <gregory.sz...@gmail.com> wrote: > > On Fri, Nov 10, 2017 at 2:24 PM, Augie Fackler <r...@durin42.com > <mailto:r...@durin42.com>> wrote: > On Mon, Nov 06, 2017 at 09:46:18AM -0800, Gregory Szorc wrote: > > On Mon, Nov 6, 2017 at 4:34 AM, Pulkit Goyal <7895pul...@gmail.com > > <mailto:7895pul...@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. > > I think for now we should not let the perfect (generalized undo) be > the enemy of the good (keeping track of where labels were on > remotes). For now, I'd be fine with using some sort of null-separated > file format. It's gross, but it should let Pulkit land the feature, > and since it's largely advisory data it's not a crisis if we improve > it later. > > I agree. A generalized undo format is a lot of work and is definitely scope > bloat for remote names. > > But my point about append-only data structures still stands. You basically > get the Git equivalent of the "reflog" for free if you e.g. store this data > in a revlog.
That sounds relevant for journal, less so for remotenames. Would it make sense to try and come to an agreement on a single format we can use for node->label storage? It's come up in the bookmarks binary part patches as well...
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel