Future CVS Development

[Kostur, Andre]

I see many suggesting floating around on what should be added to CVS (where
everybody seems to have a different idea of what "should" is).  However, I
don't recall seeing a roadmap to what is _going to be_ added to CVS.  There
are a few design decisions that I'd like to know more about, personally.

1) The exclusion of any sort of authentication capabilities in CVS.   In the
case of local CVS (where "local" also includes rsh and ssh.  They're just
hiding that they're actually running on the repository server), CVS assumes
that the userid associated with the login is reliable.  This I think is
reasonable, but if you grant a user access to the repository via CVS, how do
you prevent the user from modifying the repository directly? (Other than
"don't do that")

2) Continuing on #1, if you use the pserver method, you can have all CVS
users access the repository through a separate UNIX account, and only that
account has rights to touch the repository, but you're basically trusting
the guy that says "hi, I'm joe".  Someone out there has suggested that the
PAM patch be added to CVS so that it could do some sort of password
authentication other than the stock crypt() passwords that CVS can do.  But,
someone else started screaming that there isn't and never should be anything
resembling authentication in CVS.  It isn't secure now, and it shall never
be.

3) Another question that was asked by other people is why merging of
branches isn't recorded in the repository, and someone replied with
something along the lines of "well, if we wrote something extra in the
repository, would we still be compatable with RCS?".  Is strict
compatability with RCS that important of a deal, or is upgrade compatability
the important side of things?

4) And I know this is going to be a contentious point: the _option_ of
exclusive locking.  Now I'm not saying that everyone should use this, or
changing the default of do not strict lock files, but having the option
_available_ would make CVS much more attractive to people who want that
safety net, particularly in the case of binary files which cannot be merged.
It would be really irritating to start modifying a file, work on it for 3
days, try to commit it only to find that someone else changed a spelling
error 5 minutes before you committed, with the end result that you have to
do a manual merge on your own.  An argument that I can see offhand is that
in a widely distributed development environment, you don't want to lock down
files for editing since the guy over in Europe (I'm North American), may
lock a file and accidentally leave it locked.  One possible solution (I
haven't thought it through completely...) is that exclusive locks are
"leased" for a certain period of time, and must be renewed to continue past
that.


Now do be gentle... I am looking for calm, reasoned debate, and not a
flamefest... (although I am pulling on the flame-retardant longjohns as we
speak....), particularly on what direction is CVS going.

Kostur, Andre.vcf
Description: Binary data