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:

• number of changeset pulled,
• number of file affected,
• head changes,
• number of local draft getting published,
• number of new obsolescence markers,
• number of changeset obsoleted,
• number of new unstable changeset (of each types)
• the range of new changeset

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:

• more details about the new changesets,
• more details about the new heads (and merged/head),
• more details about named branches changes,
• more details about obsoleted changesets, and their successors/prune,
• more details about the instability introduced and resolved.

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

• adding basic phases information to hg pull output

• adding ranges of pulled changeset to output

• adding obsolescence related information to outpu

• start logging data about transaction

• display basic information about logged transaction

• Give access to details in each possible area

  • changesets,

  • branches,

  • phases,

  • obsolescence,

  • prune,

  • unstability changes

• introduce a --confirm option

  • push

  • pull

• fix inc/out

  • hg incoming

  • hg outgoing

• introduce the Ownership specific bits:
  • extra details in report,
  • confirm when affected

3. See Also

• Ownership plan

• ChangesetEvolutionDevel

• ChangesetEvolution

CategoryDeveloper CategoryNewFeatures CategoryEvolution