strategy.tex

   1 Here we describe the update algorithm.  This is responsible for
   2 refreshing patches against updated versions of their dependencies,
   3 for merging different versions of the various braches created by
   4 distributed development, and for implementing decisions to add and
   5 remove dependencies from patches.
   6
   7 Broadly speaking the update proceeds as follows: during the Ranking
   8 phase we construct the intended graph of dependencies between patches
   9 (and incidentally select a merge order for the base branch of each
  10 patch).  Then during the Traversal phase we walk that graph from the
  11 bottom up, constructing for each patch by a series of merges and other
  12 operations first a new base branch head commit and then a new tip
  13 branch head commit.  These new head commits are maximums - that is,
  14 each has as ancestors all of its branches' sources and indeed all
  15 relevant commits in that branch.
  16
  17 We have two possible strategies for constructing new base branch
  18 heads: we can either Merge (works incrementally even if there the
  19 patch has multiple dependencies, but may sometimes not be possible) or
  20 we can Regenerate (trivial if there is a single dependency, and is
  21 always possible, but may involve the user re-resolving conflicts if
  22 there are multiple dependencies).
  23
  24 \section{Notation}
  25
  26 \begin{basedescript}{
  27 \desclabelwidth{5em}
  28 \desclabelstyle{\nextlinelabel}
  29 }
  30 \item[ $\depsreqof{K}$ ]
  31 The set of direct dependencies (in the form $\py$)
  32 requested in the commit $K$ ($K \in \pn$) for the patch $\p$.
  33
  34 \item[ $\pc \hasdirdep \p$ ]
  35 The patch $\pc$ has as a direct dependency the
  36 patch $\p$.  This is an acyclic relation.
  37
  38 \item[ $\p \hasdep \pq$ ]
  39 The patch $\p$ has as direct or indirect dependency the
  40 patch $\pq$.
  41 Acyclic; the completion of $\hasdirdep$ into a
  42 partial order.
  43
  44 \item[ $\pendsof{\set J}{\p}$ ]
  45 Convenience notation for
  46 the $\le$-maximal elements of $\bigcup_{J \in \set J} \pendsof{J}{\p}$
  47 (where $\set J$ is some set of commits).
  48
  49 \item[ $\pendsof{\set X}{\p} \le T$ ]
  50 Convenience notation for
  51 $\bigforall_{E \in \pendsof{\set X}{\p}} E \le T$
  52
  53 \item[ $\allsrcs$ ]
  54 $\bigcup_{\p \in \allpatches} \set H^{\pn} \cup \set H^{\py}$.
  55 All the input commits to the update algorithm.  (See below.)
  56
  57 \item[ $\set H^{\pc^{_=/-}}$ ]
  58
  59 The existing head commit(s) $\set H$ of the branch $\pc^{+/-}$.
  60 These are the heads which will be merged and used in this update.
  61 This will include the current local and remote git refs, as desired.
  62 Obtained from the function $h$ (see below).
  63
  64 \item[ $W$ ]
  65
  66 During the Traversal phase, when we generate new commits, the working
  67 head of the branch we are working on.  Starts at $W_0$, updated as the
  68 algorithm progresses, and ultimately used to set $T$.
  69
  70 %\item[ $\set E_{\pc}$ ]
  71 %$ \bigcup_i \pendsof{S_{\pc,i}}{\pc} $.
  72 %All the ends of $\pc$ in the sources.
  73
  74 %\item[ $ \tipzc, \tipcc, \tipuc, \tipfc $ ]
  75 %The git ref for the Topbloke commit set $\pc$: respectively,
  76 %the original, current, updated, and final values.
  77
  78 \end{basedescript}
  79
  80 \stdsection{Inputs to the update algorithm}
  81
  82 \begin{basedescript}{
  83 \desclabelwidth{5em}
  84 \desclabelstyle{\nextlinelabel}
  85 }
  86 \item[ $\pc_0$ ]
  87 The topmost patch which we are trying to update.  This and
  88 all of its dependencies will be updated.
  89
  90 \item[ $h : \pc^{+/-} \mapsto \set H^{\pc^{+/-}}$ ]
  91 Function for getting the existing heads $\set H$ of the branch $\pc^{+/-}$.
  92
  93 \item[ $w : \pc^{+/-} \mapsto W_0^{\pc^{+/-}}$ ]
  94
  95 Function for getting the existing local head of the branch
  96 $\pc^{+/-}$.  I.e., the current value of the branch ref for $\pc^{+/-}$.
  97 $W_0^{\pc^{+/-}} \in \set H$.
  98
  99 \item[ $g : \pc, \Gamma \mapsto \Gamma'$ ]
 100 Function to allow explicit adjustment of the direct dependencies
 101 of $\pc$.  It is provided with a putative set of direct dependencies
 102 $\Gamma$ computed as an appropriate merge of the dependencies requested by the
 103 sources and should return the complete actual set $\Gamma'$ of direct
 104 dependencies to use.  This allows the specification of any desired
 105 (acyclic) relations $\hasdirdep$ and $\hasdep$.
 106
 107 \end{basedescript}
 108
 109 \stdsection{Important variables and values in the update algorithm}
 110
 111 \begin{basedescript}{
 112 \desclabelwidth{5em}
 113 \desclabelstyle{\nextlinelabel}
 114 }
 115 \item[ $\Gamma_{\pc}$ ]
 116 The desired direct dependencies of $\pc$, a set of patches.
 117
 118 \item[ $\allpatches$ ]
 119 The set of all the patches we are dealing with (constructed
 120 during the update algorithm).
 121
 122 \item[ $\tipcn, \tipcy$ ]
 123 The new tips of the git branches $\pcn$ and $\pcy$, containing
 124 all the appropriate commits (and the appropriate other patches),
 125 as generated by the Traversal phase of the update algorithm.
 126
 127 \item[ $\allreach$ ]
 128 The set of all reachable commits.
 129
 130 A reachable commit is one we might refer to explicitly in any of these
 131 algorithms, and any ancestor of such a commit.  We explicitly
 132 enumerate all of the input commits ($\allsrcs$), so the reachable
 133 commits are originally the input commits and their ancestors.
 134
 135 $\allreach$ varies over time as we generate more commits.  Each
 136 commit we generate will have only reachable commits as ancestors, so
 137 generating a new commit (only) adds that new commit to $\allreach$.
 138
 139 \item[ $\allreachof{\pn}$, $\allreachof{\py}$ ]
 140 The sets of reachable commits at the point where we have just generated
 141 $\tippn$ or $\tippy$, i.e. just after $\alg{Merge-Base}(\p)$ or
 142 $\alg{Recreate-Base}(\p)$, or $\alg{Merge-Tip}(\p)$, respectively.
 143
 144 \end{basedescript}