No subject

it special is an agreement among the developers. `mainline' can be
different things depending on the context for the same project. If you
and me are talking about Emacs `mainline', most likely is `trunk' at
bzr.gnu.org. If you are talking with some collaborator of your bidi
sub-project, it *may* be `bidi' at bzr.gnu.org. And if I'm thinking
about integrating a feature I privately developed, `mainline' is my
personal Emacs fork.

I think it is fundamental to emphasize that for DVCS all branches are
the same.

> Traditional, centralized version control systems, such as CVS or SVN,
> do not have integral support for branching and merging.

This is confusing. Someone may think that cvs and svn does not support
branching and merging, which is not correct. Since some time ago, svn
even tracks merges.

> They consider the history of a package as a linear sequence of
> revisions:
>
>    [insert here an image of a linear history]
>
> In this model, a new revision can only be committed if it is based on
> the latest revision in the linear history recorded in the repository.

`repository' means very different things for bzr and svn/cvs. This
distinction should be made before using the word here.

> If the developer started from a revision that is not the latest by the
> time she wants to commit, she needs to manually synchronize her code
> with the latest revision in the repository, by applying all the
> changes made in between the revision from which she started and the
> current latest revision.  Only after that, she will be able to commit
> without destroying the work of others.  This manual labor is what
> makes distributed development hard with the traditional VCSs.

You have this same labor whenever you wish to integrate your changes on
some other branch (`mainline', for instance.) On this regard, DVCS just
allows to defer the task to some convenient occasion and to it in
batches.

> A DVCS makes all this much easier by tracking branching and merging
> between revisions in the repository.  This is central to the support
> of a distributed development model built into every DVCS, whereby a
> number of separate teams independently develop features of a package.

A svn user will see no obvious difference with what he has.

> To track branching and merging, a DVCS needs to be built around a
> proper representation of the relations between revisions in the
> repository.  In contrast with traditional VCSs, a DVCS can no longer
> represent the history as a line, it needs a non-linear representation
> that can express branching and merging of revisions.
>
> This non-linear representation of revision history can be illustrated
> as a set of revisions and interconnections between these revisions.
> The interconnections have a direction: they point from each revision
> to one or more of its parents.  A `parent` is the revision from which
> a `child` revision was produced.  If the child revision was produced
> by editing some of the files in the working tree, that child revision
> will have a single parent -- the revision which was edited.  If the
> child revision was produced by merging two divergent paths of
> development, it will have two parents, one each from each one of the
> two branches that were merged.
>
> .. image:: dag_basics.png
>     :scale: 50
>
> (Note: Those of you who have some background in computer science will
> recognize that this structure is a `directed acyclic graph` (DAG), in
> which revisions serve as `nodes` and interconnections are `edges`.
> Directed acyclic graphs provide a natural representation of historical
> relationships between revisions in a DVCS.)
>
> Note that, unlike the linear history in the traditional VCSs, the DVCS
> history no longer has a simply defined order: there's no `latest`
> revision anymore, strictly speaking.

Yes, there is. Each bzr branch has one and only one `tip'. It is
possible to define a total order (on the Mathematics sense) of revisions
on a bzr branch, thanks to the distinction among left and right lines of
the DAG you mention below.

The rest of the document looks okay.

Some basic concepts that you are omitting are: 

* The `D' in `DVCS' is all about exchanging revisions.

* For doing this on a sane manner, each revision must be uniquely
  identifiable.

* The parent(s) of a revision are components of its identity, so the
  unique ID of a revision implicitly defines all the history that
  precedes it.

[snip]