Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Jan 2001 16:10:06 -0800 (PST)
From:      Salvo Bartolotta <bartequi@inwind.it>
To:        freebsd-doc@freebsd.org
Subject:   Re: docs/24662: correct management of sources with cvsup(1): a draft version
Message-ID:  <200101310010.f0V0A6a65720@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/24662; it has been noted by GNATS.

From: Salvo Bartolotta <bartequi@inwind.it>
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
 
 <snip>
 
 > 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 ------------------------
 
 <NOTE>
 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.
 </NOTE>
 
 
 
 <SUGGESTION I>
 Switching one's sources from one tag to another.
 
 <REMARK>
 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.
 </REMARK>
 
 When tracking FreeBSD src-all, if I wish to switch from tag=3DA to
 tag=3DB (A<B or A>B 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.
 
 <WARNING>
 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
 ...
 </WARNING>
 </SUGGESTION I>
 
 
 <SUGGESTION II>
 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).
 
 
 <REMARK>
 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.
 </REMARK>
 </SUGGESTION II>
 
 
 <SUGGESTION III>
 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.
 </SUGGESTION III>
 
 ---------------------- 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101310010.f0V0A6a65720>