[PATCH] evolution: make troubles appear in default log (issue4686)

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri Sep 9 19:10:31 EDT 2016

On 09/09/2016 08:14 PM, Matt Mackall wrote:
> On Fri, 2016-09-09 at 18:38 +0200, Pierre-Yves David wrote:
>> On 09/09/2016 06:31 PM, Matt Mackall wrote:
>>> On Wed, 2016-09-07 at 15:23 -0400, Augie Fackler wrote:
>>>> On Fri, Sep 02, 2016 at 10:26:22AM -0500, Kevin Bullock wrote:
>>>>>> On Sep 2, 2016, at 04:38, liscju <piotr.listkiewicz at gmail.com> wrote:
>>>>>> # HG changeset patch
>>>>>> # User liscju <piotr.listkiewicz at gmail.com>
>>>>>> # Date 1472809041 -7200
>>>>>> #      Fri Sep 02 11:37:21 2016 +0200
>>>>>> # Node ID 463b164126a0db3f7147787ace34f74deeccc03f
>>>>>> # Parent  f148bfa40489269be2e48046734f81065129847a
>>>>>> evolution: make troubles appear in default log (issue4686)
>>>>>> This patch is request for comment, it does not update failing
>>>>>> test due to new information about troubles, it adds one test
>>>>>> to show how troubles looks like in default log.
>>>>> I think having a way to show troubled changesets as such in the log is a
>>>>> good idea, but the best we're able to do here is to add a new built-in
>>>>> template (cf. `hg log -T phases`). The default log output is very
>>>>> strongly a
>>>>> part of our command-line API, and changing it (even additively!) is a
>>>>> no-no.
>>>> There's caselaw for adding new lines to the -Tdefault output
>>>> (bookmarks come to mind), so I think we can probably do that?
>>> Bookmarks and branches did indeed get output added to default log. But no
>>> user
>>> would see that output until they started using those things (one of the
>>> reasons
>>> the "default" branch is invisible). So fragile tooling that couldn't handle
>>> them
>>> appearing wouldn't break simply from upgrading.
>>> There are two key points to this pattern:
>>> - no behavior change for repos not using a feature
>>> - output change is introduced WITH the feature
>>> This second is essential to ensure that there's no timeframe where users
>>> could
>>> start coding production scripts against the feature and then get broken
>>> simply
>>> by upgrading. Note that it IS ok if using a new feature breaks something
>>> (that's
>>> unavoidable!) but it's NOT ok if simply upgrading does.
>>> So this boat has already sailed for "troubles", because we've had them for a
>>> while.
>> But they have been experimental (with no in-core way to get them) the
>> whole time so backward compatibility is not to be expected yet.
> In theory, yes.
> In practice, if something useful is marked "experimental" for N years, the
> likelihood of it being widely used still rapidly converges to 100%. At which
> point, if you break it, people are still going to be justifiably disappointed
> and your appeals to it being experimental are going to ring false. Much like
> having a pre-1.0 version number, the experimental label only buys you a finite
> amount of time.

That might happen, yes. But this is not the case here. Evolution is not 
widely used, still advertise itself as experimental and still break BC 
on a regular basis (and people are usually pleased about the behavior 
hop). In addition we eventually hears about anyone running into these 
{troubles} regularly because tracking and solving them is too often 
still complicated right now (because tool need to be improved). One part 
the current struggle with {troubles} is the fact they do not appears in 
the default log. So I firmly think the right move here is to add this 
information to the default log.


Pierre-Yves David

More information about the Mercurial-devel mailing list