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

Sean Farley sean at farley.io
Thu Nov 16 14:30:45 EST 2017


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)

>   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)?"

We're talking about putting something in core and I believe we should
really think this stuff out.
-------------- 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/20171116/8ae890dd/attachment.sig>


More information about the Mercurial-devel mailing list