d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Make some updates to the hardware guide, take some of Chuck Robey's comments

Browse Source 
regarding the source syncing section (sss!).
This commit is contained in:
Jordan K. Hubbard 1996-08-29 04:26:42 +00:00
parent a0228a8384
commit b73620c976
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=17882
2 changed files with 61 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
share/doc/handbook/hw.sgml
View File

@ -1,4 +1,4 @@
<!-- $Id: hw.sgml,v 1.38 1996/08/24 10:18:50 jkh Exp $ -->
<!-- $Id: hw.sgml,v 1.39 1996/08/27 03:55:55 jkh Exp $ -->
<!-- The FreeBSD Documentation Project -->
<!--
@ -77,12 +77,13 @@ Slippery when wet. Beware of dog.
therefore buy one of the newer Triton II based motherboards, which offer
both better performance and parity checking.
<p>At the even higher end, the Intel/Venus Pro (VS440FX) motherboard
appears to work very well with FreeBSD, as does its accompanying 200Mhz
P6 (Pentium Pro) CPU. Recent price drops (pluments might be a more
accurate term) have dropped P6 systems into a very affordable price
bracket, at least in the United States, and for serious server
applications you may wish to look no further than one of these.
<p>At the even higher end, the Intel/Venus Pro (<ref id="hw:mb:pci"
name="VS440FX">) motherboard appears to work very well with FreeBSD,
as does its accompanying 200Mhz P6 (Pentium Pro) CPU. Recent price
drops (plummets might be a more accurate term) have dropped P6 systems
into a very affordable price bracket, at least in the United States,
and for serious server applications you may wish to look no further than
one of these.
<sect2><heading>Disk Controllers</heading>
<p>This one is a bit trickier, and while I used to recommend the
@ -215,8 +216,7 @@ Slippery when wet. Beware of dog.
<sect2><heading>* ISA</heading>
<sect2><heading>* EISA</heading>
<sect2><heading>* VLB</heading>
<sect2><heading>PCI</heading>
<sect2><heading>PCI<label id="hw:mb:pci"></heading>
<p><em>Contributed by &a.rgrimes;.<newline>25 April 1995.</em></p>
<p><em>Continuing updates by &a.jkh;.</em><newline>Last update on
<em>26 August 1996.</em></p>

57
share/doc/handbook/synching.sgml
View File

@ -1,4 +1,4 @@
<!-- $Id: current.sgml,v 1.8 1996/01/31 14:26:01 mpp Exp $ -->
<!-- $Id: synching.sgml,v 1.1 1996/02/11 00:16:20 jkh Exp $ -->
<!-- The FreeBSD Documentation Project -->
<chapt><heading>Synchronizing source trees over the Internet<label id="synching"></heading>
@ -7,15 +7,62 @@
<!--
Last updated: $Date: 1996/01/31 14:26:01 $
Last updated: $Date: 1996/02/11 00:16:20 $
This document tries to describe the various ways in which a user may
use the internet to keep development sources in synch.
-->
<p>There are various ways of using an Internet (or email) connection
to stay up-to-date with whatever collection of FreeBSD project sources
it is that interests you. The primary services we offer are:
<p>There are various ways of using an Internet (or email) connection
to stay up-to-date with any given area of the FreeBSD project sources,
or all areas, depending on what interests you. The primary
services we offer are CTM, SUP and CVSup (<bf>new</bf>).
<p>It's been suggested by some that CTM obsoletes SUP. This isn't quite
true, in fact, because each tool was originally designed to serve a
different constituency and, although they have both undergone significant
improvement since first going into service, they take fundamentally
different approaches in trying to solve the source syncronization problem.
SUP was originally designed to support those who had dedicated (or at
least fast) Internet connections whereas CTM was originally aimed at
supporting those who's access was limited to email only.
<p><bf>SUP</bf> (Software Update Protocol) is a system that tracks a local
copy of the FreeBSD sources on your local disk and, using configuration files
the user sets up, makes requests over the network to fetch and update any
files which have changed on the FreeBSD master archive.
<p><bf>CTM</bf>, on the other hand, does not interactively compare
the sources you have with those on the master archive.
Instead, a script which identifies changes in files since its previous run
is executed several times a day on the master archive, any detected changes
being compressed, stamped with a sequence-number and encoded for transmission
over email (printable ASCII only). Once received, these "CTM deltas" can then
be handed to the ctm_rmail(1) utility which will automatically decode, verify
and apply the changes to the user's copy of the sources. This process is
far more efficient than SUP, and places less strain on our server resources
since it's a <em>push</em> rather than a <em>pull</em> model.
<p>There are other trade-offs, of course. With SUP, you can also
inadvertantly wipe out portions of your archive and SUP will detect
and rebuild the damaged portions for you. CTM won't do this, and if
you wipe some portion of your source tree out (and don't have it backed
up) then you will have to start from scratch (from the most recent CVS
"base delta") and rebuild it all.
<p>More recently, the waters have been muddied even more by
the introduction of the <bf>CVSup</bf> utility, a highly efficient
replacement for SUP which also offers access to any branch of FreeBSD
development from a single CVS repository (which, in turn, can also be
transferred non-destructively with CVSup - any local developer work on
independant branches is preserved). It overcomes many of SUP's shortcomings
and may be <htmlurl url="ftp://freefall.freebsd.org/pub/CVSup/"
name="downloaded"> from our development server, where additonal documentation
is also provided. Both the CVSup client and server are compatible with
the sup and supfilesrv distribution file formats.
For more information on SUP and CTM, please see one of the following
sections:
&sup;
&ctm;