CVS development ideas

This page contains ideas for possible future changes to CVS. It is similar in spirit to the TODO file in the CVS distribution.

More convenient uploads

Some users, especially web authors, will want to be able to check files into CVS without having to run a CVS client on their machine. There are a few possible ways to address this:

• FTP. Advantage is that this is how most web authors already upload. First problem is whether there is a way to specify the log message (could add a SITE MESG extension and/or figure users will not care about log messages). Second problem is an implementation detail: most FTP servers have no ability to accept plug-ins the way that HTTP servers accept CGI plug-ins.
• Form-based HTTP upload (RFC1867). Haven't look in any detail; this requires a browser which supports RFC1867.
• Regular forms. This could be a package vaguely similar to FAQ-O-Matic (for example, you might click on "edit foo.html", get an editable form with the old contents, and then click submit to make the changes).
• WEBDAV extensions to HTTP. This is the only choice of those mentioned here which would do anything about keeping several people editing the same document from getting in each other's way.

More flexible upload disposition

Right now, an upload (checkin) will either succeed or fail (based on CVSROOT/readers, commitinfo, &c). It might be nice to have more flexible mechanisms; perhaps some analogue to loginfo which gets run for patches which are not accepted for checkin. For users who are not familiar with diff/email/&c patch submission procedures, this might be more convenient.

SASL

The SASL authentication framework (defined in RFC2222) is in general terms similar to GSSAPI (RFC2078) in the sense of providing a way to support several ways of providing network security. The biggest concern is that SASL seems to involve an excessive number of network turnarounds, although this perception is in part a property of the binding of SASL to IMAP (RFC2060) which is commonly used in SASL examples, but which is not a part of SASL itself.

It is not clear how well SASL fits into the CVS protocol or whether writing an CVS-SASL binding is any easier than just binding network security mechanisms such as GSSAPI, S/KEY, anonymous access, &c, to the CVS protocol directly.

Network usage

The need to transmit entire files to the server for "cvs update" is often seen as an annoyance, and is probably avoidable without too many problems or hair.

Changes

I won't go into great detail, but here is a brief sketch of changes and why CVS needs them. When you check several files into CVS the first thing CVS does is forget that they were checked in as part of the same change. What you would like is to treat the files checked in at a given time (or perhaps, separate checkins later grouped together) as a single entity. For example "show me the diff corresponding to change #423" rather than having to get such a diff with dates, tags, and/or lots of "cvs log" and numeric revisions. A related feature is the ability to have several changes in progress in a single working directory. For example, "cvs edit" might let you specify which change you are working on, and then "cvs commit" might let you specify whether to all changes or just some of them.

Also see our user-level changes page.

Per-repository settings

Here is a brief discussion of how future CVS enhancements might maintain per-repository settings on the client side (settings on the server side can go in CVSROOT/config, of course).

Tagged text enhancements

The tagged text feature ("MT" response) currently has no way to indicate that a particular piece of text traditionally/customarily should go to stderr rather than stdout. Probably the best way to do this is with "MT +stderr" and "MT -stderr" tags (analogous to bold, italic, &c, found in languages like HTML).

Modules file -r option

People periodically suggest that the modules file should contain a -r option, so that checking out a certain module will get you a branch. Another application of what I suspect is the same feature is that you want to provide access to sources by anonymous CVS but provide people with a stable or released version by default (unless they specify they want the latest and buggiest).

Renames

The basic story about renaming files and directories (and how it might be improved) is in item #189 in the TODO file. But here are a few more thoughts.

DOS/Win3

Here are some thoughts on what it would take to make CVS run well on DOS or Windows3 (as distinct from Windows 95 or NT).

Checksums

RCS files don't have a checksum the way SCCS files do. The reason this is useful is that by the time corruption is noticed, backups might be long gone. It wouldn't be hard to add this. One subtle point: one might want to play certain tricks with rewriting part of a file and recomputing the checksum (although CVS currently doesn't). To allow that, use a checksum like SCCS's, rather than one like MD5.

Obsolete Ideas

19 Jan 1999: Moved the installation ideas to the set up page.

17 Jan 1999: Moved "Branch naming" item to the Branching page.

Jan 1999: Moved documentation ideas to the documentation page.

The idea concerning Directory addition/deletion has turned into a preliminary patch.

A documentation patch concerning the VISUAL environment variable was checked in 5 Oct 1998.

The idea for Tagged text in client/server protocol was accepted and implemented on 14 Dec 1997.