2892
Comment:
|
5055
explaining "bumped"
|
Deletions are marked like this. | Additions are marked like this. |
Line 15: | Line 15: |
'''Definition and property''': Evolving history can introduce problems that need to be solved.: * They are intrinsic side effect of the free exchange and rewrite of draft changeset, * They are and unhealthy state the user needs to take care of before moving forward, (Even if they can stay around unsolved for a while), * They are not critical, we know how to detect and solve them, * They are different kind of them. |
|
Line 26: | Line 35: |
{i} [[https://www.mercurial-scm.org/doc/evolution/user-guide.html#id19|Related documentation]] Instability happens when a changesets with descendant is rewritten. The non-obsolete descendant of the now obsolete changeset are said "unstable changesets". A Changeset is "unstable" because either: * one of its parents is obsolete, * one of its parents is unstable. Automatic resolution of instability if node by ''rebasing'' the unstable changesets on the latest known successors of its obsolete parent. (Changeset unstable because the parent is unstable needs to wait for their unstable parent to be '''stabilized''' before we can solve them.) |
|
Line 27: | Line 47: |
|| unstable || instability || || || in use || || unsettled || ? || || || || || uprooted || ? || || || || === "Bumped" changeset and "bumping" === {i} [[https://www.mercurial-scm.org/doc/evolution/sharing.html#id18|related documentation]] A changeset is says "Bumped" when it is the successors of a public changeset. The public changeset cannot be obsoleted or hidden anymore so both the old and new version exists. This usually happens when someone is reworking a changeset while somewhere else is publishing it at the same time elsewhere. The two actions are eventually gathered somewhere and evolve detect there is an issue. To some extend "bumping" can be seens as "divergence with your past" as opposed to "divergence with another rewriting that happened in parallel). So in summary bumped changesets are: * superseding something public, * trying to obsolete something that cannot be obsolete, * trying to bring "a change" but is too late to do so, The automated solution for this is to create a new changeset with the diff between the public and the successors (The diff introduced by the amend). || Changeset adjective || Concept name || pro || con || status || || latecomer || ? || || || old abandoned name || |
|
Line 33: | Line 74: |
=== "Bumped" changeset and "bumping" === || Changeset adjective | Concept name || pro | con | status || || unstable | instability || | | in use || || unsettled | ? || | | || || uprooted | ? || | | || |
Describe CEDVocabulary here.
Changeset Evolution - Vocabulary
This page is intended for developer
This pages gather data from discussion about the named use within the ChangesetEvolution concept.
Contents
Troubles
"troubled" changeset and troubles
Definition and property:
Evolving history can introduce problems that need to be solved.:
- They are intrinsic side effect of the free exchange and rewrite of draft changeset,
- They are and unhealthy state the user needs to take care of before moving forward,
- (Even if they can stay around unsolved for a while),
- They are not critical, we know how to detect and solve them,
- They are different kind of them.
Changeset adjective |
Concept name |
pro |
con |
status |
troubled |
Troubles |
|
|
in use |
conflicted |
conflicts? |
|
|
|
invalid |
? |
|
|
|
unevolved |
unevolution? |
|
|
|
dirty |
dirtiness? |
|
|
|
"unstable" changeset and "instability"
Instability happens when a changesets with descendant is rewritten. The non-obsolete descendant of the now obsolete changeset are said "unstable changesets".
A Changeset is "unstable" because either:
- one of its parents is obsolete,
- one of its parents is unstable.
Automatic resolution of instability if node by rebasing the unstable changesets on the latest known successors of its obsolete parent. (Changeset unstable because the parent is unstable needs to wait for their unstable parent to be stabilized before we can solve them.)
Changeset adjective |
Concept name |
pro |
con |
status |
unstable |
instability |
|
|
in use |
unsettled |
? |
|
|
|
uprooted |
? |
|
|
|
"Bumped" changeset and "bumping"
A changeset is says "Bumped" when it is the successors of a public changeset. The public changeset cannot be obsoleted or hidden anymore so both the old and new version exists. This usually happens when someone is reworking a changeset while somewhere else is publishing it at the same time elsewhere. The two actions are eventually gathered somewhere and evolve detect there is an issue. To some extend "bumping" can be seens as "divergence with your past" as opposed to "divergence with another rewriting that happened in parallel).
So in summary bumped changesets are:
* superseding something public, * trying to obsolete something that cannot be obsolete, * trying to bring "a change" but is too late to do so,
The automated solution for this is to create a new changeset with the diff between the public and the successors (The diff introduced by the amend).
Changeset adjective |
Concept name |
pro |
con |
status |
latecomer |
? |
|
|
old abandoned name |
bumped |
bumping |
|
|
in use |
invalidated |
invalidation? |
|
|
|
behind |
? |
|
|
|
superseded |
? |
|
|
|
lagging |
lagginess? |
|
|
|
obviated |
? |
|
|
|
"divergent" changeset and "divergence"
Changeset adjective |
Concept name |
pro |
con |
status |
unstable |
instability |
|
|
in use |
unsettled |
? |
|
|
|
uprooted |
? |
|
|
|
Obsolescence graph
"Successor"
Noun |
verb |
pro |
con |
status |
Successor |
supersede |
|
|
in use |
Successor |
suceed |
|
|
in use |
replacement |
replace |
|
|
|
next |
? |
|
|
|
"Precursor"
Noun |
verb |
pro |
con |
status |
precursor |
precede? |
|
|
in use |
original |
? |
|
|
|
predecessor |
precede |
|
|
|
progenitor |
? |
|
|
|
previous |
? |
|
|
|
prior |
? |
|
|
|
antecedent |
? |
|
|
|