Storage format for remotenames.

[Durham Goode]

I wish we had some easily reusable serializer/deserializer instead of 
having to reinvent these every time.  What's our reasoning for not using 
json? I forget. If there are some weird characters, like control 
characters or something, that break json, I'd say we just use json and 
prevent users from creating bookmarks and paths with those names.

Otherwise we could move the paths to a separate section and format the 
file something like:

[paths]
1=ssh://blahblah.com//blahblah
2=ssh://blahblah.com//blahblah
3=ssh://blahblah.com//blahblah

[bookmarks]
HASH 2 book/mark/name
HASH 1 book2/foo/bar

[branches]
HASH 1
HASH 3

On 11/6/17 4:34 AM, Pulkit Goyal 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?
>
> Pulkit
>