Re: Future CVS Development

[Noel L Yap]

>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")

Don't grant them unlimited access.  This is trivial to do when using SSH.

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

Again, in theory SSH can be used for this.  In practice, you may have some
problems with different versions of SSH.

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

IMHO, using RCS on a CVS repo isn't a big req.  I'm also guessing (wildly) that
this kind of compatibility can still be attained with the proper implementation.

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

Or how 'bout using the edit and commit patches that more or less give you
advisory locks.  I'm thinking you may also want to add (if it's possible without
breaking something like client/server) a server-side config that would make
these flags a default.

Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.