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

Matt Mackall mpm at selenic.com
Fri Sep 9 14:14:29 EDT 2016


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.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list