Patchwork evolution: make troubles appear in default log (issue4686)

login
register
mail settings
Submitter liscju
Date Sept. 2, 2016, 9:38 a.m.
Message ID <463b164126a0db3f7147.1472809126@liscju-VirtualBox>
Download mbox | patch
Permalink /patch/16529/
State Accepted
Headers show

Comments

liscju - Sept. 2, 2016, 9:38 a.m.
# HG changeset patch
# User liscju <piotr.listkiewicz@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.

First of all do evolution troubles should appear by default
in "default" log only or in templates as well?

In line:

evolutioninfo = [s for s in ['obsolete', ...

its hard coded all possible evolution troubles, are there any
list of them somewhere else?

I check if revision has troubles by doing:

rev in obsolete.getrevs(self.repo, s)

Is there a better way to get all troubles for revision?
Pierre-Yves David - Sept. 8, 2016, 8:47 p.m.
On 09/07/2016 09:39 PM, Kevin Bullock wrote:
>> On Sep 7, 2016, at 14:23, Augie Fackler <raf@durin42.com> wrote:
>>
>> On Fri, Sep 02, 2016 at 10:26:22AM -0500, Kevin Bullock wrote:
>>>> On Sep 2, 2016, at 04:38, liscju <piotr.listkiewicz@gmail.com> wrote:
>>>>
>>>> # HG changeset patch
>>>> # User liscju <piotr.listkiewicz@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?
>
> Why didn't we do it for phases then?

If I remember correctly (that was 5 year ago), we did not did it for 
phases because that would have affected pretty much every (well, most) 
`hg log` output in the wild without any change in user actions. As every 
new changesets are draft by default, `hg log` for normal user work-flow 
would have started displaying this new information, possibly confusing 
people (and maybe script?). I also suspect that Matt decision was also 
driven by the low importance of phases back then (still somewhat true)

We changed the output for bookmark because people have to opt in to 
bookmarks. People who never changed their work-flow and usage did not 
touched bookmark and did not got their output changed.

The same logic could be applied to evolution's trouble. People/work-flow 
who don't use anything related to evolution will not encounter 
evolution-troubles and will keep their log output unchanged . People who 
venture into new territory will get related information in their log.

To summarize, we did not changed output for phase because (1) it would 
affect all users (2) it would affect many commits. Neither of this 
applies to evolution-troubles, so we should probably include then in the 
default log output. This would be a great help for users encountering 
evolution troubles for the first time.

On the implementation side, the best way to introduce them might be 
through the namespace API.

Cheers
Matt Mackall - Sept. 9, 2016, 4:31 p.m.
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@gmail.com> wrote:
> > > 
> > > # HG changeset patch
> > > # User liscju <piotr.listkiewicz@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.

-- 
Mathematics is the supreme nostalgia of our time.
Pierre-Yves David - Sept. 9, 2016, 4:38 p.m.
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@gmail.com> wrote:
>>>>
>>>> # HG changeset patch
>>>> # User liscju <piotr.listkiewicz@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.

Cheers,
Matt Mackall - Sept. 9, 2016, 6:14 p.m.
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@gmail.com> wrote:
> > > > > 
> > > > > # HG changeset patch
> > > > > # User liscju <piotr.listkiewicz@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.

-- 
Mathematics is the supreme nostalgia of our time.
Pierre-Yves David - Sept. 9, 2016, 11:10 p.m.
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@gmail.com> wrote:
>>>>>>
>>>>>> # HG changeset patch
>>>>>> # User liscju <piotr.listkiewicz@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.

Cheers,

Patch

diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
--- a/mercurial/cmdutil.py
+++ b/mercurial/cmdutil.py
@@ -1266,6 +1266,13 @@  class changeset_printer(object):
         self.ui.write(_("changeset:   %d:%s\n") % revnode,
                       label='log.changeset changeset.%s' % ctx.phasestr())
 
+        evolutioninfo = [s for s in ['obsolete', 'unstable', 'suspended',
+                                     'extinct', 'bumped', 'divergent']
+                         if rev in obsolete.getrevs(self.repo, s)]
+
+        if len(evolutioninfo) > 0:
+            self.ui.write(_("evolution:   %s\n") % ', '.join(evolutioninfo))
+
         # branches are shown first before any other names due to backwards
         # compatibility
         branch = ctx.branch()
diff --git a/tests/test-obsolete.t b/tests/test-obsolete.t
--- a/tests/test-obsolete.t
+++ b/tests/test-obsolete.t
@@ -944,6 +944,31 @@  Test bundle overlay onto hidden revision
   |/
   o  0:4b34ecfb0d56 (draft) [ ] A
   
+  $ hg --config 'ui.logtemplate=' log --hidden
+  changeset:   3:b7d587542d40
+  tag:         tip
+  parent:      0:4b34ecfb0d56
+  user:        test
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     B+
+  
+  changeset:   2:eb95e9297e18
+  evolution:   obsolete, extinct
+  user:        test
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     temporary amend commit for 44526ebb0f98
+  
+  changeset:   1:44526ebb0f98
+  evolution:   obsolete, extinct
+  user:        test
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     B
+  
+  changeset:   0:4b34ecfb0d56
+  user:        test
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     A
+  
 
   $ hg incoming ../repo-bundleoverlay --bundle ../bundleoverlay.hg
   comparing with ../repo-bundleoverlay