Re: dVCS vs. CVS

[Stephen J. Turnbull]

David Kastrup writes:

 > Yavor Doganov <address@hidden> writes:
 > 
 > > Lifting the barrier -
 > >
 > > dVCS (and the fact that there are many of them) are a nightmare for
 > > contributors who are not programmers, like translators and
 > > documentation writers.
 > 
 > Sorry, but that's nonsense.

Please, David, don't overstate your case.  It's not "nonsense".  This
is an issue that has surfaced on Debian's I18N list.  It is one
motivation for web-based translation systems like Rosetta Stone.  The
problem is that nontechnical contributors tend to contribute to a lot
of projects ("dozens" is not unusual) simultaneously.  Eg, the
difference in semantics between "hg pull" (does not update the
workspace) and "git pull" (does update the workspace) is somewhat
confusing and can be very annoying to some users.

That said, I don't consider this a reason for any project not to
change its VCS, especially not from CVS to a dVCS.  It's simple enough
to insulate the nontechnical contributors from the changeover, though
it may require some creativity and effort.

 > > Autoconf, Automake, m4, Gnulib and other projects switched to Git some
 > > time ago.  One would expect that there will be an avalanche of new
 > > contributors who were not volunteering only because they needed a
 > > modern VCS to go ahead.  False assumption -- pretty much the same
 > > people hack on these projects after the switch.

This makes me laugh.  The autotools are such a crock (a crucially
important crock, but a horrible crock nonetheless) that it's amazing
they haven't suffered a dambreak and aren't gushing forth developers,
cackling insanely.  Maybe it's git that saved them.  (^^;;

 > Sure.  The question is whether they are more effective in that manner.
 > 
 > Linus Torvalds averages something in the order of hundreds of daily
 > patch sets for reviewing, applying, handling in the Linux kernel.  He
 > would not be doing that using CVS.

No, but he did approximate it without any VCS at all.  And, AIUI, that
is where Richard is coming from.  Admittedly, without a dVCS, to do
what Richard does or what Linus used to do requires extreme talent as
well as discipline.  However, with discipline it is possible for any
developer to achieve fairly high productivity (explicit estimates in
this list have been running about 20-25% less than with the tool, very
small compared to the 10:1 differences commonly reported for
differentials across developers in both LOC and defect rate).

Now, I see no reason to believe that Emacs is lacking such
discipline.  The behavior of Richard, Eli, and Alan leads me to
believe, on the contrary, that there is a powerful discipline here.
If so, such a discipline is a more or less fixed investment, that
shows up in a reluctance to change workflow.  That reluctance is
well-justified!

But individual developer workflow does not *need* to change
immediately (viz. my last post), and in practice will change very
naturally, almost without friction, as even very conservative
developers start grabbing the new tools available to them.  Project
workflow probably *should* change somewhat, but the necessary changes
can and should be implemented and maintained by the dCVS advocates and
other volunteers.  Here's an example.

XEmacs, a project with a culture and developer mix similar to Emacs's,
recently (December 15) changed over from CVS to Mercurial for our
mainline.  Little has changed.  Semi-conservatives like myself (we
were using dVCSes privately but were reluctant to change the public
repo) have experienced an immediate modest productivity increase (in
terms of rate of pushing changesets, which is an appropriate measure
of productivity for "conservative" developers) for three reasons:

    - inordinate fear of pushing something broken has dramatically
      decreased, partly because the VCS is more robust, and partly
      because the initial push goes to a "bleeding edge" repo, and a
      gatekeeper moves it from there to the "testing" repo after a few
      days without blood (workflow discipline still matters, you see,
      but important parts of it can be systematically implemented by a
      few volunteers rather than imposed on all active developers)

    - having the local repos encourages more frequent (private)
      commits giving more flexibility in pushing; this helps to get
      small, obviously correct changes (like typo fixes and doc
      improvements) into the code base more quickly

    - better merging tools and efficient reversion tools make merging
      of conflicts and localization of bugs much more effective

The last two perhaps deserve some comment.  First, obviously learning
to push selectively, to use new merge tools, and to use new reversion
tools requires an investment.  However, this investment is repaid
*immediately*.  It is faster to learn to use git revert, then start
searching for the regression using that tool, than to just go "reverse
patching" and do the search that way.  (git bisect is even more
economical of developer time, if a scriptable recipe is available.)

Second, with focused changesets, a local repo, and a scriptable test
case, a bisection search over the sequence of revisions can be
automated.  In fact, git already has a "bisect" command, and I believe
there is a Mercurial extension to perform this task.  Inveterate
multitaskers will quickly learn to love this feature.

The productivity of the "kids" is harder to assess.  Their push rate
doubled, but so did the number of bugs manifesting in the bleeding
edge repo.  Of course the shallow bugs (build breakage, etc) also get
fixed quickly because they are easy to localize, but I worry (and
Emacs developers should account for when adjusting the project
workflow) that there are also deeper bugs being introduced more
quickly, and some are not getting caught.  Still the net effect is
apparently an increase in productivity.

This is a very important point.  Increasing the flow of contributions
(which dVCS will do, for *all* contributors, for the reasons outlined
above regarding "semi-conservatives") is not unambiguously good.  It
is not true that to "many eyes, all bugs are shallow".  What is true
is that (1) with many eyes, shallow bugs get caught very quickly, and
(2) that the more eyes there are, the more likely it is that some
member of the group has sufficiently penetrating vision to catch the
deeper-swimming bugs.

(No, I'm not trying to teach anybody's Grandma how to knit; probably
everybody knows this already.  But I hope to contribute a wording that
both the progressives and the conservatives in this debate can use as
a common ground.)