[PATCH 4 of 4 NEW-CONCEPT] track-tags: write all tag changes to a file

Yuya Nishihara yuya at tcha.org
Fri Apr 7 11:25:22 EDT 2017


On Fri, 7 Apr 2017 15:11:16 +0200, Pierre-Yves David wrote:
> On 04/06/2017 05:27 PM, Yuya Nishihara wrote:
> > On Thu, 6 Apr 2017 01:09:47 +0200, Pierre-Yves David wrote:
> >> On 04/05/2017 10:54 PM, Jun Wu wrote:
> >>> I don't think "writing things that hook *may* need to filesystem" is a good
> >>> approach. It introduces unnecessary overhead if the hook does not need that
> >>> information.
> >>
> >> I do not find the overhead concerning.
> >>
> >> The thing to keep in mind is that if they are many things to write down,
> >> this also means many thing changed during the transaction. So the
> >> overhead is likely minimal. In the tags cases, just updating the various
> >> tags related cache is going to be much more expensive that writing this
> >> to disk.
> >
> > I agree Pierre-Yves in that I/O overhead wouldn't matter. On the other hand,
> > I think the slowness of calling back an hg command doesn't matter, too.
> 
> The cost of a round-trip to Mercurial is close to a minimum of 0.1s. And 
> every hooks who needs fine transaction data will have to pay it. 
> Possibly multiple time. One the other hand writing down a file is a one 
> time operation that do not add overhead to each hook.
> So I'm still leaning toward the file solution.
> 
> > As the journal extension collects similar information for bookmarks, can't
> > we integrate the tag tracking with the journal?
> 
> Journal is currently an extension, and an experimental one. I would 
> prefer not to be scope bloated into solving the two points aboves before 
> getting theses features done.
> 
> Journal is also tracking name movement, not transaction. We would have 
> to teach journal about transaction first (that is probably something 
> useful to do, but more scope bloat :-) )

Okay, so this tags.changes file describes the current transaction, which is
a different concept than the journal. I agree.

I prefer not introducing new file format which we'll have to document and
maintain forever, but I have no better idea.


More information about the Mercurial-devel mailing list