From owner-freebsd-doc Tue Jan 30 16:10:29 2001 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id ECFBC37B69C for ; Tue, 30 Jan 2001 16:10:06 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f0V0A6a65720; Tue, 30 Jan 2001 16:10:06 -0800 (PST) (envelope-from gnats) Date: Tue, 30 Jan 2001 16:10:06 -0800 (PST) Message-Id: <200101310010.f0V0A6a65720@freefall.freebsd.org> To: freebsd-doc@freebsd.org Cc: From: Salvo Bartolotta Subject: Re: docs/24662: correct management of sources with cvsup(1): a draft version Reply-To: Salvo Bartolotta Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR docs/24662; it has been noted by GNATS. From: Salvo Bartolotta To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: docs/24662: correct management of sources with cvsup(1): a draft version Date: Wed, 31 Jan 2001 00:08:22 GMT >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 1/26/01, 11:52:10 PM, bartequi@inwind.it wrote regarding docs/24662: correct management of sources with cvsup(1): > >Number: 24662 > >Category: docs > >Synopsis: too many questions about source management bloat freebsd lists > A reference to J.Polstra's cvsup FAQ should be made and/or emphasized > in the existing documentation (handbook and/or cvsup(1) and/or FreeBSD= > FAQ); in this connection, explicit specific examples might be helpful.= > Also, cvsupchk should be mentioned as a useful tool for correct source= > management. ------------------ Suggestions: a first draft ------------------------ Q12, Q13, Q36-39 (and probably others) in the cvsup FAQ found at http://www.polstra.com should: 1) be **explicitly** linked. In the handbook, there IS a link to the site (which is the way I discovered the issue), but it is only bears indirect relation to the Qs; 2) and/or be included in the handbook; 3) and/or be reworded and included in the handbook. This material deals with the correct "first update" procedure (and the resons for it); OTOH, a tool such as cvsupchk is worth mentioning. This python script is found in /usr/ports/net/cvsup/work/cvsup-16.1/contrib/cvsupchk/cvsupchk, along with an explanatory README. Quoting from the README: README.cvsupchk --------------- cvsupchk is a python script that checks a CVSup maintained directory hierarchy against the corresponding CVSup checkouts file. It looks for a number of anomalies: missing checked out files, deleted files being present, extra RCS files, 'dead' directories being present and so on. --------------- After introducing the basics, we can now proceed to a few more interesting concrete examples. Switching one's sources from one tag to another. If one specifies tag=3DA in a supfile, cvsup will generate a checkouts file called "checkouts.cvs:A": e.g. if tag=3DRELENG_4, a checkouts file called checkouts.cvs:RELENG_4 is generated. When tracking FreeBSD src-all, if I wish to switch from tag=3DA to tag=3DB (AB does not make any difference), and if my checkouts file is, say, checkouts.cvs:A, the following steps need to be performed: 1) mv checkouts.cvs:A checkouts.cvs:B /* This provides the subsequent step with the appropriate checkouts file */ 2) write a supfile whose collection line reads: src-all tag=3DB 3) cvsup sources (ie src-all) using the supfile as per 2). Cvsup will look for a checkouts.cvs:B -- in that the target is B; thus, cvsup will make use of the information contained therein in order to correctly manage the sources. The benefits: a) the sources are dealt with correctly (no stale files, no disk space wasted); b) less load is placed on the server in that cvsup will operate in the most efficient way. Example I A=3DRELENG_4, B=3D. The period in "B=3D." means CURRENT. This is a rather typical update, from 4-STABLE to -CURRENT. Example II A=3D. B=3DRELENG_4. This is the reverse operation, from -CURRENT to 4-STABLE. Here I **only** consider the **cvsup phase**. In order to actually downgrade a **system**, a number of preliminary steps may be necessary (e.g. downgrade binutils, gcc, perl, etc.) before making buildworld ... Switching to the same release as of a different date. If one wishes to switch from "tag=3DA" to "tag=3DA" as of a different GM= T date (say, "date=3DD"), one will perform the following actions: 1) write a supfile whose collection line reads: src-all tag=3DA date=3DD 2) cvsup using the supfile as per 1) The fact that the date is < or > the date of the last update with tag=3D= A is immaterial. For example, in order to specify the date "August 27, 2000, 10:00:00 GMT" one will write the line: src-all tag=3DRELENG_4 date=3D2000.08.27.10.00.00 N.B. The format of the date is rigid. One has to specify all the components of a date: century (19 for the 19th or 20 for the 20th), year, month, day, hour, minutes, seconds -- as shown in the above example. For more information, please see cvsup(1). Whether or not a date is specified, the checkouts file will be called checkouts.cvs:A (eg checkouts.cvs:RELENG_4). As a result, no particular action is needed in order to revert to the previous state: one has to modify the date in the supfile, and csvup again. Updating the ports collection for the first time via cvsup. Since ports are tagged "." (ie -CURRENT), one can correctly "sync" them for the first time by adding the *date* keyword (cf cvsup(1) for the exact format): one should specify a date as close as possible to that of "shipping" of one's ports tree. After cvsup has correctly created the ports checkouts file, which is precisely the goal of this first special synch operation, the date field must be removed; all subsequent updates will be performed smoothly. ---------------------- End of Suggestions --------------------------- These examples should (hopefully) put people in a position to correctly update whatever collection the wish to. They should probably come after the general cvsup theory in the handbook. N.B. This is just a draft. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message