CVS "just works?" (was RE: Bazaar book from Packt)

Mark Grandi markgrandi at
Sat Sep 7 09:43:48 UTC 2013

I don't see how colocated branches help with maintaining a large and
active product, or were those two separate things

From: Stephen J. Turnbull
Sent: 9/7/2013 1:23 AM
To: JP Vossen
Cc: bazaar at
Subject: CVS "just works?" (was RE: Bazaar book from Packt)
JP Vossen writes:

 > I totally agree, which is why I find everyone else's love of git so
 > confusing.

Not everybody loves git.  The thing about git is that it opens up to
all users the possibilities of DAG manipulation that Bazaar offers
only to its core developers and a few enthusiasts.  That comes at a
cost of git's surface complexity and annoyance to people who want it
to "just work" (or better yet, "just go away" :-).  That is probably
the great majority of all programmers.

But you shouldn't be surprised that a large fraction of the open
source community loves git.  One good reason is that git *does* open
up its core functionality to the user: we like our tools sharp and we
hone them ourselves.  Sure, Bazaar is open source, but I have neither
the skills nor the equipment to forge a replacement blade starting
from iron ore.  With git, it's more at the level of whetstone and
sharpening oil, and maybe a bench vise.

Another reason is that git is the best tool available for handling the
kind of massive, distributed branching that occurs in a hyperactive
public project (and I'm not just talking about the Linux kernel).
Colocated branches really help.  Mercurial has colocated branches, but
the implementation sucks by design.  Bazaar's implementation isn't
supported, and its UI ain't "there" yet.

 > I do not want to have to know as much about the guts of the
 > tool as git requires in order to not shoot myself in the foot,

What need to know "guts"?[2]  You "just" need to be disciplined about
what commands and options you allow yourself to use.  But that's a big
defect when git sports a plethora of non-orthogonal commands and
options, and often you *do* need to use options, default behavior
isn't quite right.  That's very unattractive to "I want it to just
work" users.

 > and I *certainly* don't want to have to try to explain all of it to
 > other folks who don't understand or want to use a VCS in the first
 > place!

Actually, I find those folks to be among the easiest to introduce to
git.  Eg, my economics students.  They only know five commands: init,
add, commit, push, and log.  If push came to shove, *they* could get
along without log.[3] :-)  The hardest part of getting them going with
git is getting ssh installed and configured on Windows.  I wouldn't
care what dVCS they use in this application, but if it's git I can use
gitolite (a tool I use anyway) to manage communication.

 > [...]
 > > We still use CVS because it "just works", doesn't get in the way.
 > Unless you tag every single commit, or change only a single file at a
 > time, I have to disagree there.  CVS is fundamentally broken because of
 > the way it does everything "per file."

There are a lot of applications where CVS and RCS are fine.  Eg, my
students would do fine with either; they don't branch at all, and
often they only have one file under VCS.  The choice of a modern dVCS
is dictated by the "d": they can work offline and submit for review
with one simple command the next time they're online.

[1]  With the single exception of git-gc.

[2]  Not that the guts are difficult.  They are just a slight
generalization of singly-linked lists as used in the "guts" of Lisp.

[3]  And they don't use "diff" because they all use Word to edit their
documents. :-P

More information about the bazaar mailing list