Re: New sync'd branch

[Stephen J. Turnbull]

David Reitter writes:

 > And I think you'd have to know [a bit about the revision DAG] for
 > Bzr or Hg, too.

Not really.  hg is designed to strongly encourage "virtually linear"
development, automatically managing the DAG for "small" divergences
and using the single command "merge" to manually manage "large"
divergences or those with conflicts.  By "automatically" I mean that
hg dislikes having multiple heads (anonymous branches) in a single
workspace, so most users use either the fetch extension or pull -u to
pull and merge in a single operation.  Thus even though most of the
time your local commit will end up being parallel to somebody else's
commit in the public repository, almost all the time you're in a state
where there's only a single head in your branch.  push works to
preserve that invariant for the public repository.  This keeps merges
to a minimum, and you rarely need to be aware of the DAG or even the
branch name.

The bzr command set is a big mess, intended to support a wide variety
of variant workflows with a small number of commands each.  Most of
the commands are the same across workflows, but often they have wildly
varying semantics depending on how your branch is configured.  In
particular, "commit" can mean "record a version in the local repo" (in
a "standalone" branch), "push a version to a remote repo without
recording locally" (in a "lightweight checkout") or "record *and*
push" (in a "heavyweight checkout" or "bound branch").  bzr is
somewhat more friendly to multiple heads than is hg, especially with
the loom extension, but the basic philosophy is the same: try to
maintain a single-headed DAG as much of the time as possible, and
merge only when tactically (the case of a conflict) or strategically
(integrating a feature) necessary.  You rarely need to be aware of the
DAG or the branch name in bzr too, but you do need to be aware of the
type of branch (standalone, lightweight checkout, bound branch).

In fact, for both hg and bzr, I'd say if you become aware of the DAG
you had better be a core VCS hacker.  Anybody else is in big trouble,
because it requires deep understanding of internals to safely
manipulate the DAG directly.

git can emulate all of these various workflows to some degree
(lightweight checkouts are currently impossible to fully emulate
because of restrictions on pushing from "shallow clones"), but you do
need to understand the DAG well to do so.  Also, in git branching is
the cheapest possible operation (a pointer copy) and branch switching
is relatively cheap, so branches tend to proliferate.  For that
reason, you need to be aware of branch names, and it's hard in git to
work with anonymous branches.