Subject: CVSup 14.1 is now available
Date: Tue, 07 Jan 1997 16:23:12 -0800
From: John Polstra <jdp>
Announcing CVSup 14.1
---------------------
Release 14.1 of CVSup, the CVS-aware network distribution system, is now
available.
Where to Get CVSup
-------------------
CVSup is free software. It is available from the following FTP sites:
ftp://freefall.freebsd.org/pub/CVSup/
ftp://ftp.polstra.com/pub/FreeBSD/CVSup/ (slow; avoid if possible)
Full sources as well as FreeBSD binaries are available:
cvsup-bin-14.1.tar.gz FreeBSD static binaries for the client
cvsupd-bin-14.1.tar.gz FreeBSD static binaries for the server
cvsup-14.1.tar.gz Sources **
The MD5 signatures for these files are:
MD5 (cvsup-bin-14.1.tar.gz) = b06efe8be163f127f5103968f0545067
MD5 (cvsupd-bin-14.1.tar.gz) = 6c822e77db2d8b9179d8c6d4c281acea
MD5 (cvsup-14.1.tar.gz) = e131ef39f1cfb5807d9f488b0b3b0691
An updated port will appear in the FreeBSD ports and packages
collections soon:
Port:
ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/net/cvsup/
Package:
ftp://ftp.freebsd.org/pub/FreeBSD/packages-current/net/cvsup-14.1.tgz
ftp://ftp.freebsd.org/pub/FreeBSD/packages-2.2/net/cvsup-14.1.tgz
The FreeBSD package now depends only on the "modula-3-lib" package,
a subset of the Modula-3 installation consisting of only the shared
libraries. Because of this, you can now install and use the "cvsup"
package in a reasonable amount of disk space. The package is much
smaller than the statically linked binary distribution, so updates
to new versions of CVSup should be more convenient now. The package
is the recommended distribution for binary-only users. The static
binary distributions may be phased out soon.
If you want SOCKS support, you must also install the "modula-3-socks"
port or package:
Port:
ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/lang/modula-3-socks/
Package:
ftp://ftp.freebsd.org/pub/FreeBSD/packages-current/lang/modula-3-socks-1.0.tgz
ftp://ftp.freebsd.org/pub/FreeBSD/packages-2.2/lang/modula-3-socks-1.0.tgz
SOCKS is supported only under FreeBSD, and only with dynamically linked
executables. The static binary distributions do not support SOCKS.
** If you wish to build CVSup from the sources, be sure to read the
discussion further on in this announcement.
Compatibility with Previous Releases
-------------------------------------
This release is fully backward-compatible with release 14.0.
There are a couple of very minor compatibility issues which could affect
a few users upgrading from a release prior to 14.0.
Clients: The default for the "base" directory has changed from
"/usr"
to "/usr/local/etc/cvsup". Practically everybody specifies the base
explicitly in their supfiles, so this change will have no impact for
most people. If you have been using the default value, you will need to
add a line "*default base=/home" to your supfile, or specify "-b
/home"
on the cvsup command line.
Servers: The "hostbase" is no longer taken from the client's
supfile.
It is now controlled on the server host. On the FreeBSD project,
"hostbase=/home" was always used in the past. People operating
servers
will need to specify "-b /home" on the cvsupd command line to get the
same effect. Alternatively, move your server configuration files from
"/home" to the new default location, "/usr/local/etc/cvsup".
(As
before, most of the configuration files appear under a subdirectory
named "sup".)
What Has Changed Since the Previous Release?
---------------------------------------------
For both the client and the server, there is now a "-c collDir"
command line option for overriding the name of the subdirectory
where the collection information is maintained. The name used
to be hard-wired to "sup", and that is still the default.
If the client's prefix directory for a collection doesn't exist,
it is no longer a fatal error. A warning is produced and the
offending collection is skipped, but the others are still processed
normally. If the prefix is a symbolic link pointing to "SKIP",
the warning is suppressed.
Fixed a server problem that caused certain pathological updates in
checkout mode to take damned near forever.
Fixed a problem that caused fixups to be performed for certain
RCS files that were corrupted to begin with. The files had incorrect
dates on some revisions, because they had been hacked up by hand.
That caused the client to write out the delta texts in the wrong
order. Since there was a way to work around this dubious situation, I
implemented it.
Changed the logic surrounding the time stamp comparisons between
files on the client and files on the server, eliminating a
miniscule possibility of missed updates. Now, the system can
detect it if a file happens to have been modified independently
on both the client and the server at exactly the same time. The
file is recognized as possibly needing an update, even though
its time stamp is the same on the client and the server.
Fixed the client's lock file handling ("-l" option) so that the
lock remains held during the intervals between retries. Formerly,
the lock was released during those intervals, rendering it fairly
useless for avoiding multiple stacked up processes from cron
jobs.
Added a check to make sure it is possible to get the client host's
own IP address before starting up the GUI. Formerly, misconfigured
hosts (e.g., incorrect host name) would result in a baffling
"IP.FatalError" message.
Changed the priorities for syslog messages from the server so
that messages associated with individual client connections are
logged at "info" level rather than "notice". For simple
syslog.conf
setups, that takes these mostly informational messages out of
/var/log/messages, where they caused a lot of clutter. The
logging still isn't perfect, as a few more serious messages now
also come out at "info" level. Nevertheless, the new situation
is an improvement.
Added a new "-k" command line option for the client, intended
for debugging. This option causes the bad temporary files to be
saved for files requiring fixups due to incorrect edits. The
fixups are still performed, regardless.
Further improved the server's handling of corrupted RCS files.
In virtually all circumstances, the server should now be able to
issue warnings for corrupted RCS files and carry on with the
remaining updates.
Beefed up the semantic checking of RCS files, to detect some more
pernicious kinds of corruption.
Added a "norsync" option which can be specified in the server's
"releases" files. It allows the server to disable the use of
the rsync algorithm for selected collections and releases. This
is beneficial for CVS repositories, where CVSup's "append" updates
work better and more efficiently than the rsync algorithm.
Added additional server checks of the filenames received from
the client, to ensure that the server cannot be spoofed into
delivering files from outside its collections.
What Is CVSup?
---------------
CVSup is a software package for distributing and updating collections
of files across a network. CVSup is specifically tailored to
distributing CVS repositories. By taking advantage of the special
properties of the files contained in CVS repositories, CVSup is
able to perform updates much faster than traditional systems. It is
especially valuable for people with slow Internet connections.
CVSup parses and understands the RCS files making up a CVS repository.
When updates occur, CVSup extracts new deltas directly from the RCS
files on the server and edits them into the client's RCS files.
Likewise, CVSup notes the addition of new symbolic tags to the files
on the server and sends only the new tags to the client.
CVSup is able to merge new deltas and tags from the server with deltas
and tags added locally on the client machine. This makes it possible
for the client to check local modifications into his repository
without their being obliterated by subsequent updates from the server.
Note: Although this feature is fully implemented in CVSup, it will
probably not be practical to use it until some small changes have been
made to CVS.
In addition to distributing the RCS files themselves, CVSup is able to
distribute specific checked-out versions. The client can specify a
symbolic tag, a date, or both and CVSup will extract the appropriate
versions from the server's CVS repository. Checked-out versions do
not need to be stored on the server since CVSup can extract any
version directly from the CVS repository.
If the client has an existing checked-out tree, CVSup will apply the
appropriate edits to update the tree or transform it into the
requested version. Only the differences between the existing version
and the desired version are sent across the network.
To update non-RCS files, CVSup uses the highly efficient rsync
algorithm, developed by Andrew Tridgell and Paul Mackerras.
CVSup uses lightweight processes (threads) to implement a streaming
protocol across the network. This completely eliminates the delays
associated with the lock-step, request-reply form of communication
used by many existing protocols, such as sup and NNTP. Information
is transferred at the full available speed of the network in both
directions at once. Network latency and server response delays
are rendered practically irrelevant.
CVSup uses the "zlib" compression package to optionally compress all
communications. This provides an additional 65-75% compression, on
top of the diff-based compression already built into CVSup.
For efficiency, all processing is built into the CVSup package
itself. Neither the client nor the server executes any other
programs.
For further information about how CVSup works, see the "Blurb"
document
in the CVSup distribution.
Using CVSup to Maintain FreeBSD Sources
----------------------------------------
CVSup servers are currently running at the following FreeBSD mirror
sites:
USA:
cvsup.freebsd.org
cvsup2.freebsd.org
cvsup4.freebsd.org
Argentina:
cvsup.ar.freebsd.org
Australia:
cvsup.au.freebsd.org
Germany:
cvsup.de.freebsd.org
Japan:
cvsup.jp.freebsd.org
Netherlands:
cvsup.nl.freebsd.org
South Africa:
cvsup.za.freebsd.org
Taiwan:
sup.tw.freebsd.org
Additional servers are planned to come on-line soon.
Using CVSup, you can easily receive or update any of the standard
FreeBSD source releases, namely, "cvs", "current", and
"stable".
The manual page for cvsup(1) describes how to do that. For more detailed
instructions, see the FreeBSD Handbook, section 17.2:
http://www.freebsd.org/handbook/
Building CVSup from the Sources
--------------------------------
CVSup is written in Modula-3, a modern, compiled, object-oriented
language. Modula-3 integrates threads, exceptions, and garbage
collection, providing an ideal vehicle for this sort of application.
Without Modula-3, CVSup would almost certainly not exist today.
If you wish to build CVSup from the sources, you will first need
to install the free Modula-3 compiler and runtime libraries from
DEC SRC. A port is available in the FreeBSD ports collection, in
"lang/modula-3". The corresponding package is, of course, available
in the packages collection.
You will also need version 1.0.4 or later of the "zlib" library.
In FreeBSD-2.1.6 and later releases, this library has been incorporated
into the system sources, in "src/lib/libz". Prior to that, a
FreeBSD port was available in "devel/libz" of the FreeBSD ports
collection. For other sources of this library, see the "Install"
file. Do not try to use versions earlier than 1.0.4.
You will also need Poul-Henning Kamp's "libmd" library. It is a
standard library on FreeBSD systems.
Portability Issues
-------------------
I intend for CVSup to be portable to most POSIX systems. The
present release has only been tested under FreeBSD versions 2.1
and later. Primarily because of packaging problems, this release
of CVSup probably won't build out-of-the-box on other systems.
Among other things, it relies on Poul-Henning Kamp's "libmd"
encapsulation of the MD5 subroutines. The library itself is quite
portable, but its Makefiles are BSD-specific. There are probably
some other FreeBSD-specific things in CVSup that have not been
found yet.
Anybody who succeeds in porting CVSup to other systems is encouraged
to send his changes to <cvsup-bugs@polstra.com>. As long as the
changes are reasonably palatable, they will be incorporated into
future CVSup releases.
CVSup uses several POSIX-specific functions which may make it more
of an effort to port the package to non-POSIX systems such as Win32.
These functions include mmap, fork, syslog, stat, and chmod, among
others.
Status of this Release
-----------------------
CVSup has seen heavy use and has been quite stable for months.
Like all software, though, it is not perfect. Please be prepared
to find bugs -- without a doubt, there are some. Please report
bugs to <cvsup-bugs@polstra.com>.
---
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Self-knowledge is always bad news." -- John Barth