[PATCH 6 of 6 RFC] perf: define formatter locally if Mercurial is earlier than 2.2

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Jun 29 05:17:54 EDT 2016



On 06/18/2016 06:28 PM, FUJIWARA Katsunori wrote:
> At Sat, 18 Jun 2016 03:29:01 +0200,
> Pierre-Yves David wrote:
>>
>> On 06/17/2016 08:59 PM, Matt Mackall wrote:
>>> On Fri, 2016-06-17 at 19:04 +0200, Pierre-Yves David wrote:
>>>> The code itself seems mostly good to me (I need a second pass) but I'm a
>>>> bit confused about why we want to make perf.py backward compatible? Old
>>>> version of Mercurial can use the old version of the perf extension,
>>>> isn't that enough? I'm curious about your use case here.
>>>
>>> When you add new perf tests, you want to run them against historic hg. I hit
>>> this regularly.
>>
>> This quest seems a bit doomed to me as perf.py is likely to keep
>> evolving alongside the code base of Mercurial, breaking BC and using new
>> feature. Especially now that there is some people working on improving
>> our performance tracking.
>>
>> The way I usually handle this by applying a small patch with the new
>> perf thing when doing the initial comparision (same as I do with
>> regression tests)
>>
>> That said, I've nothing against this series if it help a bit, but I
>> think we should document (near the compatibility hack) the motive better
>> so that future contributor understant what is going on here.
> 
> I think:
> 
>   we have to:
> 
>   - make perf.py loadable with as old version hg as possible
> 
>   - make historical perf tests work with as old version hg as possible
> 
>   we don't have to:
> 
>   - make newer perf tests work with old version hg
>     (of course, it is good, if a newer test works with old hg)
> 
>     therefore, even if perf.py itself can be enabled with an old hg,
>     it isn't ensured that all perf tests are executable.
> 
> As far as I confirm, we can make recent perf.py loadable with
> Mercurial 1.1 or so by this series and some additional patches.

(sorry for the delay)

Okay, can you send a V2 of this series with extra comment about the
intend and boundary of the compatibility effort?

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list