5055
Comment: explaining "bumped"
|
14457
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
Describe CEDVocabulary here. | |
Line 5: | Line 4: |
/!\ This page is intended for developer This pages gather data from discussion about the named use within the ChangesetEvolution concept. |
/!\ This page is intended for developers This page gathers data from discussion about the name use within the ChangesetEvolution concept. |
Line 11: | Line 10: |
= 2017 March 15 Meeting = == Conclusions == === Introduction to Instability === Rewriting changesets may introduce '''instability'''. There are two main kinds of '''unstable''' changesets: '''orphaned''' and '''divergent'''. '''Orphans''' are changesets left behind when their ancestors are rewritten. '''Divergence''' has two variants: * '''Content-divergence''' occurs when independent rewrites of the same changesets lead to different results. * '''Phase-divergence''' occurs when the old (obsolete) version of a changeset becomes public. ==== Renames ==== * Troubles => Instability * Troubled => Unstable * Precursor => Predecessor * Unstable => Orphan * Divergent => Content-divergent * Bumped => Phase-Divergent * evolve => stabilize * Evolution => Stabilization == Notes == Overview: * We have already agreed on the developer-facing things: * Obsolete is a good term for developers * Precursor is being renamed predecessor * Successor will remain successor * There is some agreement about changing the name "troubles" to "instability" and having having the main command be "stabilize" rather than "evolve" * We are trying to come up with names for the user-facing. They are currently called: * Troubles * Unstable * Divergent * Bumped More discussion: * One idea: UI sentences can include "simpler" phases such as "left behind". For example: "3 changesets were left behind and are now orphans". Naming ideas: * Unstable: * Orphan * Obsbased * Dangling * Left Behind * Divergent: * Competing * Alternates * Bumped: * Divergent Important points: * ability to Google the terms Sentences describing things: * Rewriting changesets you shared with other repository might introduce instability. Two terms: * There are two main kinds of instability: orphaning and diverging. * There are two main kinds of instability: orphaning and diverging (content and phase). * There are two main kinds of unstable changesets: orphaned and diverged. * There are two main kinds of unstable changesets: orphaned and diverged (content and phase). Three terms: * There are three kinds of instability: orphaning, content-variance, and phase-divergence. Unstable: * "Orphans" are changesets left behind when their ancestors are rewritten Divergence: * "Content-diverged" changesets occur when independent rewrites of the same changesets lead to different results. * "Changes-diverged" changesets occur when independent rewrites of the same changesets lead to different results. * "Content-variants" are changesets created by independent rewrites of the same changeset(s). Bumped: * "Phase-diverged" changesets occur when their old (obsolete) versions are made public. * "Divergent" changesets occur when their old (obsolete) versions are made public. * "Phase-variants" are changesets that occur when their old (obsolete) versions are made public. = Older Discussions = |
|
Line 15: | Line 102: |
'''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, |
Evolving history can introduce problems that need to be solved: * They are intrinsic side effects of the free exchange and rewrite of draft changesets, * They are an unhealthy state the user needs to take care of before moving forward, |
Line 23: | Line 108: |
* They are different kind of them. || Changeset adjective || Concept name || pro || con || status || || troubled || Troubles || || || in use || || conflicted || conflicts? || || || || || invalid || ? || || || || || unevolved || unevolution? || || || || || dirty || dirtiness? || || || || |
* There are different kinds of them. || Changeset adjective || Concept name || pro || con || status || || troubled || Troubles || self-explanatory, not so weird || uncommon || in use, maybe? || || conflicted || conflicts? || || confusion with merge conflict, doesn't work for unstable || || || invalid || ? || || disabled people, doesn't suggest resolution || || || unevolved || unevolution? || || || maybe? || || dirty || dirtiness? || || terrible || || || unhealthy || unhealthiness || || confusion with code, suggests contamination || || || unstable || instability || || || other use || || unsteady || || || || maybe? || || unsettled || ? || || || maybe for divergence || || stalled || ? || || confusion with work || || || stagnated || stagnation || || || || || problematic || || || || || || volatile || || cool word || || maybe? || || tainted || taint || || || || |
Line 37: | Line 131: |
Instability happens when a changesets with descendant is rewritten. The non-obsolete descendant of the now obsolete changeset are said "unstable changesets". | Instability happens when a changeset with descendants is rewritten. The non-obsolete descendants of the now obsolete changeset are called "unstable changesets". |
Line 44: | Line 138: |
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.) | Automatic resolution of instability by ''rebasing'' the unstable changesets on the latest known successors of their obsolete parent. (A changeset that is unstable because its parent is unstable needs to wait for the unstable parent to be '''stabilized''' before we can solve it.) |
Line 47: | Line 141: |
|| unstable || instability || || || in use || || unsettled || ? || || || || || uprooted || ? || || || || |
|| unstable || instability || || too generic || in use || || unsettled || ? || || || no || || uprooted || ? || || bad timing || || || orphaned || orphan? || pretty good || || || || precarious || ? || || || || || dangling || ? || || || || || stale || ? || || || || |
Line 56: | Line 153: |
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). | A changeset is called "Bumped" when it is the successor of a public changeset. The public changeset cannot be obsoleted or hidden anymore so both the old and new versions exist. This usually happens when someone is reworking a changeset while someone else is publishing it at the same time elsewhere. The two actions are eventually gathered somewhere and evolve detects there is an issue. To some extend "bumping" can be seen as "divergence with your past" as opposed to "divergence with another rewriting that happened in parallel). |
Line 62: | Line 159: |
* 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). |
* trying to bring "a change" but they are too late to do so. The automated solution for this is to create a new changeset with the diff between the public changeset and the successors (The diff introduced by the amend). |
Line 67: | Line 164: |
|| latecomer || ? || || || old abandoned name || | || latecomer || ? || || mouthful || old abandoned name || |
Line 69: | Line 166: |
|| trumped || || || || || | |
Line 74: | Line 172: |
|| unlucky || ? || || || || || tardy || tardiness || || || || || rewritten || ? || || || || || covering || ? || || || || || shadowed || shadowing || || || || || replacer || ? || || || || || belated || ? || || || || || mutated || mutant || || || || || mislead || ? || || || || || naive || ? || || || || || unaware || ? || || || || || mindless || ? || || || || || disenchanting || ? || || || || || dangling replacement|| ? || || || || || undermined || ? || || || || || inhibited || ? || || || || || deferred || ? || || || || || obviated || ? || || || || || forestalled || ? || || || || |
|
Line 77: | Line 194: |
Divergence happens when two changesets claim to have superseded the same changeset. The canonical way to do this is to have two people in two different repos rewriting the same changeset. The divergence is detected when one pulls from the other. (There is currently no other easy way to get divergence locally). * Divergence denotes that two (or more) different and independent "edits" happened on the same changeset, * No version can be called "better/newer" than the other one, so both are "alive" at the same time, duplicating all the common changes, * There is at least one latest common precursor that both divergent changesets claim to rewrite. They are said to be ''divergent '''from''' ''that latest common precursor. * A divergent changeset is ''divergent '''with''' ''the other non-obsolete changeset. The automated way to solve this, is to merge the two divergent changesets using the precursor they are divergent from as a base. |
|
Line 78: | Line 204: |
|| unstable || instability || || || in use || || unsettled || ? || || || || || uprooted || ? || || || || |
|| divergent || divergence || || || in use || || Duplicated || duplication || || content are different || || || concurrent || ? || || || || || forked || fork? || || too overloaded || || || conflicting || conflict? || || || || || conflicting replacement || ? || || || || || contested || ? || || || || || disputed || ? || || || || || torn || ? || || || || || competing || ? || || || || || scattered || ? || || || || || unmerged || ? || || || || || alternative || ? || || || || || twinned || ? || || || || || spread || ? || || || || || dispersed || ? || || || || || deviated || ? || || || || || unjoined || ? || || || || |
Line 84: | Line 225: |
Obsolescence markers create an orthogonal graph between the changesets, that track what changeset gets rewritten into which other. For this we use ''obsolescence-marker''. A small data structure that contains various information including the fact that "Changesets [Y] are replacing changeset X". We are interested in names used to describe the `X ← Y` relation. In both directions and from the point of view of each side of it. |
|
Line 86: | Line 229: |
"successor" are the "new" part of that relation. | |
Line 88: | Line 232: |
|| Successor || supersede || || || in use || | || Successor || supersede || || long? obscure? || in use || |
Line 92: | Line 236: |
|| new || ? || || too generic || || || post-<image> || ? || || || || || obsoleting || ? || || || || |
|
Line 95: | Line 241: |
"precusor" are the "old" part of that relation. The precursors will become obsolete and hidden (except in multiple cases). |
|
Line 99: | Line 247: |
|| predecessor || precede || || || || | || predecessor || precede || proper complement to successor, has a different shape || || || |
Line 104: | Line 252: |
|| old || ? || || too generic || || || pre-<image> || ? || || || || || obsoleted || ? || || || || || replaced || ? || || || || == See Also == * [[https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-January/092473.html|mailing list discussion about evolution naming]] * [[CEDUserInterface#Terminology_Opinions]] * [[https://www.mercurial-scm.org/pipermail/mercurial-devel/2012-September/044600.html|mailing list discussion: [RFC] naming of obsolescence troubles (2012-September)]] * [[https://www.mercurial-scm.org/pipermail/mercurial-devel/2012-July/042755.html|mailing list discussion: Obsolete Terminology (2012-July)]] * [[https://www.mercurial-scm.org/pipermail/mercurial-devel/2012-August/043708.html|continued (2012-August)]] * etherpad with notes: https://public.etherpad-mozilla.org/p/evolve-naming_NO_SPAM |
Changeset Evolution - Vocabulary
This page is intended for developers
This page gathers data from discussion about the name use within the ChangesetEvolution concept.
2017 March 15 Meeting
Conclusions
Introduction to Instability
Rewriting changesets may introduce instability.
There are two main kinds of unstable changesets: orphaned and divergent.
Orphans are changesets left behind when their ancestors are rewritten.
Divergence has two variants:
Content-divergence occurs when independent rewrites of the same changesets lead to different results.
Phase-divergence occurs when the old (obsolete) version of a changeset becomes public.
Renames
Troubles => Instability
Troubled => Unstable
Precursor => Predecessor
Unstable => Orphan
Divergent => Content-divergent
Bumped => Phase-Divergent
evolve => stabilize
Evolution => Stabilization
Notes
Overview:
- We have already agreed on the developer-facing things:
- Obsolete is a good term for developers
- Precursor is being renamed predecessor
- Successor will remain successor
- There is some agreement about changing the name "troubles" to "instability" and having having the main command be "stabilize" rather than "evolve"
- We are trying to come up with names for the user-facing. They are currently called:
- Troubles
- Unstable
- Divergent
- Bumped
More discussion:
- One idea: UI sentences can include "simpler" phases such as "left behind". For example: "3 changesets were left behind and are now orphans".
Naming ideas:
- Unstable:
- Orphan
- Obsbased
- Dangling
- Left Behind
- Divergent:
- Competing
- Alternates
- Bumped:
- Divergent
Important points:
- ability to Google the terms
Sentences describing things:
- Rewriting changesets you shared with other repository might introduce instability.
Two terms:
- There are two main kinds of instability: orphaning and diverging.
- There are two main kinds of instability: orphaning and diverging (content and phase).
- There are two main kinds of unstable changesets: orphaned and diverged.
- There are two main kinds of unstable changesets: orphaned and diverged (content and phase).
Three terms:
- There are three kinds of instability: orphaning, content-variance, and phase-divergence.
Unstable:
- "Orphans" are changesets left behind when their ancestors are rewritten
Divergence:
- "Content-diverged" changesets occur when independent rewrites of the same changesets lead to different results.
- "Changes-diverged" changesets occur when independent rewrites of the same changesets lead to different results.
- "Content-variants" are changesets created by independent rewrites of the same changeset(s).
Bumped:
- "Phase-diverged" changesets occur when their old (obsolete) versions are made public.
- "Divergent" changesets occur when their old (obsolete) versions are made public.
- "Phase-variants" are changesets that occur when their old (obsolete) versions are made public.
Older Discussions
Troubles
"troubled" changeset and troubles
Evolving history can introduce problems that need to be solved:
- They are intrinsic side effects of the free exchange and rewrite of draft changesets,
- They are an 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,
- There are different kinds of them.
Changeset adjective |
Concept name |
pro |
con |
status |
troubled |
Troubles |
self-explanatory, not so weird |
uncommon |
in use, maybe? |
conflicted |
conflicts? |
|
confusion with merge conflict, doesn't work for unstable |
|
invalid |
? |
|
disabled people, doesn't suggest resolution |
|
unevolved |
unevolution? |
|
|
maybe? |
dirty |
dirtiness? |
|
terrible |
|
unhealthy |
unhealthiness |
|
confusion with code, suggests contamination |
|
unstable |
instability |
|
|
other use |
unsteady |
|
|
|
maybe? |
unsettled |
? |
|
|
maybe for divergence |
stalled |
? |
|
confusion with work |
|
stagnated |
stagnation |
|
|
|
problematic |
|
|
|
|
volatile |
|
cool word |
|
maybe? |
tainted |
taint |
|
|
|
"unstable" changeset and "instability"
Instability happens when a changeset with descendants is rewritten. The non-obsolete descendants of the now obsolete changeset are called "unstable changesets".
A Changeset is "unstable" because either:
- one of its parents is obsolete,
- one of its parents is unstable.
Automatic resolution of instability by rebasing the unstable changesets on the latest known successors of their obsolete parent. (A changeset that is unstable because its parent is unstable needs to wait for the unstable parent to be stabilized before we can solve it.)
Changeset adjective |
Concept name |
pro |
con |
status |
unstable |
instability |
|
too generic |
in use |
unsettled |
? |
|
|
no |
uprooted |
? |
|
bad timing |
|
orphaned |
orphan? |
pretty good |
|
|
precarious |
? |
|
|
|
dangling |
? |
|
|
|
stale |
? |
|
|
|
"Bumped" changeset and "bumping"
A changeset is called "Bumped" when it is the successor of a public changeset. The public changeset cannot be obsoleted or hidden anymore so both the old and new versions exist. This usually happens when someone is reworking a changeset while someone else is publishing it at the same time elsewhere. The two actions are eventually gathered somewhere and evolve detects there is an issue. To some extend "bumping" can be seen 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 they are too late to do so.
The automated solution for this is to create a new changeset with the diff between the public changeset and the successors (The diff introduced by the amend).
Changeset adjective |
Concept name |
pro |
con |
status |
latecomer |
? |
|
mouthful |
old abandoned name |
bumped |
bumping |
|
|
in use |
trumped |
|
|
|
|
invalidated |
invalidation? |
|
|
|
behind |
? |
|
|
|
superseded |
? |
|
|
|
lagging |
lagginess? |
|
|
|
obviated |
? |
|
|
|
unlucky |
? |
|
|
|
tardy |
tardiness |
|
|
|
rewritten |
? |
|
|
|
covering |
? |
|
|
|
shadowed |
shadowing |
|
|
|
replacer |
? |
|
|
|
belated |
? |
|
|
|
mutated |
mutant |
|
|
|
mislead |
? |
|
|
|
naive |
? |
|
|
|
unaware |
? |
|
|
|
mindless |
? |
|
|
|
disenchanting |
? |
|
|
|
dangling replacement |
? |
|
|
|
undermined |
? |
|
|
|
inhibited |
? |
|
|
|
deferred |
? |
|
|
|
obviated |
? |
|
|
|
forestalled |
? |
|
|
|
"divergent" changeset and "divergence"
Divergence happens when two changesets claim to have superseded the same changeset. The canonical way to do this is to have two people in two different repos rewriting the same changeset. The divergence is detected when one pulls from the other. (There is currently no other easy way to get divergence locally).
* Divergence denotes that two (or more) different and independent "edits" happened on the same changeset, * No version can be called "better/newer" than the other one, so both are "alive" at the same time, duplicating all the common changes, * There is at least one latest common precursor that both divergent changesets claim to rewrite. They are said to be divergent from that latest common precursor. * A divergent changeset is divergent with the other non-obsolete changeset.
The automated way to solve this, is to merge the two divergent changesets using the precursor they are divergent from as a base.
Changeset adjective |
Concept name |
pro |
con |
status |
divergent |
divergence |
|
|
in use |
Duplicated |
duplication |
|
content are different |
|
concurrent |
? |
|
|
|
forked |
fork? |
|
too overloaded |
|
conflicting |
conflict? |
|
|
|
conflicting replacement |
? |
|
|
|
contested |
? |
|
|
|
disputed |
? |
|
|
|
torn |
? |
|
|
|
competing |
? |
|
|
|
scattered |
? |
|
|
|
unmerged |
? |
|
|
|
alternative |
? |
|
|
|
twinned |
? |
|
|
|
spread |
? |
|
|
|
dispersed |
? |
|
|
|
deviated |
? |
|
|
|
unjoined |
? |
|
|
|
Obsolescence graph
Obsolescence markers create an orthogonal graph between the changesets, that track what changeset gets rewritten into which other. For this we use obsolescence-marker. A small data structure that contains various information including the fact that "Changesets [Y] are replacing changeset X". We are interested in names used to describe the X ← Y relation. In both directions and from the point of view of each side of it.
"Successor"
"successor" are the "new" part of that relation.
Noun |
verb |
pro |
con |
status |
Successor |
supersede |
|
long? obscure? |
in use |
Successor |
suceed |
|
|
in use |
replacement |
replace |
|
|
|
next |
? |
|
|
|
new |
? |
|
too generic |
|
post-<image> |
? |
|
|
|
obsoleting |
? |
|
|
|
"Precursor"
"precusor" are the "old" part of that relation. The precursors will become obsolete and hidden (except in multiple cases).
Noun |
verb |
pro |
con |
status |
precursor |
precede? |
|
|
in use |
original |
? |
|
|
|
predecessor |
precede |
proper complement to successor, has a different shape |
|
|
progenitor |
? |
|
|
|
previous |
? |
|
|
|
prior |
? |
|
|
|
antecedent |
? |
|
|
|
old |
? |
|
too generic |
|
pre-<image> |
? |
|
|
|
obsoleted |
? |
|
|
|
replaced |
? |
|
|
|
See Also
mailing list discussion: [RFC] naming of obsolescence troubles (2012-September)
etherpad with notes: https://public.etherpad-mozilla.org/p/evolve-naming_NO_SPAM