Skip to content
Snippets Groups Projects

help: categorizing evolve and topic commands

Merged Rodrigo Damazio Bovendorp requested to merge topic/default/help_categories into branch/default

This makes them show up under the right categories in 'hg help'.

Differential Revision: https://phab.mercurial-scm.org/D6999

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Ugh, next time I'll be aware how gitlab cuts off the context that's below the comments on the Discussions tab. It looks better on the Changes tab.

  • Rodrigo Damazio Bovendorp resolved all discussions

    resolved all discussions

  • I agree about the context being cut off :) I noticed that if I click on the file name, it gives me ellipsis I can click to expand, but not on the merge request screen.

  • Administrator added 2 commits

    added 2 commits

    • d3ad50b40a4e - 1 commit from branch branch/default
    • 10ccccd481cd9f435b7018982ba6ff0d5ba1509b - help: categorizing evolve and topic commands

    Compare with previous version

  • Okay, the categories look good, but since evolve supports older versions of hg that don't have these categories yet, that needs to be handled somehow.

    The help categories appeared first in hg 4.8, and, as the patch is now, testing evolve on older versions of hg (i.e. ~/hg-features/stable-versions/hg-4.7/tests/run-tests.py test-topic.t) fails with

    *** failed to import extension topic: 'command' object has no attribute 'CATEGORY_CHANGE_ORGANIZATION'

    Currently, evolve supports "4.5.2 4.6.2 4.7 4.8 4.9 5.0 5.1" (from metadata.py), and maybe we can drop some older versions (@marmoute ?), but I think we still want to support 4.7 for now.

    Edited by Anton Shestakov
  • Ok, what's your typical strategy for supporting older versions?

    That test fails with a bunch of other errors on 4.7 even without my changes - how do you test it properly with that?

    Anyway, if it's just about it not crashing, I'm pushing a version with a suggestion that makes test-topic.t "pass" (only show the same errors as on the public head) for 4.7, let me know if that looks acceptable and I'll fix evolve in a similar way.

    Edited by Rodrigo Damazio Bovendorp
  • (GitLab detail: I ended up pushing twice 'cause I had forgotten to save a comment, and now "Compare with previous version" shows the wrong two versions, you want to check against version 3)

  • Yeah, since we try and support multiple hg versions, tests can be messy sometimes. There are mercurial-X.Y compatibility branches where tests are supposed to pass on hg X.Y, but stable and default of evolve aren't always clean. But in general, default branch of evolve soft-targets default branch of hg, which means with hg 4.7 it's expected to have some output changes, just nothing too crazy.

  • We try to support at least the four major version. And adjust around that from what major linux distribution supports and how annoying it is to support these older version.

    Right now we can probably drop some of the older version if they get annoying. @av6 what's your rational to cutoff at 4.7 ?

    We deal with compatibility using the evolve.compat and topic.compat module. They offer function with the appropriate logic to deal with multiple version. The expected output for each version lives in their respective mercurial-x.y branches. The Readme may explain that a bit. I don't think @rdamazio needs too dive too much into that since his change will be "crash at init or run".

  • Rodrigo Damazio Bovendorp resolved all discussions

    resolved all discussions

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading