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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri Apr 14 18:03:32 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
>>>>> 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.

What is the status of this series ? It seems dropped of patchwork but I 
don't think we have defined an alternative way forward.

I really would like to have something to play with in 4.2, is it 
possible to move forward with this series (it is behind an experimental 
flag, so we won't guarantee BC).

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list