Improving requirement error message

Adrian Buehlmann adrian at cadifra.com
Wed Jun 22 02:13:12 CDT 2011


On 2011-06-22 02:44, Pierre-Yves David wrote:
> Here is a reset of the discussion about improving the current requirement error message.
> 
> Timing is very tight, I suggest:
> 
> - 2011-06-22 People give view about what should be fixed,
> - 2011-06-23 People agree on a new phrasing for the message,
> - 2011-06-24 patch is written (before pre-release).
> 
> Bellow are points I believe necessary to be covered by this error message.
> 
> Issue with the current message:
> ====================
> 
> Lack hint about how to solve the issue
> --------------------
> This is the main issue in my opinion.
> 
> The user just get the error and have no clue about how to handle it. 

This is not true. For 1.9 we will have:

  abort: unknown repository format: requires feature 'foo' (upgrade
Mercurial)!

instead of

  abort: requirement 'foo' not supported!

http://selenic.com/repo/hg/rev/973959fbe8ec

The hint is "upgrade Mercurial", which I think is enough.

> - Having a dedicated help entry may help but it won't be made for 1.9.0,
> 
> - linking to a dedicated page on the wiki seems necessary anyway. We need to update new requirement which are by definition unknown by the version that get the error.
> 
> Only display the first missing feature
> --------------------
> Hiding the full issue to the user might be very frustrating. This is something to fix in my opinion
> 
> The goal is to avoid the following scenario:

Which we already avoided by improving the error message for 1.9 with
http://selenic.com/repo/hg/rev/973959fbe8ec

which I think is enough

> 1) Bob using version 1.6 try to access repo created with dotencode+generaldelta,
> 2) Bob get an error --> abort: […] requires features 'dotencode',

We can't change his 1.6 any more.

> 3) Bob check the wiki see that dotencode is introduced in 1.7,
> 4) Bob install version 1.8.0 (may include fighting with IT departement),

If Bob doesn't install the latest and greatest version we make here,
then it's not our fault.

If he needs to fight with his IT department, it isn't our fault either.

> 5) Bob get an error --> abort: […] requires features 'generaldelta',
> 6) Bob check the wiki see that generaldelta is introduced in 1.9,
> 7) Bob install version 1.9.0 (may include fighting with IT departement).
> 8) Bob access it's repo (at last).
> 
> Note:
> 
> Version and requirement used here are for demo purpose only as version prior 1.9
> wont have this changeset.
> 
> Such scenario are far from pure theorycraft, current mercurial version in debian
> stable (squeeze) is 1.6.x. Current mercurial version in stable-backport is
> 1.8.4.
> 
> 
> Does not make explicit that only the action of reading a local repository raise the error.
> --------------------
> 
> There is *only* one case were Mercurial don't preserve backward compatibility. Highlighting that this error is the only one user can encounter is better. Being more explicit will make user more confident in the process of upgrading mercurial in general.
> 
> Need to be explicit that the issue comes from the version of hg used (vs the version that created this repo).
> --------------------
> 
> Having an explicit reference to a "version issue" make the error less mysterious. (The current message say "upgrade mercurial" to cover this point)
> 
> 
> 
> Have fun commenting the issue
> 


More information about the Mercurial-devel mailing list