Fossil

# @make-template template ?outfile?
#
# Reads the input file <srcdir>/$template and writes the output file $outfile.
# If $outfile is blank/omitted, $template should end with ".in" which
# is removed to create the output file name.
#
# Each pattern of the form @define@ is replaced the the corresponding
# define, if it exists, or left unchanged if not.
# 
# The special value @srcdir@ is subsituted with the relative
# path to the source directory from the directory where the output
# file is created. Use @top_srcdir@ for the absolute path.
#
# Conditional sections may be specified as follows:

/*
** WEBPAGE: tktsetup_rpttplt
*/
void tktsetup_rpttplt_page(void){
  static const char zDesc[] =
  @ Enter the default ticket report format template.  This is the
  @ the template report format that initially appears when creating a
  @ new ticket summary report.
  ;
  tktsetup_generic(
    "Default Report Template",
    "ticket-report-template",
    zDefaultReport,
    zDesc,

<li> Mac x86_64
<li> Windows (mingw)
<li> Windows (vc++)
<li> OpenBSD
</ol>

<li><p>
Run at least one occurrence of the the following commands on every
platform:
<ol type="a">
<li> <b>fossil rebuild</b>
<li> <b>fossil sync</b>
<li> <b>fossil test-integrity</b>
</ol>

project has no ancestors and thus has no P-card.

A manifest has zero or more Q-cards.  A Q-card is similar to a P-card
in that it defines a predecessor to the current check-in.  But
whereas a P-card defines the immediate ancestor or a merge
ancestor, the Q-card is used to identify a single check-in or a small
range of check-ins which were cherry-picked for inclusion in or
exclusion from the the current manifest.  The first argument of
the Q-card is the artifact ID of another manifest (the "target")
which has had its changes included or excluded in the current manifest.  
The target is preceeded by "+" or "-" to show inclusion or
exclusion, respectively.  The optional second argument to the
Q-card is another manifest artifact ID which is the "baseline"
for the cherry-pick.  If omitted, the baseline is the primary
parent of the target.  The

to have their changes be merged into "official" branches by integrators.
For example, the Linux kernel team has a hierarchy of integrators with
Linus Torvalds at the root.  Individual developers each have their own
private branches of the source tree into which they make their own changes.
They then encourage first-tier integrators to pull those changes.  The
first-tier integrators merge together changes from multiple contributors
then try to get second-tier integrators to pull their branches.  The
changes merge up the the hierarchy until (hopefully) they are pulled into 
"Linus's branch", at which time they become part of the "official" Linux.

In Git, each branch is "owned" by the person who creates it and works
on it.  The owner might pull changes from others, but the owner is always
in control of the branch.  Branches are developer-centric.

Fossil, on the other hand, encourages a workflow where branches are