Notes from the version control BOF at the summit

[Florian Weimer]

* Tom Lord:

>     > 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.

See?  Here we go again...

> 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).

This is a strong claim, but I think it isn't quite true (only if you
are accustomed to all the little annoyances and are no longer feeling
the pain, so to speak).

> The current first generation of Arch users, having an unbiased
> choice, have collectively decided that decentralized is usually the
> best thing.

Centralized vs decentralized is not just a technical distinction
(given enough effort, you can turn one tool that favors one choice
into something for the other).  It can also ave great impact on
development.

I've already seen two projects which declined considerably after
version control software was introduced.  Previously, distributed
development was implemented by ad-hoc patch submission, and frequent
releases synchronized everyone with the current state of development
and provided clear reference points.  With version control, regular
releases have almost stopped (and security fixes suddenly take a very
long time for one of the projects).  This is not tied to the type of
version control, by the way; one project is centralized, one is
extremely distributed (de facto, it even lacks an official release
tree).

The GCC Release Manager will continue to do an excellent job, but I
fear that a drastic change in the underlying revision control system
could make the developers' and even his much more complicated.

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

The archive does not reflect which branches are in active development
and which aren't.  I think this might be a usability issue and leads
to hacks such as periodic archive deprecation (e.g. a switch from
lord@emf.net--2003b to lord@emf.net--2004).

> 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.

I know.  A strength of arch is the availability of tolerable
workarounds.  But this also means that there is less incentive to fix
these issues.

>     > 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. 

Well, it's not, I currently pay extra for the web server that servers
some of my arch changesets. 8-)

>     > 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 GCC, right now.

> In arch world, that's pretty much _all_ that we do.

I know.  I'm not sure if this makes that much sense for all
developers.  The model which is enforced (well, strongly encouraged)
by arch certainly makes easy branching and merging mandatory.  But
this does not mean that its the most important aspect of a version
control system that should dominate the choice of a CVS successor
because other systems might get away with less branching.

> 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.

Each time I read about GNU arch, I really think I must love it, but
when I use tla, I discover that it doesn't like me. 8-((( There are a
few truly great ideas in arch.

>From another message of yours:

> A few learn svn, a few learn arch, darcs, monotone, .... whichever
> there's interest in.  Experiment a bit.  Study how other projects
> get along with these systems.  Try to imagine how it fits into
> GCC-world.  If you can imagine it making GCC-world much better, then
> start evaluating what's involved with switching and advocating for a
> switch.

There are some things that could encourage such experiments with
actual data from the GCC project.  I will ask around a bit.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com,
jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com,
tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.