When will CVS be replaced by modern version control system?

Nicolas Mailhot nicolas.mailhot at laposte.net
Mon Nov 12 22:30:46 UTC 2007


Le lundi 12 novembre 2007 à 14:19 -0600, Les Mikesell a écrit :
> Nicolas Mailhot wrote:

> > Ironically Fedora cvs is one exception and that's only because koji will
> > only build stuff when given a tag number, and generally speaking we have
> > anal brutal dumb SCM procedures that force everyone to behave.
> 
> Yes, I've always considered the ability to reference things by tag name 
> only and have it give consistent results to be almost the whole point of 
> using the SCM, at least on the testing/release side of things.

Well, that's the theory, in practice what's tested is the tarball that's
given to QA (internal QA in proprietary world, internet QA for FLOSS).
Unless projects have totally automated the SCM to tarball step, and have
very strong discipline that forbids massaging the tarball in something
suitable instead of fixing stuff in the SCM then re-starting the lengthy
automated export when small stuff is broken, SCM tag is only a release
approximation.

And when projects break up, or fold, the only part remaining (that can
still be packaged years later) are the tarballs that were mirrored on
code repository sites.

What developers "test" are SCM dumps build in an environment which has
usually little in common with the one production entities like Fedora
uses. Which does not mean developer testing is useless, just what you're
used to with direct SCM access and what Fedora does at packaging time
are two different things. One workflow emphasises re-build speed at the
expense of perfect reliability or reproducibility. The other emphasises
reliability and reproducibility at the expense of speed.

You usually need some time in a support/sysadmin position managing
systems built by developers from SCM dumps (or god forbid production
systems directly re-build from developer SCM-plugged RAD IDE
environments) to appreciate the difference. The developer just wants
direct access so he can quickly inject code fixes in case of bugs. The
sysadmin wants to nail the damn thing down. It does not matter if there
are bugs as long as they're known bugs and he can organise himself so
users do not call for help in the middle of the night (when developers
sleep). The organic uncontrolled continuously evolving system developers
typically dream of is his worst nightmare.

rpm is designed to protect the sysadmin, and help him nail down
developer code dumps. It limits what's needed to be trusted from
developer systems to the bare minimum (release archive plus standalone
patches) and enforces a process where changes are evolutionary and
small. And this is good. It's a beautiful design. Much better than every
system I've seen that tried the direct SCM-to-binary approach, and where
developer happiness was achieved at the expense of everyone else in the
ecosystem.

rpm formalism is an annoyance just like unix permissions are an
annoyance. Remove them and everything quickly spins out of control.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/00547954/attachment.sig>


More information about the fedora-devel-list mailing list