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#23588, @durin42 wrote:
  
  > In https://phab.mercurial-scm.org/D1358#23388, @smf wrote:
  >
  > > For something to make it to core, I would expect a unified way to deal
  > >  with this duplication. 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.
  > >   - F46176: signature.asc <https://phab.mercurial-scm.org/F46176>
  >
  >
  > I like where your head is at, but I'm unclear if Pulkit et al will be willing to do this extra work. Pulkit, is this something that we could get you to put on the path of "remotenames in core"?
  
  
  I will be happy to do that work but there are two things involved here:
  
  1. Improving end-user experience
  2. Improving our backend storage
  
  If we do 1) after the completion of 2), then I think we won't have enough time to test the new feature in this cycle or maybe we need to wait for the next cycle. I don't see a very hard dependency here between both and they can go in parallel which I am again happy to do. @smf  how does this sounds to you? If this sounds good to you, I will send a new version of the series and start a thread on mailing related to improving the storage API's.

REPOSITORY
  rHG Mercurial

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

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