Re: Future CVS Development

[Mark]

--- "Kostur, Andre" <address@hidden> wrote:

> 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

I've had users that for once reason or another had to go into the CVS
repository to vi (look at) or cp (sometimes moved by mistake). To make the CVS
repository idiot-proof, I normally use setgid bit on the cvs binary or use
pserver with no one in the group that owns the repository.

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

I think merge tracking can be added without compromising the RCSfile format,
forward/backward cvs compatability. Merge info need not be stored in the
RCSfile, could be setup similar to edits/watches. It will just take much add-on
code, some cvs commands and options will have to do more than they currently do
(see a previous post of mine). I don't think that much/if any existing
code/functionality would have to change. But adding this functionality will
take much time by whomever wants to work on it.

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

I would guess that cvs edit could be given an option to signify a reservered
checkout (and unreserve it), then cvs commit would have to verify reserved
files. I am sure there is more to it (like ensuring that the user is updated to
latest verion on branch before locking).

But I think the editors is okay for a reserved checkout substitute. Using
editors, you have the option of editing at the same time, communicationing with
the other person editing, or playing solitaire till the other person is done.

Maybe to address the binary issue, cvs edit can auto-determine if the file is
binary and refuse edit it some is already editing.

Mark


__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/