Liquid-HG

/!\ This page is intended for developers. <!> This is a proposed feature, last minor updated April 2011.

A system for safely allowing mutable history.

Contents

  1. Liquid-HG
    1. Base concept
    2. Other concepts
      1. Garbage collection of "abandoned" changeset
      2. Semantical Change tracking (as mq do with patches) and versionning (as versionned mq)
      3. History edition extension compatibility
      4. Sharing volatile part of the history
    3. Ideas and discussion

Base concept

The first objective of Liquid-HG is to have a clear distinctions between the part of the history can be altered and the one which can't. (To keep it simple: the private part may be edited while the public can't). This imply two points

Other concepts

Garbage collection of "abandoned" changeset

For now, all extensions that alter history destroy old changeset by rewriting part of revlog. Most of them save a backout of the stripped part of the revlog in a bundle located at ".hg/strip-backup/"

Semantical Change tracking (as mq do with patches) and versionning (as versionned mq)

mq currently allow to keep a single identifier (patch name) for the multiple changeset that qrefresh create.

Versionned mq allow to restore state of the liquid part you changeset and share it with other people.

History edition extension compatibility

mq (any other extension) keep information about changeset outside the revlog. The force other history editing extension to either: Implement mq compatibility itself, Be incompatible with mq handled changeset, corrupt mq repo.

Sharing volatile part of the history

Sharing the liquid part of the history for review, preview is a complicated issue but an interesting problem.

Ideas and discussion

CategoryNewFeatures