|
Size: 584
Comment:
|
Size: 1306
Comment: sum up base concept and mention related issue.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
/!\ This page is intended for developers. <!> This is a proposed feature, last minor updated April 2011. |
|
| Line 5: | Line 9: |
| /!\ This page is intended for developers. <!> This is a proposed feature, last updated Jan 2011. |
|
| Line 10: | Line 11: |
| == Ideas == | == 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 * Deny edition of non-liquid (frozen) changeset, * Simple and logical transition from liquid to frozen state (freezing). This transition should be transparent for the user. == Other concept == * Garbage collection of "abandoned" changeset, * Semantical Change tracking (as mq do with patches) and versionning (as versionned mq), * History edition extension compatibility, * Sharing volatile part of the history. == Ideas and discussion == |
Liquid-HG
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
This page is intended for developers. 
This is a proposed feature, last minor updated April 2011.
A system for safely allowing mutable history.
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
- Deny edition of non-liquid (frozen) changeset,
- Simple and logical transition from liquid to frozen state (freezing). This transition should be transparent for the user.
Other concept
- Garbage collection of "abandoned" changeset,
- Semantical Change tracking (as mq do with patches) and versionning (as versionned mq),
- History edition extension compatibility,
- Sharing volatile part of the history.