[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