[PATCH 4 of 4 NEW-CONCEPT] track-tags: write all tag changes to a file
pierre-yves.david at ens-lyon.org
Fri Apr 7 12:56:52 EDT 2017
On 04/07/2017 05:25 PM, Yuya Nishihara wrote:
> 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
>>>> 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.
Can we move forward with a file for now?
The feature is experimental so we have time to think of an alternative
before we enforce backward compatibility.
More information about the Mercurial-devel