This page is primarily intended for developers of Mercurial.

Improved Exchange report plan

Status: Project

Main proponents: Pierre-YvesDavid, PulkitGoyal, SushilKanchi

A way to keep track of what is happening during push/pull.

1. Goal

A way to help users keeping track of what happened after push/pull (and maybe any operation). Especially for changesets owned by the users

2. Details

2.1. The Problem

The current pull output is fairly basic and not logged. So it is easy to miss important information during a pull. In addition one cannot track back what happened after the fact. To make things worse hg incoming has never been ported to include the new informations about phases and obsolescence.

2.2. Logging report

The idea is to Keep track of the Nth last transaction (with a focus on push/pull). The data would be accessible through something like hg journal or equivalent.

Having instruction on how to "undo" some of the operation could help the users. The Journal seems like a good place to do so.

2.3. Improved report

Currently a pull will output the following information:

These data are useful to get an overall sense of what happened, but not to actually understand the details.

We need the option of something better with:

Having all this information all the time would be a lot of data. So having it available through the journal seems like a better option.

Changing the default hg pull/push output should not be out of the question, we could have configuration for control the default verbosity level by category.

In addition, we could leverage the Ownership idea to display more information about the changeset relevant to the users.

2.4. Confirmation prompt

Another interesting application of this would be to add a --confirm to hg pull/push. The command would display some details about the transaction and let the user reject it. To work well, the user will need a way to "zoom in" to get more details about the area he is interested in.

We could have configuration to automatically ask for confirmation when changeset relevant to the user are affected.

Another option, is to inhibit the "hidding" of the owned obsolete changeset until the user validate them. This could be cumbersome for the user, so I would rather have a good journal and an easy way to bring things back.

2.5. Roadmap

3. See Also

CategoryDeveloper CategoryNewFeatures CategoryEvolution

CEDExchangeReportPlan (last edited 2019-11-12 11:38:57 by Pierre-YvesDavid)