When will CVS be replaced by modern version control system?

[Les Mikesell]

Nicolas Mailhot wrote:
> 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.

The key to making it work is to make the tag name the only thing that 
can pass between the developer, the QA approver and the release deployer 
so they all have to be using the same thing.  That can be arranged by 
mandate from the right person in a proprietary environment - but the 
best you'll probably do with internet development is to glue a bug 
tracker to the revision number.

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

Couldn't that be equally true of distributed SCMs?

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

I do know the difference - a company where I worked for years had one 
group that was religious about deployment builds being based strictly on 
tags and the SCM containing everything necessary for the build and 
another that did a lot of hand tweaking and could only do the build on 
one machine that nobody remembered how to reconstruct.  A patient QA 
dept. was the only thing that let the latter group survive.

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

An SCM-to-binary mechanism that only deployed QA-tagged versions should 
be indistinguishable from ones that nail released content in other ways.
You seem to be equating QA/testing with a deployment mechanism which is 
just coincidental.

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

But RPM is barely enough and only works in a forward direction.  Maybe 
the place to really take advantage of SCM features would be to let one 
manage the installed package lists as part of the OS functionality, and 
teach yum to go backwards or forwards so you would have a way to 
duplicate another machine's installed state or a prior one.

-- 
   Les Mikesell
    lesmikesell at gmail.com