[Python-Dev] Looking for VCS usage scenarios

[Stephen J. Turnbull]

Brett Cannon writes:

 > I have yet to have met anyone who thinks git is great while having
 > used another DVCS as extensively (and I mean I have never found
 > someone who has used two DVCSs extensively).

When XEmacs was considering changing from CVS, I used Darcs as my
primary VCS for about 4 months, including a mammoth (>1MB patch)
merge.  Since Dec 2007, Mercurial has been the official XEmacs VCS.
Nowadays I'm more management than developer but I love git, and will
not use either Darcs or Mercurial for any project where git is an
option.  (Somebody else did the work of moving the CVS history, so
they got to choose Mercurial -- in hindsight, it would have been worth
doing the work....)  I don't know if that counts as "extensive".

I like git because
(1) I like the model of exposing the commit DAG directly as a graph of
    objects.
(2) It's very fast.
(3) It does not promote a particular style of development.  Both
    merging parallel branch tips and rebasing to serialize branches on
    the trunk are well-supported.  (Mercurial and especially Bazaar do
    support the merging style better than git does.)
(4) Branching is cheap and fast.  I typically have a subbranch for
    almost every typo/minor fix I do in a working branch, which I then
    cherrypick into the mainline.  (This workflow avoids merge
    conflicts due to cherrypicking typo fixes directly from the
    subbranch.  Mercurial makes such cherrypicking relatively
    inconvenient, and I often make mistakes and commit too much in the
    wrong branch.  In Darcs this can be very painful because of
    dependencies the cherrypick drags in.)  Switching branches is a
    sub-second operation until the diff gets to be about 15-20 files.
(5) All branches are explicit.  You commit to the current branch.
(6) Files to commit must be named in the commit command, marked with
    an add command, or included via the --all option.
(7) A fairly natural, if ugly, syntax for specifying revisions,
    ranges, and various operations on ranges in log and diff
    commands.  No "revision numbers" that vary randomly according to
    workspace.

I dislike Darcs because
(1) The DAG is implicit.
(2) It's slow.
(3) I never know what I'll get when I ask to pull a single patch;
    Darcs's criteria for dependency are opaque, at least to me.
(4) It's hard to script and really likes to be used interactively.

I dislike Mercurial because
(1) It strongly encourages a commit-then-merge style which results in
    a large number of "merge turds" in the history.  Since most
    "merges" succeed because the changes are in different files, these
    are very annoying to me.
(2) The default revision numbering typically results in rather bizarre
    diffs near merges, but there is no easy way to specify a
    particular parent (except the first) without looking up the log.
(3) Commits everything in the workspace by default.
(4) Commit is silent by default, so you don't realize how much you
    have committed until you push ... and have succeeded so you can no
    longer roll it back safely.
(5) Creates new branches without being asked, which then need to be
    merged, thus strongly encouraging the commit-then-merge style.
(6) I don't trust its compute-ancestors-separately-per-file merge
    algorithm.  If this really works, there's nothing wrong in
    principle with CVS!
(7) A lot of features require plugins, and the result is command
    proliferation, though unlike git only "porcelain" is exposed.

I haven't used Bazaar beyond "bzr pull" of Mailman once a week or so,
so I don't dislike it.  Things I have observed or have seen discussed
on the bazaar mailing list that you might want to consider:
(1) The UI is as baroque as git's, once you consider all the plugins
    and GUIs that are available.  Lots of different workspace styles
    (ordinary branching, stacked branching, looms -- similar to
    quilts?, lightweight checkouts, ...) are supported with a
    corresponding increase in subcommand count and/or options.
(2) New repo formats are added frequently, and taking advantage of new
    features often requires upgrading your repo format.  So-called
    lightweight checkouts can be especially annoying as they involve
    leaving the history on the server, making distributed work
    problematic.
(3) Bazaar is very good at supporting the kind of refactoring that
    involves lots of file/directory renames and/or splitting/combining.
(4) Bazaar is claimed to have especially good merging support.
(5) Bazaar has an idiosyncratic log format that displays branches and
    merges "nicely" by choosing a principal branch, and indenting
    subsidiary branches.  This view changes depending on the repo,
    AIUI.  Some people prefer to leave that to a separate command
    (a graphical DAG viewer or something like "git-show-branches").
(6) In some common use patterns (eg, "bzr log | less"), Bazaar
    currently does not scale.

 > >.  It is guaranteed to scale (unless Python gets to be
 > > significantly bigger and more active than Linux, at any rate) and it has
 > > a large, very technically capable, and supported user community already.
 > 
 > I think any of the DVCSs will scale. But I will be taking some
 > performance numbers so scalability will be taken into consideration.

On the contrary.  Bazaar is currently known *not* to scale, and the
bazaar developers have a number of hypotheses about why, and are
working hard on fixing the acknowledged problem.  Emacs made the
decision to use bzr "because it's a fellow GNU project" early this
year, but they're still using CVS because of ongoing pushback against
the performance problems of bzr.  Let's put it this way: on my iBook
G4, for the same Emacs repository (ie, containing the same subset of
versions), "gitk" puts up the whole DAG in living color in about 10
seconds, while "bzr log" takes almost 5 minutes to return the *first*
revision.  There are workarounds, of course, but the default form of
that command (and several others) is very slow in that repo.

My understanding is that to deal fully with these problems, the Bazaar
developers plan to change the repo file format.  Some progress has
been made, (small) quantitative improvements have been made, but AFAIK
bzr still has bad worst-case performance for some common operations on
moderately large repos (way smaller than the Linux kernel).

 > Well, we will see, but as of right now my use of git has left a nasty
 > taste in my mouth that will take a lot of proverbial mouthwash to get
 > rid of and allow it to be considered in this PEP.

It's your PEP, but if you don't take git seriously, I expect a lot of
people will refuse to take your PEP seriously.

N.B.  It is *not* obvious that you or the PSF should cater to those
people.  It is relatively simple, though of course somewhat annoying
and inconvenient, to set up a local bidirectional gateway between the
"official" dVCS and one's preferred one.  I think you probably do want
a compromise that everybody will use, but you should keep the "keep
your own repo in any format you want" alternative in mind as a way to
gauge how much claimed pain you should acknowledge.<wink>