D1358: remotenames: store journal entry for bookmarks if journal is loaded

[pulkit (Pulkit Goyal)]

pulkit added a comment.


  In https://phab.mercurial-scm.org/D1358#23388, @smf wrote:
  
  > > durin42 added a comment.
  > > 
  > >   I don't think so. IMO the storage-only parts can and should go straight in core and be on by default. Exposing the data (by default, at least) we're collecting should probably go through an extension rodeo first.
  >
  > I agree with putting data generating functions and storage into core.
  >  Though, I disagree with the approach shown so far.
  >
  > We currently have at least two extensions in core that do something
  >  similar: blackbox and journal. Including remotenames, all three have
  >  overlapping data storage needs. The storage design of each is roughly:
  >
  > - blackbox logs each command
  > - journal logs update / move commands
  > - remotenames logs exchange commands
  >
  >   For something to make it to core, I would expect a unified way to deal with this duplication.
  
  
  While I agree with you that we should have a unified way to deal with any kind of duplication, I am unable to understand the duplication between data stored by remotanemes and one stored by journal and blackbox.
  
  Data stored for journal, blackbox and remotenames are as follows:
  
  Journal: time, user, namespace, name of changed item, command, nodes(old and new)
  Blackbox: date, user, node, process id, source and some kind of formatter message
  Remotenames: node, remotepath, name of bookmark or branch
  
  I strongly feel that data storage for journal and blackbox should be unified, I am not sure how these overlaps with remotenames one. I want to keep remotenames stored separately as information about a remoterepo can be used in operations like push and pull. @durin42 and others had some ideas around it. Moreover journal and blackbox data serves different purpose than that of remotenames.
  
  Can you please help me understanding how you think these data can be merged in one format.
  
  > For example, one solution could be:
  > 
  > 1. Create a v1 storage format api to hold this information (maybe start with sqlite or something very simple at first for the backend)
  > 2. Create a helper utility (decorator, or just wrap ui, etc)
  > 3. Use helper utility on all these commands to keep the data extension-agnostic
  > 
  >   This would be a great way to improve all our data logging extensions as well as keep things tidy in core. If it’s needed, I’d be more than happy to guide Pulkit and do the review for him if that is a bottleneck.
  
  I will also like to work on improving storage things in core but I don't think that intersects very much with remotenames. This thread will also interests you: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/107411.html

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1358

To: pulkit, #hg-reviewers
Cc: durin42, smf, dlax, mercurial-devel