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

Sean Farley sean at farley.io
Tue Nov 14 18:19:40 EST 2017


durin42 (Augie Fackler) <phabricator at mercurial-scm.org> writes:

> durin42 added a comment.
>
>
>   In https://phab.mercurial-scm.org/D1358#22899, @smf wrote:
>
>   > pulkit (Pulkit Goyal) <phabricator at mercurial-scm.org> writes:
>   >
>   > > pulkit created this revision.
>   > >  Herald added a subscriber: mercurial-devel.
>   > >  Herald added a reviewer: hg-reviewers.
>   > >
>   > > REPOSITORY
>   > >
>   > >   rHG Mercurial
>   > >
>   > > REVISION DETAIL
>   > >
>   > >   https://phab.mercurial-scm.org/D1358
>   > >
>   > > AFFECTED FILES
>   > >
>   > >   mercurial/remotenames.py
>   > >
>   > > CHANGE DETAILS
>   > >
>   > > diff --git a/mercurial/remotenames.py b/mercurial/remotenames.py
>   > >
>   > > - a/mercurial/remotenames.py +++ b/mercurial/remotenames.py
>   >
>   > A bit jumping the gun, no? I don't think we should be skipping putting
>   >  this initial stuff into hgext/remotenames.py.
>
>
>   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. 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20171114/22d105b6/attachment.sig>


More information about the Mercurial-devel mailing list