remove some stray files

This commit is contained in:
peter 1997-06-22 12:50:33 +00:00
parent 6d701eaf76
commit 0a4476a7fb
3 changed files with 0 additions and 287 deletions

View File

@ -1,159 +0,0 @@
CVS port to VMS
DISCLAIMER: This port must be considered experimental. Although
previous versions have been in use at one large site since about
October, 1995, and the port is believed to be quite usable, various
VMS-specific quirks are known and the port cannot be considered as
mature as the ports to, say, Windows NT or unix. As always, future
progress of this port will depend on volunteer and customer interest.
This port is of the CVS client only. Or in other words, the port
implements the full set of CVS commands, but cannot access
repositories located on the local machine. The repository must live
on another machine (a Unix box) which runs a complete port of CVS.
Most (all?) work to date has been done on OpenVMS/AXP 6.2. Other VMS
variants might work too.
You will also need GNU patch installed on your system. Here's a list
of ftp servers which have VMS GNU resources, taken from
ftp://prep.ai.mit.edu/pub/gnu/vms.README
mvb.saic.com
wuarchive.wustl.edu
ftp.wku.edu
ftp.spc.edu
ftp.stacken.kth.se
Please send bug reports to bug-cvs@prep.ai.mit.edu.
As of CVS 1.5.something, this port passed most of the tests in
[.src]sanity.sh. I say "most" because some tests to not apply to the
CVS client. The tests were run by hand because the VMS POSIX shell
was incapable of running the script. The tests that sanity.sh
provides are not conclusive but at least provides some assurance that
the client is usable.
To compile, you will need DEC C (CC), DEC UCX, and of course DCL
installed on your machine. Just type "@build" in the top level
directory. This will build the sources in each subdirectory, and link
the executable [.src]cvs.exe
Copy the executable to an appropriate directory, and define the symbol "CVS"
in a .COM file which everyone running CVS will need to run. Here's an example
of what needs to be done.
$ CVS :== $YOUR_DEVICE:[YOUR.DIRECTORY.CVS]CVS.EXE
Accessing a remote repository can happen in several ways.
1. pserver
2. rsh - privileged (default)
3. rsh - unprivileged (on VMS side)
Here's how to do each of the above:
-------------------------------------------------------------------------------
1. pserver. This is the preferred way. It works just as it is
documented in the CVS manual (see the README file in the CVS
distribution for more information on the manual).
-------------------------------------------------------------------------------
2. Using CVS internal rsh support (privileged)
VMS's RSH is unusable for CVS's purposes (that is, the one in UCX.
Don't know about Multinet). However, there is code within CVS to
emulate RSH for purposes of contacting a CVS server "in the usual way"
via rshd. Unfortunately, this requires the VMS CVS client to be
installed with OPER privilege, by your system administrator.
RSH uses privileged ports and trusted software/hosts to determine
which user on the client side is trying to connect. Part of this
security is due to the fact that on VMS or UNIX, a non privileged
process is not permitted to bind a socket to a privileged port.
If rshd receives a connection on a non-privileged port, the connection is
immediately aborted. Only connections arriving from a privileged port will
be authenticated and served. The CVS client will therefore need privileges
under VMS to produce such a connection.
*** Please note that no careful examination has been done of the security
implications of installing CVS with the OPER privilege. If some hole
exists, then by doing so, you will enable users who are already on
your system to gain unauthorized privileges ***
-------------------------------------------------------------------------------
3. Using CVS internal rsh support (non-privileged)
There is a workaround, but this is one case where I think the cure is worse
than the disease. If you patch an rshd to not care that the RSH originating
port is "non-privileged", the CVS VMS client will allow you to define the
logical CVS_RCMD_PORT to the port number where this patched rshd will be
listening. I leave the talk of patching rshd to the gentle reader and his/her
friendly system administrator.
If I put an entry in my /etc/services file:
cvs_rcmd 4381/tcp cvs_rcmd
And add a line to /etc/inetd.conf, then restart inetd via "kill -1"
cvs_rcmd stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/cvs_rcmd
On the VMS side, you will have to do this:
$ define CVS_RCMD_PORT 4381
Then run CVS in the "usual way".
Note that the patched rshd will need to be invoked via inetd as root, so it can
authenticate and _become_ the intended user, the same as the regular rshd.
***Please note that you will be installing a security hole by doing this.***
Please also note that this security hole is no larger than allowing a
Macintosh, PC (OS/2, NT, etc.) to have it's hostname in any .rhosts file,
as any user can create a privileged socket without authentication, under these
environments. In fact, existing ports of CVS to these environment use this
to their advantage.
-------------------------------------------------------------------------------
Wildcard expansion is not yet implemented (i.e. CVS COMMIT *.c won't
work.) I think that expand_wild should be calling lib$findfile
(util.c in gzip is said to provide an example), but noone has gotten
around to implementing this.
Log messages must be entered on the command line using -m or -F. You
can use -e or define the logical EDITOR to cause CVS to try other
editors (TPU.EXE or any other editor which wants DCL command parsing
will not work) if you want to test what's available on your system. I
haven't tested this, but if you install vi or emacs, chances are it
will probably work. Just make sure the .EXE files are in a directory
listed in VAXC$PATH (is this a typo for DCL$PATH? Also, will a
logical name work?). If someone gets around to implementing it, we
should probably be using the callable editors (e.g. TPU$TPU), although
of course we also need interface(s) which are not locked into any
particular editors.
----------------------------------------
Notes regarding compiling on VAX/VMS 6.2 (not Alpha) (These are items
which hopefully will have cleaner solutions in the future, but here is
how to get around them for now):
* Need to compile lib/getdate.c with vaxc instead of decc to avoid a
compiler bugcheck. Therefore one must add SYS$LIBRARY:VAXCRTL/LIBRARY
to the link.
* In src/ignore.c, change lstat to stat. In vms/filesubr.c, change
"#ifdef S_ISLNK" to "#if 0".
* Ignore the warnings in vms/vmsmunch.c; the system include file
declares something as an int when it should be void *. Not *our*
fault!
Credits:
Initial VMS port by Benjamin J. Lee <benjamin@cyclic.com>, Cyclic
Software, October 1, 1995 (Update March 1, 1996).

View File

@ -1,97 +0,0 @@
#!/usr/bin/perl
# The version of the remote shell program on some Linuxes, at least,
# misuses GNU getopt in such a way that it plucks arguments to rsh
# that look like command-line switches from anywhere in rsh's
# arguments. This is the Wrong Thing to do, and causes older versions
# of CCVS to break.
# In addition, if we live behind a firewall and have to construct a
# "pipeline" of rshes through different machines in order to get to
# the outside world, each rshd along the way undoes the hard work CCVS
# does to put the command to be executed at the far end into a single
# argument. Sigh.
# This script is a very minimal wrapper to rsh which makes sure that
# the commands to be executed remotely are packed into a single
# argument before we call exec(). It works on the idea of a "proxy
# chain", which is a set of machines you go through to get to the CCVS
# server machine.
# Each host you go through before you reach the CCVS server machine
# should have a copy of this script somewhere (preferably accessible
# directly from your PATH envariable). In addition, each host you go
# through before you reach the firewall should have the CVS_PROXY_HOST
# envariable set to the next machine in the chain, and CVS_PROXY_USER
# set if necessary.
# This really isn't as complex as it sounds. Honest.
# Bryan O'Sullivan <bos@serpentine.com> April 1995
$usage = "usage: ccvs-rsh hostname [-l username] command [...]\n";
if ($#ARGV < 1) {
print STDERR $usage;
exit 1;
}
# Try to pick a sane version of the remote shell command to run. This
# only understands BSD and Linux machines; if your remote shell is
# called "remsh" under some System V (e.g. HP-SUX), you should edit
# the line manually to suit yourself.
$rsh = (-x "/usr/ucb/rsh") ? "/usr/ucb/rsh" : "/usr/bin/rsh";
# If you are not rshing directly to the CCVS server machine, make the
# following variable point at ccvs-rsh on the next machine in the
# proxy chain. If it's accessible through the PATH envariable, you
# can just set this to "ccvs-rsh".
$ccvs_rsh = "ccvs-rsh";
# There shouldn't be any user-serviceable parts beyond this point.
$host = $ARGV[0];
if ($ARGV[1] eq "-l") {
if ($#ARGV < 3) {
print STDERR $usage;
exit 1;
}
$user = $ARGV[2];
$cbase = 3;
} else {
$cbase = 1;
}
# You might think you shoul be able to do something like
# $command = join(' ', $ARGV[$cbase..$#ARGV]);
# to achieve the effect of the following block of code, but it doesn't
# work under Perl 4 on Linux, at least. Sigh.
$command = $ARGV[$cbase];
for ($cbase++; $cbase <= $#ARGV; $cbase++) {
$command .= " " . $ARGV[$cbase];
}
if (defined $ENV{"CVS_PROXY_HOST"}) {
$command = (defined $user)
? "$ccvs_rsh $host -l $user $command"
: "$ccvs_rsh $host $command";
if (defined $ENV{"CVS_PROXY_USER"}) {
exec ($rsh, $ENV{"CVS_PROXY_HOST"}, "-l", $ENV{"CVS_PROXY_USER"},
$command);
} else {
exec ($rsh, $ENV{"CVS_PROXY_HOST"}, $command);
}
} elsif (defined $user) {
exec ($rsh, $host, "-l", $user, $command);
} else {
if (defined $ENV{"CVS_PROXY_USER"}) {
exec ($rsh, $host, "-l", $ENV{"CVS_PROXY_USER"}, $command);
} else {
exec ($rsh, $host, $command);
}
}

View File

@ -1,31 +0,0 @@
WHAT THE "DEATH SUPPORT" FEATURES DO:
(Some of the death support stuff is documented in the main manual, but
this file is for stuff which noone has gotten around to adding to the
main manual yet).
CVS with death support can record when a file is active, or alive, and
when it is removed, or dead. With this facility you can record the
history of a file, including the fact that at some point in its life
the file was removed and then later added.
Files can now be added or removed in a branch and later merged
into the trunk.
cvs update -A
touch a b c
cvs add a b c ; cvs ci -m "added" a b c
cvs tag -b branchtag
cvs update -r branchtag
touch d ; cvs add d
rm a ; cvs rm a
cvs ci -m "added d, removed a"
cvs update -A
cvs update -jbranchtag
Added and removed files may also be merged between branches.
Files removed in the trunk may be merged into branches.
Files added on the trunk are a special case. They cannot be merged
into a branch. Instead, simply branch the file by hand.