RE: cvs commit: fptools/green-card/distrib INSTALL

=20
>  > branching/merging that is a nightmare to use for anything
>  > non-trivial,
>=20
> Branching is easy in CVS, but merging is often not.

Branching is slow - there's no reason I should have to touch every
single file in the tree to make a branch.  Branches should be cheap, if
they were we would use them a lot more.

> Things are much
> easier if one follows a few conventions (no CVS keywords, always merge
> in a single direction, use tags), but the remaining complexity is
> probably a sign of the mental complexity of the merging itself, not a
> problem of CVS.

You shouldn't have to tag every merge point - CVS should remember which
changes you already merged.  And tagging a large tree is *slow*.  Not to
mention the problems when merging file renames/moves.

>  > no distributed repositories, ...
>=20
> Huh? CVS > 1.11 supports this, and we actually used it in my last
> company: Parts of the development tree were accessible to hired
> consultants via ssh, but not the "main" parts.

I think we're using different definitions of "distributed repository".
I mean being able to create my own fork of a remote repository, commit
my own changes into it, and merge changes from the remote repository as
and when they happen.  Arch supports this kind of thing, and I believe
BitKeeper does too.

>  > [ Subversion, Arch, Darcs comments omitted ]
>=20
> But one of the main advantages of CVS should not be forgotten: There
> is a *vast* amount of tool support for it. It works with almost every
> IDE out there, dozens of CVS browers exist (e.g. the really cool
> Cervisia stuff integrated in KDE's konqueror, several web-based ones,
> etc.), it works via ssh, etc. etc.

Absolutely - this is the main reason we shouldn't ditch CVS lightly.  I
just hope that one day we will be able to, though.  Either that or CVS
fixes some of its shortcomings.

Cheers,
	Simon