Differences between revisions 13 and 14
Revision 13 as of 2017-01-25 19:03:14
Size: 6843
Editor: PeterSuter
Comment: Restore divergence table
Revision 14 as of 2017-01-25 19:17:32
Size: 6873
Editor: PeterSuter
Comment: Typos
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:
Evolving history can introduce problems that need to be solved.: Evolving history can introduce problems that need to be solved:
Line 16: Line 16:
 * 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,
 * 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 20: Line 20:
 * They are different kind of them.  * There are different kinds of them.
Line 35: Line 35:
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 42: Line 42:
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 54: Line 54:
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 60: Line 60:
* trying to bring "a change" but is too late to do so, * trying to bring "a change" but they are too late to do so.
Line 62: Line 62:
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). 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 77: Line 77:
Divergence happens when two changesets claims to superseded to the same changesets. The canonical way to do this is to have two people in two different repo rewriting the same changeset. The divergence is detected when one pull from the other. (there is currently other eay way to get divergence locally). 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).
Line 79: Line 79:
* Divergence denote that two (or more) different and independent "edit" happened on the same changeset,
* No version can be said "better/newer" than the other one, so both are "alive" at the same time, duplicating all the common changes,
* There is at least on latest common precursors that both divergent changeset claims to rewrite, They are said to be ''divergent '''from''' ''that latest common precursors.
* 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.
Line 84: Line 84:
The automated way to solve this, is to merge the two divergent changeset using the precursors they are divergent from as a base. The automated way to solve this, is to merge the two divergent changesets using the precursor they are divergent from as a base.
Line 92: Line 92:
Obsolescence markers create an orthogonal graph between the changesets that tracks 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 direction and from the point of view of each side of it. 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.

Changeset Evolution - Vocabulary

/!\ This page is intended for developer

This pages gather data from discussion about the named use within the ChangesetEvolution concept.

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

in use

conflicted

conflicts?

invalid

?

unevolved

unevolution?

dirty

dirtiness?

unhealthy

unhealthiness

"unstable" changeset and "instability"

{i} Related documentation

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

in use

unsettled

?

uprooted

?

"Bumped" changeset and "bumping"

{i} related documentation

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

?

old abandoned name

bumped

bumping

in use

invalidated

invalidation?

behind

?

superseded

?

lagging

lagginess?

obviated

?

unlucky

?

tardy

tardiness

"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

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

in use

Successor

suceed

in use

replacement

replace

next

?

"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

progenitor

?

previous

?

prior

?

antecedent

?

== See also ==


CategoryDeveloper CategoryEvolution

CEDVocabulary (last edited 2017-08-04 09:26:27 by RyanMcElroy)