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

pulkit (Pulkit Goyal) phabricator at mercurial-scm.org
Thu Nov 16 17:47:46 EST 2017

pulkit added a comment.

  In https://phab.mercurial-scm.org/D1358#23866, @smf wrote:
  > pulkit (Pulkit Goyal) <phabricator at mercurial-scm.org> writes:
  > > 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
  > Why not union them as such:
  > datetime, user, namespace, node, process id, args (name of changed item,
  >  remotepath, etc), input (old nodes), result of command (new nodes, etc)
  1. remotenames don't need datetime, user, process id, result of commands and the etc's.
  2. if we store all the journal data, blackbox data and remotenames data all at one place, we will certainly need one more field which will store whether it's remotenames data, journal or blackbox as otherwise it will be slow to read all the data and find the data we need.
  >>   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.
  > I don't really see them as different purposes. Questions like, "What was
  >  the state of my repo yesterday (journal)?" or "What was the state of
  >  remote yesterday (remotenames, though future features that is append
  >  only)?" or "What were the last five commands and their input
  >  (blackbox)?"
  Sorry Sean, but I do see them as different purposes because of the following points:
  1. This information is related to a remote repo. It will be very good if we have storage of remote repo information and local repo information separately.
  2. remotenames will be a part of the UI (commands like log etc.)
  3. There are revsets related to remotenames
  4. remotenames will have new namespaces
  5. There is lot of data stored by journal and blackbox which is not required for remotenames.
  Even we get to a stage where we pulls the journal or blackbox information from a remote repo and store them locally, we should store them atleast in different files as that of local journal and blackbox information.
  If we want to unify the storage for remote and local things, then we should think about having a unified storage for bookmarks(local+remote) and branches(local+remote).
  > We're talking about putting something in core and I believe we should
  >  really think this stuff out.

  rHG Mercurial


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

More information about the Mercurial-devel mailing list