[PATCH 03 of 10] commands: stub for debugupgraderepo command

[Pierre-Yves David]

On 11/22/2016 06:15 AM, Gregory Szorc wrote:
>
>
> On Mon, Nov 21, 2016 at 6:05 PM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
> wrote:
>
>
>
>     On 11/06/2016 05:40 AM, Gregory Szorc wrote:
>
>         # HG changeset patch
>         # User Gregory Szorc <gregory.szorc at gmail.com
>         <mailto:gregory.szorc at gmail.com>>
>         # Date 1478391613 25200
>         #      Sat Nov 05 17:20:13 2016 -0700
>         # Node ID 9daec9c7adabe8c84cf2c01fc938e010ee4884d6
>         # Parent  ed3241d8b00e476818ff1aec3db0136bf960de35
>         commands: stub for debugupgraderepo command
>
>         Currently, if Mercurial introduces a new repository/store feature or
>         changes behavior of an existing feature, users must perform an
>         `hg clone` to create a new repository with hopefully the
>         correct/optimal settings. Unfortunately, even `hg clone` may not
>         give the correct results. For example, if you do a local `hg clone`,
>         you may get hardlinks to revlog files that inherit the old state.
>         If you `hg clone` from a remote or `hg clone --pull`, changegroup
>         application may bypass some optimization, such as converting to
>         generaldelta.
>
>         Optimizing a repository is harder than it seems and requires more
>         than a simple `hg` command invocation.
>
>         This patch starts the process of changing that. We introduce
>         `hg debugupgraderepo`, a command that performs an in-place upgrade
>         of a repository to use new, optimal features. The command is just
>         a stub right now. Features will be added in subsequent patches.
>
>
>     I had a similar series in progress which a slightly different
>     naming/behavior.
>
>     * 'hg debugformat' list details about the current repository format
>     (and possible upgrade)
>
>     * 'hg debugformat --upgrade' performs actual upgrade (more on this
>     in the next patch)
>
>     I'm not saying you should restart your whole series to match this,
>     but I'll most probably submit a rename proposal to match the above
>     once this is in.
>
>
> TBH, I'm not a fan of "debugformat." The main reason is "format" isn't
> exactly unambiguous: it can mean several things from deleting all data
> (i.e. "formatting a disk") to UI presentation options. If I weren't
> aware that the [format] config section existed, I'd have no clue that
> "format" referred to the on-disk repository "format."

As I know the "format" config for a long time, the "debugformat" name 
was natural to me. I'm not sure how the naming is important, user are 
not really expected to go hunting for debug command themselve, and if 
they do a proper help is probably enough. I won't have a too strong 
opinion about the name but I see a good feedback cycle between 
"debugformat" and "[format]" knowing/finding one help to find the other.

> I think having "upgrade" in the name is beneficial because it says what
> the command does ("upgrade" the repository to a new and more modern
> format). That being said, I would be open to the idea of naming it
> "debugreformat." That "re" there is important: it tells a user not
> familiar with the "format" terminology that it changes something.

I would expect mentioning "upgrade" in the first line of the help (shown 
by `hg help debug`) to be enough. "reformat" reads a bit strange to me 
but that could be a good middle ground. (Also, I'm not a native speaker)

> Another thing I like about your proposal is that `hg debugformat` is
> read-only by default. While I typically don't like commands that are
> both read-only and perform modifications, I think "upgrade/format" is
> special enough that it really should require positive affirmation /
> consent before doing anything. So I think I'll change the behavior in V2
> to print possible upgrades by default and only take action if a flag is
> specified. I'll have to think a bit more about this...

I think the ability to access what is the current format of various 
repositories will be really useful. This will allow inventory of 
existing repositories to better plan the upgrades.

Looking forward for your V2!

Cheers,

-- 
Pierre-Yves David