different strains of CVS (was Re: cvs 1.11.2 server hungs on sigpipe)

[Mark D. Baushke]

Paul Edwards <kerravon@nosppaam.w3.to> writes:

> "Mark D. Baushke" <mdb@cvshome.org> wrote in message 
> news:mailman.2446.1046253164.21513.bug-cvs@gnu.org...
> 
> Thanks for all the historical info Mark.

You are very welcome. I didn't mention a LOT of the contirbutors (and
there have been many). You really should go to the ChangeLog files for
a better understanding of who has done what and when they did it. You
may also want to look at this page:

  http://www.cvshome.org/cyclic/cvs/dev-people.html

which gives a list and brief description of many of the various CVS
developers and although it does not appear to have all of the names of
folks that have contributed, it is a fairly good list.

> > > And how many different strains are there of CVS?
> 
> > cvshome.org
> >
> > The *BSD folks have minor feature additions on their versions of CVS
> >   freebsd.org
> >   netbsd.org
> >   openbsd.org
> 
> Do they keep up to date with the releases from cvshome?  Or
> are they off on a branch of their own forever?

Derek has already mentioned the CVSNT problems.

The situation with FreeBSD is much better. I have been trying to get
FreeBSD features ported back to cvshome.org for a while now. It just
requires making small changes with test cases and then justification
for why it should change. The recent messages on adding the CVS_PID
environment variable is one such patch.

Here is a list of outstanding features in FreeBSD that are not present
in cvshome:

  - CVS_PID environment variable for the process id of cvs
        [I submitted a patch to bug-cvs for discussion.]

  - CVS_LOCAL_BRANCH_NUM environment variable support for choosing the
    magic branch number.  (for CVSup local-commit support)
        [This one is needed if you want to have local changes
        in a mirror of the master repository and not have them get
        clobbered by a CVSup update of the repository.]

  - CVSREADONLYFS environment variable and global option -R to enable
    no-locking readonly mode (eg: cvs repo is a cdrom or mirror)
        [A minor feature that could be misused as it does not create
        any lock files in the repository at all.]

  - "cvs" keyword in .cvsrc for global options
        [Useful to specify global switches like -q or -Q.]

  - CVS_OPTIONS environment variable read before the .cvsrcfile
        [Useful if you need to override the .cvsrcfile at times, say by
        telling it to ignore the .cvsrc file .]

  - CVSROOT/options file
        [Useful for the CVSHeader and other keyword expansion controls.]

  - Variable keyword expansion controls including custom keywords.
        [Being able to add new keywords like $FreeBSD$ $OpenBSD$ $NetBSD$
        for keeping track of the version of code imported from someone
        else that uses cvs source control.]

  - $ CVSHeader$ keyword - like Header, but with $CVSROOT stripped off.
        [New cvs keywords that help cvs mirrors that keep files in trees
        that are different than the master repository looking the same.]
        

  - CVS_RSH is ssh rather than rsh
        [This is the right default, but not everyone agrees yet.]

  - -T switch for checkout and update to Create/Update the
    CVS/Template file.
        [Sadly, this feature is intended for a local cvs mirror and does
        not work in client/server mode. It would be nice to setup a new
        client/server message to update the CVS/Template file when a cvs
        update is performed, but that work has not yet happened.]

  - cvs diff accepts two -j rev:date options to diff against a
    revision relative to a branch tag in the past.
        [This general kind of rev:date format needs more discussion,
        but is very nice to use in practice.]

  - New global -U switch for server mode to skip CVSROOT/password and
    require /etc/passwd users only.
        [I am not sure how to justify this patch.]

  - New global -g switch to force group-write permissions on working
    files.
        [Let your umask be relaxed for some of your cvs sandboxes.]

I would greatly appreciate having all of those features as a part of the
both the FreeBSD and cvshome versions of cvs, but it remains to be seen
if they will be accepted even if I port them back with appropriate tests.

        Enjoy!
        -- Mark