From owner-freebsd-questions@FreeBSD.ORG Mon Jul 21 02:06:55 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67E05A1F for ; Mon, 21 Jul 2014 02:06:55 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C16D2501 for ; Mon, 21 Jul 2014 02:06:54 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s6L26nTR009246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Jul 2014 20:06:50 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s6L26mxx009243; Sun, 20 Jul 2014 20:06:49 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 20 Jul 2014 20:06:48 -0600 (MDT) From: Warren Block To: Doug Hardie Subject: Re: Freebsd-update to 9.3 from 9.2 In-Reply-To: Message-ID: References: <4CA0146F-BD4E-4613-9050-DB0C1FDB7EA4@lafn.org> <53C8B7A2.1060504@my.hennepintech.edu> <494D0D9E-ED60-4187-ABCF-8E18CDEAB911@lafn.org> <53C8E2A7.6000000@my.hennepintech.edu> <7154054C-47D0-454C-8601-3F17095476EC@lafn.org> <066C2341-F26F-4817-B681-97119FB7EB7C@lafn.org> <0A5E66FF-D8B0-4619-91AC-C99BC2AEA04D@lafn.org> <0501F769-338A-4B23-AC7B-DBFC55C9387E@lafn.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 20 Jul 2014 20:06:50 -0600 (MDT) Cc: Andrew Berg , freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 02:06:55 -0000 On Sun, 20 Jul 2014, Doug Hardie wrote: > On 20 July 2014, at 17:54, Warren Block wrote: >> The desire to avoid that repetition is why there is a generic >> Subversion appendix in the Handbook. Still, we have a lot of >> repetition of Subversion instructions elsewhere. There's a section >> in the Handbook. There's another in the Committer's Guide. There's >> another in the FDP Primer. Hence my idea to factor all that out and >> make our own Subversion for FreeBSD book. My outline for it already >> has separate sections for end-user usage for ports, source, and docs. >> However, it is one of many projects on the list. > > I brought up pkg because both it and svn were introduced at about the > same time. Thus completely breaking the model we have used for > maintaining systems for over 10 years. Its been a bit difficult. Change is always difficult. Subversion is easier to use than CVS, at least. > On the documentation, the above appears fine. I would include > examples on how to upgrade OS to new version. That is just a matter of which directory is checked out. 10-stable: https://svn0.us-west.freebsd.org/base/stable/10 9-stable: https://svn0.us-west.freebsd.org/base/stable/9 10.0-release+patches: https://svn0.us-west.freebsd.org/base/releng/10.0 9.3-release+patches: https://svn0.us-west.freebsd.org/base/releng/9.3 Of course, /usr/src should again be cleared before checking out a different version. > I don't think I would remember the commands I used earlier, especially > as I try to keep upgrades to once a year. System downtime is a real > hassle for my users. I would not recommend putting that in a separate > document though. The handbook should have it all. I have never heard > of the Committer's Guide or the FDP Primer. I've never seen a > reference to them before and sure would not have check there. The Handbook and other books would reference it with text linked to the appropriate sections in the Subversion book. This would allow eliminating conflicting information and redundancy while at the same time giving more detail. We already do this with other references.