<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 10, 2017, at 17:46, Gregory Szorc <<a href="mailto:gregory.szorc@gmail.com" class="">gregory.szorc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 10, 2017 at 2:24 PM, Augie Fackler<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:raf@durin42.com" target="_blank" class="">raf@durin42.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="HOEnZb"><div class="h5">On Mon, Nov 06, 2017 at 09:46:18AM -0800, Gregory Szorc wrote:<br class="">> On Mon, Nov 6, 2017 at 4:34 AM, Pulkit Goyal <<a href="mailto:7895pulkit@gmail.com" class="">7895pulkit@gmail.com</a>> wrote:<br class="">><br class="">> > Hey,<br class="">> ><br class="">> > I am working on porting functionalities from hgremotenames extension<br class="">> > to core. The hgremotenames extensions pull the information about<br class="">> > remote branches and remote bookmarks and store them to provide a<br class="">> > better workflow.<br class="">> ><br class="">> > The current storage format which hgremotenames has is having a file<br class="">> > `.hg/remotenames` in which each line is of the format `node nametype<br class="">> > name`, where<br class="">> > - `node` refers to node where the remotename was last seen<br class="">> > - `nametype` refers whether it's a bookmark or branch<br class="">> > - `name` consists of name of the remote and name of the remote<br class="">> > bookmark/branch<br class="">> ><br class="">> > At sprint, Ryan suggested to split the file according to bookmark and<br class="">> > branches so that we can read and write more easily which makes sense.<br class="">> ><br class="">> > While working on the patches, I found out that if the name of the<br class="">> > remote contains a '/', then the current storage format is not good and<br class="">> > we can fail to parse things correctly.<br class="">> ><br class="">> > Do you guys have any better ideas on how we can store remotenames?<br class="">> ><br class="">><br class="">> I have somewhat strong feels that we should strive to use append-only file<br class="">> formats as much as possible. This will enable us to more easily implement a<br class="">> "time machine" feature that allows the full state of the repository at a<br class="">> previous point in time to be seen. It also makes transactions lighter, as<br class="">> we don't need to perform a full file backup: you merely record the offset<br class="">> of files being appended to.<br class="">><br class="">> A problem with naive append-only files is you need to scan the entire file<br class="">> to obtain the most recent state. But this can be rectified with either<br class="">> periodic "snapshots" in the data stream (like how revlogs periodically<br class="">> store a fulltext) or via separate cache files holding snapshot(s). The tags<br class="">> and branches caches kinda work this way: they effectively prevent full<br class="">> scans or expensive reads of changelog and/or manifest-based data.<br class="">><br class="">> A revlog may actually not be a bad solution to this problem space. A bit<br class="">> heavyweight. But the solution exists and should be relatively easy to<br class="">> integrate.<br class=""><br class=""></div></div>I think for now we should not let the perfect (generalized undo) be<br class="">the enemy of the good (keeping track of where labels were on<br class="">remotes). For now, I'd be fine with using some sort of null-separated<br class="">file format. It's gross, but it should let Pulkit land the feature,<br class="">and since it's largely advisory data it's not a crisis if we improve<br class="">it later.<br class=""></blockquote><div class=""><br class=""></div><div class="">I agree. A generalized undo format is a lot of work and is definitely scope bloat for remote names.</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote></div><br class=""><div class="">That sounds relevant for journal, less so for remotenames.</div><div class=""><br class=""></div><div class="">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...</div><div class=""><br class=""></div></body></html>