From owner-svn-doc-all@freebsd.org Thu Apr 14 21:52:32 2016 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A405AEC7EF; Thu, 14 Apr 2016 21:52:32 +0000 (UTC) (envelope-from wblock@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D86F012E2; Thu, 14 Apr 2016 21:52:31 +0000 (UTC) (envelope-from wblock@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u3ELqVUK054810; Thu, 14 Apr 2016 21:52:31 GMT (envelope-from wblock@FreeBSD.org) Received: (from wblock@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u3ELqVer054800; Thu, 14 Apr 2016 21:52:31 GMT (envelope-from wblock@FreeBSD.org) Message-Id: <201604142152.u3ELqVer054800@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: wblock set sender to wblock@FreeBSD.org using -f From: Warren Block Date: Thu, 14 Apr 2016 21:52:31 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48637 - in head/en_US.ISO8859-1/books/handbook: cutting-edge mirrors X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 21:52:32 -0000 Author: wblock Date: Thu Apr 14 21:52:30 2016 New Revision: 48637 URL: https://svnweb.freebsd.org/changeset/doc/48637 Log: Remove CTM from the Handbook. Some time back, CTM became deprecated or impractical or both. Cleared with clusteradm. Modified: head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml head/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml Thu Apr 14 18:53:26 2016 (r48636) +++ head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml Thu Apr 14 21:52:30 2016 (r48637) @@ -73,9 +73,8 @@ How to keep a &os; system up-to-date with - freebsd-update, - Subversion, or - CTM. + freebsd-update or + Subversion. @@ -1036,13 +1035,6 @@ before running "/usr/sbin/freebsd-update -CURRENT code from the head branch of one of the Subversion mirror sites listed in . - - Users with very slow or limited Internet connectivity - can instead use CTM as described in , - but it is not as reliable as - svn and - svn is the recommended method - for synchronizing source. @@ -1150,9 +1142,7 @@ before running "/usr/sbin/freebsd-update to check out the source for the desired branch. Branch names, such as stable/9, are listed at www.freebsd.org/releng. - CTM () can be used if a reliable - Internet connection is not available. + xlink:href="&url.base;/releng/">www.freebsd.org/releng. @@ -1175,9 +1165,8 @@ before running "/usr/sbin/freebsd-update Synchronizing Source There are various methods for staying up-to-date with the - &os; sources. This section compares the primary services, - Subversion and - CTM. + &os; sources. This section describes the primary service, + Subversion. While it is possible to update only parts of the source @@ -1207,33 +1196,9 @@ before running "/usr/sbin/freebsd-update Subversion is described in . - - CTM - - CTM does not interactively - compare the local sources with those on the master archive or - otherwise pull them across. Instead, a script which identifies - changes in files since its previous run is executed several - times a day on the master CTM machine. Any detected changes are - compressed, stamped with a sequence-number, and encoded for - transmission over email in printable ASCII - only. Once downloaded, these deltas can - be run through ctm.rmail which will - automatically decode, verify, and apply the changes to the - user's copy of the sources. This process is more efficient than - Subversion and places less strain on - server resources since it is a push, rather - than a pull, model. Instructions for using - CTM to synchronize source can be - found at . - If a user inadvertently wipes out portions of the local archive, Subversion will detect and - rebuild the damaged portions. CTM - will not, and if a user deletes some portion of the source tree - and does not have a backup, they will have to start from scratch - from the most recent base delta and - rebuild it all with CTM. + rebuild the damaged portions during an update. Modified: head/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml Thu Apr 14 18:53:26 2016 (r48636) +++ head/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml Thu Apr 14 21:52:30 2016 (r48637) @@ -133,294 +133,6 @@ This site doesn't have any products newe &chap.mirrors.ftp.inc; - - Using CTM - - - CTM - - - CTM is a method for keeping a - remote directory tree in sync with a central one. It is built - into &os; and can be used to synchronize a system with &os;'s - source repositories. It supports synchronization of an entire - repository or just a specified set of branches. - - CTM is specifically designed for - use on lousy or non-existent TCP/IP connections and provides - the ability for changes to be automatically sent by email. It - requires the user to obtain up to three deltas per day for the - most active branches. Update sizes are always kept as small as - possible and are typically less than 5K. About one in every ten - updates is 10-50K in size, and there will occasionally be an - update larger than 100K+. - - When using CTM to track &os; - development, refer to the caveats related to working directly - from the development sources rather than a pre-packaged release. - These are discussed in Tracking - a Development Branch. - - Little documentation exists on the process of creating - deltas or using CTM for other - purposes. Contact the &a.ctm-users.name; mailing list for - answers to questions on using - CTM. - - - Getting Deltas - - The deltas used by - CTM can be obtained either through - anonymous FTP or email. - - FTP deltas can be obtained from the - following mirror sites. When using anonymous - FTP to obtain - CTM deltas, select a mirror that is - geographically nearby. In case of problems, contact the - &a.ctm-users.name; mailing list. - - - - Global mirror - - - - - ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CTM/ - - - - - - - South Africa, backup server for old deltas - - - - - ftp://ftp.za.FreeBSD.org/pub/FreeBSD/CTM/ - - - - - - - Taiwan/R.O.C. - - - - - ftp://ctm.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ - - - - ftp://ctm2.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ - - - - ftp://ctm3.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ - - - - - - - To instead receive deltas through email, subscribe to one - of the ctm-src distribution lists available - from http://lists.freebsd.org/mailman/listinfo. - For example, &a.ctm-src-cur.name; supports the head - development branch and &a.ctm-src-9.name; supports the 9.X - release branch. - - As CTM updates arrive through - email, use ctm_rmail to unpack and apply - them. This command can be run directly from an entry in - /etc/aliases in order to automate this - process. Refer to &man.ctm.rmail.1; for more details. - - - Regardless of the method which is used to get deltas, - CTM users should subscribe - to the &a.ctm-announce.name; mailing list as this is the - only mechanism by which CTM - announcements are posted. - - - - - <application>CTM</application> Usage - - Before CTM deltas can be used - for the first time, a starting point must be produced. - - One method is to apply a starter delta to - an empty directory. A starter delta can be recognized by the - XEmpty in its name, such as - src-cur.3210XEmpty.gz. The designation - following the X corresponds to the origin - of the initial seed, where - Empty is an empty directory. As a rule, - a base transition from Empty is produced - every 100 deltas. Be aware that starter deltas are large and - 70 to 80 Megabytes of gzip'd data is common - for the XEmpty deltas. - - Another method is to copy or extract an initial source - from a RELEASE media as this can save a significant transfer - of data from the Internet. - - Once a base delta has been created, apply all deltas with - higher numbers. To apply the deltas: - - &prompt.root; cd /directory/to/store/the/stuff -&prompt.root; ctm -v -v /directory/which/stores/the/deltas/src-xxx.* - - Multiple deltas can be applied with a single command as - they will be processed one at a time and any deltas that are - already applied will be ignored. - CTM understands - gzip compressed deltas, which saves disk - space. - - To verify a delta without applying it, include - in the command line. - CTM will not actually modify the - local tree but will instead verify the integrity of the delta - to see if it would apply cleanly. Refer to &man.ctm.1; for - more information about available options and an overview of - the process CTM uses when applying - deltas. - - To keep the local source tree up-to-date, every time a - new delta becomes available, apply it through - CTM. - - Once applied, it is recommended to not delete the deltas - if it is a burden to download them again. This way, a local - copy is available in case it is needed for future disaster - recovery. - - - - Keeping Local Changes - - Developers often experiment with and - change files in their local source tree. - CTM supports local modifications in - a limited way: before checking for the presence of a file, - it first looks for a file with the same name and a - .ctm extension. If this file exists, - CTM will operate on it instead of - the original filename. - - This behavior provides a simple way to maintain local - changes. Before modifying a file, make a copy with a - .ctm suffix. Make any changes to the - original filename, knowing that - CTM will only apply updates to the - file with the .ctm suffix. - - - - Other <application>CTM</application> Options - - - - Finding Out Exactly What Would Be Touched by an - Update - - - To determine the list of changes that - CTM will make to the local - source repository, use . This option - is useful for creating logs of the changes or when - performing pre- or post-processing on any of the - modified files. - - - - - Making Backups Before Updating - - - To backup all of the files that would be changed by - a CTM update, specify - . This - option tells CTM to backup - all files touched by the applied - CTM delta to - backup-file. - - - - - Restricting the Files Touched by an Update - - - To restrict the scope of a given - CTM update, or to extract - just a few files from a sequence of deltas, filtering - regular expressions can be specified using - , which specifies which files to - process, or , which specifies which - files to ignore. - - For example, to extract an up-to-date copy of - lib/libc/Makefile from a collection - of saved CTM deltas: - - &prompt.root; cd /directory/to/extract/to/ -&prompt.root; ctm -e '^lib/libc/Makefile' /directory/which/stores/the/deltas/src-xxx.* - - For every file specified in a - CTM delta, - and are - applied in the order given on the command line. A file - is processed by CTM only if - it is marked as eligible after all - and options are applied. - - - - - - - Using <application>Subversion</application>