[!CrackMonkey!] [Bram@moolenaar.net: Microsoft funds OpenSource initiative]
Monkey Master and Prince Regent of San Francisco
monkeymaster at crackmonkey.org
Mon Nov 25 19:46:44 PST 2002
begin Rick Moen Lives Three Hours from Nowhere quotation:
> Quoting Patrick McFarland (unknown at panax.com):
> > I personally don't have any experience using it, but from what I
> > heard, it's better than CVS.
>
> CVS tends to become pretty painful. BK fixes all the sources of
> pain. So does any of several other options to one degree or
> another, but all of the sufficiently good options are very beta.
It actuality, CVS's painful moments mostly concern more
involved disconnected development. This is precisely the sort of
thing that the Linux kernel does (note your own characterization of
the development process as many forks).
Most of the functional problems with CVS (lack of metadata
versioning, poor directory management, etc) can usually be solved
quite neatly with a little "surgery", or direct filesystem operations
on the repository. There are the usual UI clams, of course ("nono,
you need to check out a fresh copy now--yes, I know you'll have to
redo your changes, but that's the only way to get them on *this*
branch..."), but those can be scripted around (or documented).
Speaking as someone who has integrated a great many bells and
whistles into a large many-directory CVS tree, I can say that CVS is
still a damn sight better than mailing patches around willy-nilly.
It's just missing some more *advanced* features that arch and
subversion have.
You tend to learn to work within the framework CVS provides.
Perforce folks get used to thinking of every check-in as some peculiar
N-way merge, while CVS makes a simple 2-way merge a deliberate and
contemplative event. So the Perforce types will wail about how they
can't go merging like crazy, and the CVS folks will reply "hmm, I
don't merge that often, so I always just look it up in the docs each
time."
It's a tradeoff, to be sure. The multi-merge feature can be a
lifesaver, but it can also encourage file-and-forget checkins.
> You've just described Subversion and Arch. Probably also Aegis,
> OpenCM, and PRCS2, though I'm less familiar with those. All rather
> raw, alas.
Aegis is an odd parallel to CVS. For starters, it is
local-repository only--you can't do network checkins easily, let alone
do the disconnected-repository stuff that the more modern systems
allow. Aegis is more like a development process slapped on top of
whatever local revision control system you have (usually RCS). Thus,
it forces you to move checkins between unstable/testing/stable sorts
of trees.
I'm still working through http://zork.net/doc/aegis-doc/ one
by one, but I think I'm past the point of considering aegis as a
possibility for any of my own projects.
--
A: No.
Q: Should I include quotations after my reply?
More information about the Crackmonkey
mailing list