From otto@bartequi.ottodomain.org  Fri Jan 26 14:50:26 2001
Return-Path: <otto@bartequi.ottodomain.org>
Received: from bartequi.ottodomain.org (unknown [62.98.162.85])
	by hub.freebsd.org (Postfix) with ESMTP id 61CA537B699
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 26 Jan 2001 14:50:14 -0800 (PST)
Received: (from otto@localhost)
	by bartequi.ottodomain.org (8.11.1/8.11.1) id f0QMqAq00482;
	Fri, 26 Jan 2001 23:52:10 +0100 (CET)
	(envelope-from otto)
Message-Id: <200101262252.f0QMqAq00482@bartequi.ottodomain.org>
Date: Fri, 26 Jan 2001 23:52:10 +0100 (CET)
From: bartequi@inwind.it
Reply-To: bartequi@inwind.it
To: FreeBSD-gnats-submit@freebsd.org
Subject: correct management of sources with cvsup(1)
X-Send-Pr-Version: 3.2

>Number:         24662
>Category:       docs
>Synopsis:       too many questions about source management bloat freebsd lists
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jan 26 15:00:01 PST 2001
>Closed-Date:    Mon Oct 8 04:15:44 PDT 2001
>Last-Modified:  Mon Oct 08 04:16:18 PDT 2001
>Originator:     Salvo Bartolotta
>Release:        FreeBSD 4.2-STABLE i386
>Organization:
>Environment:

	

>Description:
Stale files may cause users a number of problems. The role and 
importance of cvsup's checkouts file(s) seems to be widely ignored, as 
well the existence of such utilities as cvsupchk. 


>How-To-Repeat:

	
Read -questions for a while... 

>Fix:

	
Moooo! I have written far too many times to freebsd lists on the subject :-)

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. 



I wrote a few public letters, as well as several private ones covering 
the following topics:

--  correctly updating one's sources via cvsup for the first time;
--  switching one's sources from tag A to tag B;
--  correctly updating one's ports tree for the first time. 

If anybody is interested in this material, I will be glad to submit it 
for revision -- as plain text, for the time being.

>Release-Note:
>Audit-Trail:

From: Nik Clayton <nik@freebsd.org>
To: bartequi@inwind.it
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/24662: correct management of sources with cvsup(1)
Date: Fri, 26 Jan 2001 23:37:26 +0000

 On Fri, Jan 26, 2001 at 11:52:10PM +0100, bartequi@inwind.it wrote:
 > If anybody is interested in this material, I will be glad to submit it 
 > for revision -- as plain text, for the time being.
 
 Please do.
 
 N
 -- 
 Internet connection, $19.95 a month.  Computer, $799.95.  Modem, $149.95.
 Telephone line, $24.95 a month.  Software, free.  USENET transmission,
 hundreds if not thousands of dollars.  Thinking before posting, priceless.
 Somethings in life you can't buy.  For everything else, there's MasterCard.
   -- Graham Reed, in the Scary Devil Monastery
 

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. :-)
 
 
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: murray 
State-Changed-When: Sun Sep 2 04:35:18 PDT 2001 
State-Changed-Why:  
I've followed up with the originator. 


http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24662 

From: Murray Stokely <murray.stokely@windriver.com>
To: freebsd-gnats-submit@FreeBSD.org, bartequi@inwind.it
Cc:  
Subject: Re: docs/24662: too many questions about source management bloat freebsd lists
Date: Sun, 2 Sep 2001 04:40:43 -0700

   This looks pretty good but I'm not sure that all of this technical
 information about CVSup is really required.  Do you really get that
 many questions about them on the lists?  Is it really necessary to
 perform all these steps?  Where do you want this text to go?  Into the
 CVSup section of the Obtaining FreeBSD appendix?  If so, can you
 please tell us exactly what you want added where?  If you are able,
 submitting a diff to the SGML would be easiest.
 
   Thanks for your work on this!
 
        - Murray

From: Salvo Bartolotta <bartequi@neomedia.it>
To: Murray Stokely <murray.stokely@windriver.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: docs/24662: too many questions about source management bloat freebsd lists
Date: Mon, 03 Sep 2001 21:16:01 +0200 (CEST)

 >   This looks pretty good but I'm not sure that all of this technical
 > information about CVSup is really required.  Do you really get that
 > many questions about them on the lists?
 
 
 
 
 Well, when I wrote the PR, I had answered a few such questions. :-)
 
 From what I have been reading over the past few months on the lists I am 
 subcribed to, in particular on -questions & -stable, I don't think the 
 situation has changed much. Even if the number of question seems to be smaller.
 
 Recently, I answered a message on (IIRC) -questions, suggesting the two-step 
 cvsup procedure to correctly create the checkouts file for the src tree. 
 Somebody thought I was a little green man from Mars, until Kris Kennaway made 
 it clear I was right. :-) AAAARGH! Few people appear to read the archives... 
 
 I seem to understand that most problems concern the ports tree rather than the 
 main (/usr/src) tree.
 
 
 
 
 >  Is it really necessary to
 > perform all these steps?
 
 
 
 
 One has the choice: either use cvsupchk or synching "correctly". But even 
 then, I'd like to have cvsupchk handy -- one never knows.
 
 <Using cvsupchk>
 
 1) IIRC (past messages on -questions), the cvsupchk script used to require a 
 CVS repository in order to work, which no longer holds. A quick try confirms 
 this.
 
 207 8:28pm /usr/ports/net/cvsup/work/cvsup-16.1/contrib/cvsupchk >====> env | 
 grep -i cvs
 PWD=/usr/ports/net/cvsup/work/cvsup-16.1/contrib/cvsupchk
 # BTW, my CVS repository lives in /myjunk/home/ncvs. 
 
 
 209 8:29pm /usr/ports/net/cvsup/work/cvsup-16.1/contrib/cvsupchk >====> 
 ./cvsupchk -d /usr -c /usr/sup/src-all/checkouts.cvs:RELENG_4 | more
 EXTRA: /usr/src/release/sysinstall/anonFTP.o
 EXTRA: /usr/src/release/sysinstall/cdrom.o
 
 <snip>
 
 It goes without saying that a user should perform a "make extract" in 
 /usr/ports/net/cvsup to get the cvsupchk python script.
 
 </Using cvsupchk>
 
 
 <Correct synchronization>
 
 In my text draft, I discussed three main uses: switching a source tree from 
 tag A to B; moving it to a different date within the same tag; updating for 
 the first time a source tree having tag=. (such as the ports tree).
 
 These are the most important cases, I think; these problems might even bite an 
 experienced user. As to the position within the framework of the handbook, the 
 material (or part thereof^Wof it :-) should probably be placed in Appendix A 
 (Obtaining FreeBSD), eg in an "Advanced Use", "Advanced/Subtle Points", or 
 "Caveats" section.
 
 More on this in the next few days.
 
 -- Salvo

From: Salvo Bartolotta <bartequi@neomedia.it>
To: Murray Stokely <murray.stokely@windriver.com>
Cc: freebsd-gnats-submit@FreeBSD.org, cvsupbugs@polstra.com
Subject: Re: docs/24662: too many questions about source management bloat freebsd lists
Date: Sat, 08 Sep 2001 03:30:17 +0200 (CEST)

 This message is in MIME format.
 
 ---MOQ999912617bf28d22212d6ba57727d5d15660290b8
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 8bit
 
 Here is a patch, as promised.
 
 I exchanged a couple of e-mail messages with John Polstra on this subject 
 a few months ago; I am sending him the draft so that he may also be able to 
 spot any bugs and give suggestions.
 
 -- Salvo
 
 ---MOQ999912617bf28d22212d6ba57727d5d15660290b8
 Content-Type: text/plain; name="patch"; charset=ISO-8859-1
 Content-Transfer-Encoding: 8bit
 Content-Disposition: inline; filename="patch"
 
 
 ===================================================================
 RCS file: /myjunk/home/ncvs/doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml,v
 retrieving revision 1.153
 diff -u -r1.153 chapter.sgml
 --- chapter.sgml	2001/09/05 00:29:19	1.153
 +++ chapter.sgml	2001/09/08 00:22:40
 @@ -3910,6 +3910,213 @@
        </varlistentry>
      </variablelist>
    </sect2>
 +
 +  <sect2>
 +    <sect2info>
 +      <authorgroup>
 +        <author>
 +          <firstname>Salvo</firstname>
 +            <surname>Bartolotta</surname>
 +           <contrib>Contributed by </contrib>
 +         </author>
 +       </authorgroup>
 +    </sect2info>
 +
 +  <title>Advanced Points</title>
 +
 +    <sect3>
 +      <title>Introduction</title>
 +
 +	<para>If you have visited <ulink url="http://www.polstra.com">John Polstra's site</ulink>
 +	  and read
 +	  <ulink url="http://www.polstra.com/projects/freeware/CVSup/faq.html">his FAQ</ulink>,
 +	  you may probably have noticed Question 12 & 13.</para> 
 +
 +	<para>When updating any collection of sources (eg <filename>/usr/ports</filename>), 
 +	  &man.cvsup.1; makes use of the related checkouts file in order to
 +	  perform the updating process in the most efficient and correct way.
 +	  In this example (<filename>/usr/ports</filename>), the related checkouts
 +	  file is <filename>/usr/sup/ports-all/checkouts.cvs:.</filename> if
 +	  your base is <filename>/usr</filename>.</para>
 +
 +	<para>A checkouts file contains information on the current status of your
 +	  sources -- in a way, a sort of "photograph". This significant information
 +	  enables cvsup to retrieve updates most effectively. Further, and maybe
 +	  more important, it enables cvsup to correctly manage your sources by
 +	  locally deleting any files no longer present in the repository, thus
 +	  leaving no stale files on your system. In fact, without a checkouts file,
 +	  cvsup would NOT know which files your collection was composed of (cf
 +	  &man.cvsup.1; and the fallback method for details); as a result, it
 +	  could NOT delete on your system those files no longer present in the
 +	  repository. These files would remain on your system (stale files), and
 +	  might cause you subtle build failures or other trouble. For example,
 +	  this problem is likely to occur if you first update your ports 
 +	  collection several weeks after you have got(ten) your installation
 +	  CDs.</para> 
 + 
 +	<para>It is therefore recommended that you adopt the two-step procedure
 +	  outlined in the Cvsup FAQ (cf Q12, Q13); later, you will be given
 +	  interesting and instructive concrete examples.</para> 
 +    </sect3>
 +    <sect3>
 +      <title>An useful python script: cvsupchk</title>
 +
 +        <para>Alternatively, in order to examine your sources for inconsistencies,
 +	  you may wish to utilize the cvsupchk python script; which script is
 +	  currently found in <filename>/usr/ports/net/cvsup/work/cvsup-16.1/contrib/cvsupchk</filename>,
 +	  together with a nice <filename>README</filename>. Prerequisites:</para> 
 +
 +	  <orderedlist>
 +	    <listitem>
 +	      <para><literal>/usr/ports/net/cvsup</literal> &prompt.root; <userinput> make extract</userinput></para>
 +	    </listitem>
 +
 +	    <listitem>
 +	      <para>python (also found in the ports collection :-))</para>
 +	    </listitem>
 +
 +	    <listitem>
 +	      <para>a checkouts file for your collection of sources.</para> 
 +	    </listitem> 
 +	  </orderedlist>
 +
 +        <para>If you are updating your sources for the very first time, of course
 +	  you do not have a checkouts file. After installing python and updating
 +	  your sources (eg <filename>/usr/ports</filename>), you can check them
 +	  thus:</para>
 +
 +	  <screen>&prompt.user; <filename>/path/to/</filename><userinput>cvsupchk -d /usr -c /usr/sup/ports-all/checkouts.cvs:. | more</userinput></screen>
 +
 +	<para>If you want to check your RELENG_4 sources:</para> 
 +
 +	  <screen>&prompt.user; <filename>/path/to/</filename><userinput>cvsupchk -d /usr -c /usr/sup/src-all/checkouts.cvs:RELENG_4 | more</userinput></screen>
 +
 +	<para>In each case, cvsupchk will inspect your sources for inconsistencies
 +	 by utilizing the information contained in the related checkouts file.
 +	 Such anomalies as deleted files being present (aka stale files), missing
 +	 checked out files, extra RCS files, and dead directories, will be
 +	 printed to standard output.</para>
 +
 +	<para>In the next section, we will provide important, typical examples of 
 +	  source updating; which examples will show you the role of checkouts 
 +	  files and the dangers of negligent source management.</para>
 +    </sect3> 
 +
 +    <sect3> 
 +      <title>Examples of more advanced source management</title>
 +
 +	<sect4>
 +	  <title>How to safely change tags when updating <literal>src-all.</literal></title>
 +
 +	  <para>If you specify eg tag=A in your supfile, cvsup will create a
 +	    checkouts file called <filename>checkouts.cvs:A</filename>: for
 +	    instance, if tag=RELENG_4, a checkouts file called 
 +	    <filename>checkouts.cvs:RELENG_4</filename> is generated. This file
 +	    will be used to retrieve and/or store identification information
 +	    on your 4-STABLE sources.</para>
 +  
 +	  <para>When tracking <literal>src-all</literal>, if you wish to pass from tag=A to tag=B
 +	    (A less/greater than B not making any difference) and if your 
 +	    checkouts file is <filename>checkouts.cvs:A</filename>, the
 +	    following actions should be performed:</para>
 +
 +	     <orderedlist>
 +	       <listitem>
 +		 <para>&prompt.root; <userinput>mv checkouts.cvs:A checkouts.cvs:B</userinput>
 +		   (This provides the subsequent step with the appropriate
 +		   checkouts file)</para>
 +	       </listitem>
 +
 +	       <listitem>
 +		 <para>write a supfile whose collection line reads:</para> 
 +		   <programlisting>src-all tag=B</programlisting>
 +	       </listitem>
 +
 +	       <listitem>
 +		 <para>cvsup your sources using the new supfile.</para>
 +	       </listitem>
 +	     </orderedlist>
 +
 +	  <para>Cvsup will look for <filename>checkouts.cvs:B</filename> -- in
 +	    that the target is B; that is, cvsup will make use of the information
 +	    contained therein to correctly manage your sources.</para>
 +
 +	  <para>The benefits:</para>
 +
 +	    <itemizedlist>
 +	       <listitem>
 +		 <para>the sources are dealt with correctly (in particular, no
 +		 stale files)</para>
 +	       </listitem>
 +
 +	       <listitem>
 +		 <para>less load is placed on the server, in that cvsup operates
 +		   in the most efficient way.</para>
 +	       </listitem>	 
 +	    </itemizedlist>
 +
 +	  <para>For example, A=RELENG_4, B=.  The period in "B=." means -CURRENT.
 +	    This is a rather typical update, from 4-STABLE to -CURRENT. While it
 +	    is straightforward to "downgrade" your sources (eg from -CURRENT to
 +	    -STABLE), downgrading a system is quite another matter. You are
 +	    STRONGLY advised not to attempt such an operation, unless you know
 +	    exactly what you are doing.</para> 
 +	</sect4>
 +
 +	<sect4>
 +	  <title>Updating to the same tag as of a different date</title>
 +
 +	  <para>If you wish to switch from "tag=A" to "tag=A" as of a different
 +        GMT date (say, "date=D"), you will execute the following:</para>
 +
 +	    <orderedlist> 
 +	      <listitem>
 +		<para>write a supfile whose collection line reads:</para> 
 +		  <programlisting>src-all tag=A date=D</programlisting>
 +	      </listitem>
 +
 +	      <listitem>
 +		<para>update your sources using the new supfile</para>
 +	      </listitem>
 +	    </orderedlist>
 +
 +	  <para>Whether the new date precedes that of the last synch operation
 +	    with tag=A or not, it is immaterial. For example, in order to
 +	    specify the date "August 27, 2000, 10:00:00 GMT" you write the
 +	    line:</para>
 +
 +	  <programlisting>src-all tag=RELENG_4 date=2000.08.27.10.00.00</programlisting>
 +
 +	  <para>N.B. The format of a date is rigid. You have to specify all
 +	    the components of the 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 &man.cvsup.1;.</para>
 +
 +	  <para>Whether or not a date is specified, the checkouts file is called
 +	    <filename>checkouts.cvs:A</filename> (eg
 +	    <filename>checkouts.cvs:RELENG_4</filename>). As a result, no
 +	    particular action is needed in order to revert to the previous state:
 +	    you have to modify the date in the supfile, and csvup again.</para>
 +	</sect4>
 +
 +	<sect4>
 +	  <title>Updating your ports collection for the first time</title>
 +
 +	  <para>Since ports are tagged "." (ie -CURRENT), you can correctly "sync"
 +	    them for the first time by adding the date keyword (cf &man.cvsup.1; 
 +	    for the exact format): you should specify a date as close as possible
 +	    to that of "shipping" of your 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 carried out smoothly.</para>
 +
 +	  <para>If you have been reading the apparently nit-picking remarks in
 +	    these sections, you will probably have recognized the potential for 
 +	    scr^Wtrouble in a source updating process. A number of people have
 +	    actually run into problems. You have been warned. :-)</para> 
 +	</sect4>
 +     </sect3>
 +  </sect2> 
    </sect1>
      
    <sect1 id="mirrors-afs">
 
 ---MOQ999912617bf28d22212d6ba57727d5d15660290b8--

From: Salvo Bartolotta <bartequi@neomedia.it>
To: Murray Stokely <murray.stokely@windriver.com>
Cc: freebsd-gnats-submit@FreeBSD.org, cvsup-bugs@polstra.com
Subject: Re: docs/24662: too many questions about source management bloat freebsd lists
Date: Sun, 09 Sep 2001 14:06:40 +0200 (CEST)

 This message is in MIME format.
 
 ---MOQ10000372004d78910cea25daf24ae9d4d177f99898
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 8bit
 
 Here is another patch, namely a patch.delta. It contains few minor corrections.
 
 Applying patch.delta to the previous patch (renamed patch.old) will produce 
 the final patch and... save bandwidth. :-)
 
 -- Salvo
 ---MOQ10000372004d78910cea25daf24ae9d4d177f99898
 Content-Type: text/plain; name="patch.delta"; charset=ISO-8859-1
 Content-Transfer-Encoding: 8bit
 Content-Disposition: inline; filename="patch.delta"
 
 
 *** patch.old	Sat Sep  8 02:23:23 2001
 --- patch	Sun Sep  9 13:30:44 2001
 ***************
 *** 3,10 ****
   retrieving revision 1.153
   diff -u -r1.153 chapter.sgml
   --- chapter.sgml	2001/09/05 00:29:19	1.153
 ! +++ chapter.sgml	2001/09/08 00:22:40
 ! @@ -3910,6 +3910,213 @@
          </varlistentry>
        </variablelist>
      </sect2>
 --- 3,10 ----
   retrieving revision 1.153
   diff -u -r1.153 chapter.sgml
   --- chapter.sgml	2001/09/05 00:29:19	1.153
 ! +++ chapter.sgml	2001/09/09 11:28:45
 ! @@ -3910,6 +3910,214 @@
          </varlistentry>
        </variablelist>
      </sect2>
 ***************
 *** 53,63 ****
   +	  CDs.</para> 
   + 
   +	<para>It is therefore recommended that you adopt the two-step procedure
 ! +	  outlined in the Cvsup FAQ (cf Q12, Q13); later, you will be given
 ! +	  interesting and instructive concrete examples.</para> 
   +    </sect3>
   +    <sect3>
 ! +      <title>An useful python script: cvsupchk</title>
   +
   +        <para>Alternatively, in order to examine your sources for inconsistencies,
   +	  you may wish to utilize the cvsupchk python script; which script is
 --- 53,63 ----
   +	  CDs.</para> 
   + 
   +	<para>It is therefore recommended that you adopt the two-step procedure
 ! +	  outlined in the Cvsup FAQ (cf Q12, Q13); in subsequent sections, you
 ! +	  will be given interesting and instructive concrete examples.</para> 
   +    </sect3>
   +    <sect3>
 ! +      <title>A useful python script: cvsupchk</title>
   +
   +        <para>Alternatively, in order to examine your sources for inconsistencies,
   +	  you may wish to utilize the cvsupchk python script; which script is
 ***************
 *** 186,194 ****
   +	  <programlisting>src-all tag=RELENG_4 date=2000.08.27.10.00.00</programlisting>
   +
   +	  <para>N.B. The format of a date is rigid. You have to specify all
 ! +	    the components of the 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 &man.cvsup.1;.</para>
   +
   +	  <para>Whether or not a date is specified, the checkouts file is called
   +	    <filename>checkouts.cvs:A</filename> (eg
 --- 186,195 ----
   +	  <programlisting>src-all tag=RELENG_4 date=2000.08.27.10.00.00</programlisting>
   +
   +	  <para>N.B. The format of a date is rigid. You have to specify all
 ! +	    the components of the date: century (20, ie the 20th century, must
 ! +	    be supplied whereas 19, the past century, can be omitted), year,
 ! +	    month, day, hour, minutes, seconds -- as shown in the above example.
 ! +	    For more information, please see &man.cvsup.1;.</para>
   +
   +	  <para>Whether or not a date is specified, the checkouts file is called
   +	    <filename>checkouts.cvs:A</filename> (eg
 
 ---MOQ10000372004d78910cea25daf24ae9d4d177f99898--
State-Changed-From-To: feedback->suspended 
State-Changed-By: murray 
State-Changed-When: Sun Oct 7 20:12:43 PDT 2001 
State-Changed-Why:  
I don't believe this material belongs in an appendix to the Handbook. 
This advanced information might be valuable for a tutorial or article 
on FreeBSD.org or on John's CVSup site but I don't think it belongs 
here.  I will close this PR this week unless someone feels strongly 
about it. 


http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24662 

From: Murray Stokely <murray@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, bartequi@inwind.it
Cc:  
Subject: Re: docs/24662: too many questions about source management bloat freebsd lists
Date: Sun, 7 Oct 2001 20:11:32 -0700

 patch.delta doesn't apply cleanly to the original patch for me, but I
 can put them together manually.  I don't really like this addition.
 
 This is an appendix that describes methods for obtaining FreeBSD.
 This section on CVSup already contains a subsection "For more
 information" that includes a link to the CVSup FAQ, the CVSup home
 page, mailing lists for support of CVSup, etc.  This appendix is not a
 source of documentation for CVSup, and this addition clutters the
 concise information that is already there.  I believe that there is
 more than enough detail already (almost too much in fact) about
 creating a sup file from scratch, etc.
 
 You've written some good material, and if you would like to add a
 separate article about advanced CVSup usage, then that might be
 valuable, but I really don't think all of this information belongs in
 an appendix to the Handbook.
 
 I think this PR should be closed.
 
   Thanks,
 
   - Murray
State-Changed-From-To: suspended->closed 
State-Changed-By: murray 
State-Changed-When: Mon Oct 8 04:15:44 PDT 2001 
State-Changed-Why:  
The submitter is going to rework this material into a tutorial or 
article for Daemonnews. 


http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24662 
>Unformatted:
