Pushing after merge considered harmful

[Eli Zaretskii]

> From: Óscar Fuentes <ofv at wanadoo.es>
> Cc: Eli Zaretskii <eliz at gnu.org>
> Date: Sun, 28 Feb 2010 21:44:05 +0100
> Posted-To: gmane.comp.version-control.bazaar-ng.general
> 
> > That's it!  Let me know if you like the results:
> 
> Well, I'll let you know my impressions even if I don't fully like the
> results :-)

Thanks for the feedback.

> > .. warning::
> >
> >     This is advanced documentation of the Bazaar version control system and
> >     its underlying conceptual model.  It is not intended as a first
> >     introduction to the system.  However, it can provide a deeper level of
> >     understanding of the structures that underlie it and thus it may be
> >     helpful once you are familiar with using Bazaar for version control.
> 
> This reminds me of John Wiegley's great "Git from bottom up"
> 
> http://www.newartisans.com/blog_files/git.from.bottom.up.php

This is not my text, it was copied verbatim from the original
document.  Please keep in mind that the deal was not that I will write
an entirely new document from scratch.  The deal was that I will
rewrite what Neil wrote so that the result does not mention graphs and
the DAG.

> > Bazaar is a `distributed version control system` (DVCS) and like all
> > such systems, it makes it very easy to fork development off the
> > `official` series of revisions, known as the `mainline`, and later
> > combine the forked-off revision with mainline.  We call the forked-off
> > revision a `branch` and the process of combining a branch with mainline
> > a `merge`.
> [...]
> I think it is fundamental to emphasize that for DVCS all branches are
> the same.

I think this is unimportant for this document, whose sole purpose is
to explain the history DAG and how it is affected by bzr commands.
This document is not a general description of Bazaar and its entire
philosophy, its scope is much narrower.

I will simply drop the references to mainline from this paragraph,
since it is introduced later anyway.

> > 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.

I should probably drop SVN, since I don't know enough about it.  As
for CVS, it does not support merges in its history records; again,
please keep in mind that this document is only about history
representation.  I will try to find a clearer wording, but it's not
easy, because I'd need to base that on the history representation
which was not introduced yet at this point in the document.

> >    [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.

I don't see the need.  Again, this is not supposed to be a
mathematically correct article, just a lightweight description of a
complex subject.  Some inaccuracy is unavoidable, and this one seems
particularly harmless.  Am I missing something?

> > 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.

Not true, AFAIK.  By keeping track of merges and parent revisions, a
DVCS can automatically do more than the other kind of VCS, and err
less.  For example, parts that are present in both merged versions
because they come from the common ancestor will never cause conflicts
in a DVCS, while they might in CVS.  The whole point of this
introduction is to explain why the non-liner history representation is
necessary.

> > 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.

How about a CVS user?

> > 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'.

I'm talking about the branch order later in the document.

> 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.

Don't you think I know it?  But this is not a paper for computer
scientists who are privy to graph algorithms, so I simplified a bit
the obscure parts to make the main ideas more easily understandable.
That was the whole point of this exercise: to explain complexity in
layman's words.  Suggesting ways to complicate the document is a
non-starter.

> 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.

I think these are not important for describing the history
representation (they were absent from the original document), but if
you think they _are_ important in this context, please tell why.