[PATCH V2] journal: new experimental extension

[Martijn Pieters]

On 20 Jun 2016, at 22:54, Sean Farley <sean at farley.io> wrote:
> Martijn Pieters <mj at zopatista.com> writes:
> 
>> # HG changeset patch
>> # User Martijn Pieters <mjpieters at fb.com>
>> # Date 1466440095 -3600
>> #      Mon Jun 20 17:28:15 2016 +0100
>> # Node ID ce6a007db814d426159adc01b999b22c1a2ced05
>> # Parent  fcaf20175b1b05aa753e1b9f65f10d35a86224df
>> journal: new experimental extension
>> 
>> Records bookmark locations and shows you where bookmarks were located in the
>> past.
>> 
>> This is the first in a planned series of locations to be recorded; a future
>> patch will add working copy (dirstate) tracking, and remote bookmarks will be
>> supported as well, so the journal storage format should be fairly generic to
>> support those use-cases.
> 
> I've brought this up at the previous sprints but if we're going to be
> making a generic storage format then is it worth it to combine this with
> the blackbox format?
> 
> It seems to me that they will both have to solve the same problems
> (locking, generic format, etc.). If we put some thought into this now,
> we could perhaps get some server-side features and maybe extension
> points.
> 
> My thinking is that by having a storage layer, extensions could do
> queries like:
> 
> select * where type = 'remotebookmark'
> 
> and even adding that data so that core doesn't have to have a hard-coded
> list.
> 
> Perhaps it's too early for this, though.

Because blackbox serves a different use case (post-mortem analysis) and records data in a very different manner (via ui.log hooks) I did not see an easy path to consolidating the two. journal needs both different data (specifically recording old and new hashes) as well as the ability to filter quickly on a specific name, neither of which blackbox can currently support without a major overhaul.

I perhaps could have used `ui.log()` calls to record the information, but blackbox doesn't currently lock, and locking during the dirstate writing phase (done during unlock) adds the requirement to *not* lock as needed, complicating the API a little more. Listing journal entries would also require that rotated files are taken into account and require more scanning and parsing of the info to pull out just the info journal is interested in. That all felt like bending blackbox rather far away from its original purpose, as a fire-and-forget log recorder.

That said, I see a future where Mercurial makes heavy use of SQLite to track loads of different kinds of extra information about your repository and working copy. In that scenario it would make sense for both blackbox and journal to be fed by the same tables (assuming that the previous location for working copies and bookmarks is easily queried for).

Martijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160621/5de43162/attachment.sig>