Re: Notes from the version control BOF at the summit

[Tom Lord <lord at emf dot net>]

    > From: Florian Weimer <fw@deneb.enyo.de>

    > * Colin Walters:

    > > First of all, Florian Weimer says:

    > >> On the other hand, tla developers tend to completely dismiss the 
    > >> centralized model.

    > > This is not true, I am not sure why Florian says this.

    > It's an impression I got by reading the mailing list.  You have to
    > look away very hard if you want to avoid it. 8-)

I think that your impression results from the fact that a non-central
model is almost always preferable.

CVS makes easy a centralized model and makes _barely_ possible a
decentralized model.  Arch makes both about equally easy (archive
boundaries are largely transparent in arch).  CVS users are therefore
accustomed to centralized.  The current first generation of Arch
users, having an unbiased choice, have collectively decided that
decentralized is usually the best thing.


    >> I do centralized development with arch (tla) all the time.  It is in
    >> fact much better than CVS or Subversion for this, because it handles
    >> renames and has true changesets[1].

    > I used to use arch for centralized development, too, but there wasn't
    > more than one committer for those repositories anyway.

With one committer that's neither "centralized" or "decentralized" --
that's "indeterminate".


    > I'd love to look at a project which uses tla, hasn't got a designated
    > patch integrator, and has a significant changeset creation rate.
    > There are quite a few interesting questions: How do they trim logs (to
    > cut down the inode waste)?  Is the lack of versioned branch creation
    > (or the complete lack of branch removal) a problem?  Is "tla
    > push-mirror" fast enough for mirroring new changes from the central
    > repository?  And so on.

I don't understand what you mean by "versioned branch creation".
Do you think it's important enough to elaborate on?

Regarding "push-mirror" --- at the cost of a tiny amount of work, plus
the cost that the admin of the mirrored arch agrees to run an rsync
server -- you can avoid "push-mirror" entirely and mirror just using
rsync.   It'll be much faster.


    > > Now, I am the author of arch-pqm (http://web.verbum.org/arch-pqm), which
    > > Walter Landry referenced in his email.

    > arch-pqm seems to require that each GCC developer sets up and
    > maintains his or her own repository.

Eewww, scary.   It's not just pqm that's that way.   Arch itself makes
a similar encouragement.  

Try it.  You'll like it.   The first one's free. 

    > I'm not sure how many developers actually have to set up branches and
    > merge between them.  

Hehe.  Do you mean in arch world or GCC?

In arch world, that's pretty much _all_ that we do.  Oh sure, there
are rumours about little closed shops that use arch but do
single-branch development, but _every_single_ patch submission to arch
itself (and, I infer, several other arch-using projects) has been
either a naked diff(1) output or, yes, an arch branch to be merged.
It's just very easy to work that way -- we aren't (only) motivated to
be working this way out of principle.

    > I've got the impression that a lot of committers
    > (if they commit anything at all, unlike me) don't really need those
    > fancy features for their daily work.

The GCC project already makes very heavy use of branching and merging.
The core project community is so expert at this, by this time, that I
sometimes point to the GCC project as an example of how CVS can pretty
much do most (not all) of what you'd want --- just awkwardly, without
effective distributed development support, slowly, and with some
flakiness. 


    > >> I mean "experimental" as in "simply aborts for some common usage
    > >> errors, without supplying a proper diagnostic, and leaving behind
    > >> something in horribly inconsistent state".  Things have already
    > >> improved for common codepaths, though.

    > > The error messages, along with the tutorial, are definitely the worst
    > > things about tla.  However, the error messages are quite fixable.  

    > On common codepaths, surely.

I think arch is doing pretty well in this area, actually.

It was deliberately engineered such that most of the "crappy error
messages" were separate code paths.   Thus, when people had an "itch"
because of one of the nasty error messages, they could fix it by
modify just one part of one file. 

People have stepped up and done that, a lot.   It's harder (far from
impossible) to get an unreasonable error message from tla today than
it was N months ago.


    >>> In addition, I've got a hunch that arch is conceptually on the right
    >>> track, but has got a few design warts that cannot be addressed without
    >>> giving up backwards compatibility.

I'm confident that you're mistaken about the warts and compatibility.

    >> If you have specific problems, we would be interested to hear them;
    >> please send to gnu-arch-users@gnu.org.

    > I'm not very fond at all of some of Tom's poster childs,
    > unfortunately, but I'm going to write something down, probably before
    > the end of this month.

FWIW, I'm trying to be really good at multiculturalism in a specific
sense:

We can agree about some things and disagree about others, but just
focus on what we agree about.

In other words, if Arch is useful to you and participating in the arch
community is mutually useful to us, great, let's do that.   I'll try
not to entail any of my non-Arch "poster childs" in the collaboration.

-t