On Sat, 15 Apr 2017 00:03:32 +0200, Pierre-Yves David wrote: > 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).
Queued the series with minor typo fixes, thanks. As I said, we'll need to consider thoroughly how to pass this kind of information to user hooks, but that shouldn't block these experimental patches in. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
