[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
www/software/cvs .bash_profile .symlinks cvs.ht...
|
From: |
karl |
|
Subject: |
www/software/cvs .bash_profile .symlinks cvs.ht... |
|
Date: |
Mon, 11 Feb 2013 22:17:12 +0000 |
CVSROOT: /web/www
Module name: www
Changes by: karl <karl> 13/02/11 22:17:11
Removed files:
software/cvs : .bash_profile .symlinks cvs.html
software/cvs/manual: .symlinks cvs.html
software/cvs/manual/dvi: cvs.dvi.gz
software/cvs/manual/html_chapter: cvs_1.html cvs_10.html
cvs_11.html cvs_12.html
cvs_13.html cvs_14.html
cvs_15.html cvs_16.html
cvs_17.html cvs_18.html
cvs_19.html cvs_2.html
cvs_20.html cvs_21.html
cvs_22.html cvs_23.html
cvs_24.html cvs_25.html
cvs_3.html cvs_4.html
cvs_5.html cvs_6.html
cvs_7.html cvs_8.html
cvs_9.html cvs_toc.html
software/cvs/manual/html_mono: cvs.html
software/cvs/manual/html_node: cvs_1.html cvs_10.html
cvs_100.html cvs_101.html
cvs_102.html cvs_103.html
cvs_104.html cvs_105.html
cvs_106.html cvs_107.html
cvs_108.html cvs_109.html
cvs_11.html cvs_110.html
cvs_111.html cvs_112.html
cvs_113.html cvs_114.html
cvs_115.html cvs_116.html
cvs_117.html cvs_118.html
cvs_119.html cvs_12.html
cvs_120.html cvs_121.html
cvs_122.html cvs_123.html
cvs_124.html cvs_125.html
cvs_126.html cvs_127.html
cvs_128.html cvs_129.html
cvs_13.html cvs_130.html
cvs_131.html cvs_132.html
cvs_133.html cvs_134.html
cvs_135.html cvs_136.html
cvs_137.html cvs_138.html
cvs_139.html cvs_14.html
cvs_140.html cvs_141.html
cvs_142.html cvs_143.html
cvs_144.html cvs_145.html
cvs_146.html cvs_147.html
cvs_148.html cvs_15.html
cvs_16.html cvs_17.html
cvs_18.html cvs_19.html
cvs_2.html cvs_20.html
cvs_21.html cvs_22.html
cvs_23.html cvs_24.html
cvs_25.html cvs_26.html
cvs_27.html cvs_28.html
cvs_29.html cvs_3.html
cvs_30.html cvs_31.html
cvs_32.html cvs_33.html
cvs_34.html cvs_35.html
cvs_36.html cvs_37.html
cvs_38.html cvs_39.html
cvs_4.html cvs_40.html
cvs_41.html cvs_42.html
cvs_43.html cvs_44.html
cvs_45.html cvs_46.html
cvs_47.html cvs_48.html
cvs_49.html cvs_5.html
cvs_50.html cvs_51.html
cvs_52.html cvs_53.html
cvs_54.html cvs_55.html
cvs_56.html cvs_57.html
cvs_58.html cvs_59.html
cvs_6.html cvs_60.html
cvs_61.html cvs_62.html
cvs_63.html cvs_64.html
cvs_65.html cvs_66.html
cvs_67.html cvs_68.html
cvs_69.html cvs_7.html
cvs_70.html cvs_71.html
cvs_72.html cvs_73.html
cvs_74.html cvs_75.html
cvs_76.html cvs_77.html
cvs_78.html cvs_79.html
cvs_8.html cvs_80.html
cvs_81.html cvs_82.html
cvs_83.html cvs_84.html
cvs_85.html cvs_86.html
cvs_87.html cvs_88.html
cvs_89.html cvs_9.html
cvs_90.html cvs_91.html
cvs_92.html cvs_93.html
cvs_94.html cvs_95.html
cvs_96.html cvs_97.html
cvs_98.html cvs_99.html
cvs_toc.html
software/cvs/manual/info: cvs-infonfo.tar.gz
software/cvs/manual/ps: cvs.ps.gz
software/cvs/manual/texi: cvs.texinfo.tar.gz
software/cvs/manual/text: cvs.txt
Log message:
rm cvs here, since there is some super-redirect in place to nongnu/cvs
CVSWeb URLs:
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/.bash_profile?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/.symlinks?cvsroot=www&r1=1.2&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/cvs.html?cvsroot=www&r1=1.6&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/.symlinks?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/cvs.html?cvsroot=www&r1=1.3&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/dvi/cvs.dvi.gz?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_1.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_10.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_11.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_12.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_13.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_14.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_15.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_16.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_17.html?cvsroot=www&r1=1.2&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_18.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_19.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_2.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_20.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_21.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_22.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_23.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_24.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_25.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_3.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_4.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_5.html?cvsroot=www&r1=1.2&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_6.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_7.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_8.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_9.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_chapter/cvs_toc.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_mono/cvs.html?cvsroot=www&r1=1.3&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_1.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_10.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_100.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_101.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_102.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_103.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_104.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_105.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_106.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_107.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_108.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_109.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_11.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_110.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_111.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_112.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_113.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_114.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_115.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_116.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_117.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_118.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_119.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_12.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_120.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_121.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_122.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_123.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_124.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_125.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_126.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_127.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_128.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_129.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_13.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_130.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_131.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_132.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_133.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_134.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_135.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_136.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_137.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_138.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_139.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_14.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_140.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_141.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_142.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_143.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_144.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_145.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_146.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_147.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_148.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_15.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_16.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_17.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_18.html?cvsroot=www&r1=1.2&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_19.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_2.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_20.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_21.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_22.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_23.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_24.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_25.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_26.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_27.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_28.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_29.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_3.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_30.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_31.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_32.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_33.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_34.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_35.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_36.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_37.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_38.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_39.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_4.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_40.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_41.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_42.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_43.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_44.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_45.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_46.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_47.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_48.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_49.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_5.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_50.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_51.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_52.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_53.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_54.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_55.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_56.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_57.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_58.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_59.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_6.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_60.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_61.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_62.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_63.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_64.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_65.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_66.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_67.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_68.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_69.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_7.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_70.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_71.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_72.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_73.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_74.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_75.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_76.html?cvsroot=www&r1=1.2&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_77.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_78.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_79.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_8.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_80.html?cvsroot=www&r1=1.2&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_81.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_82.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_83.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_84.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_85.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_86.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_87.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_88.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_89.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_9.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_90.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_91.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_92.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_93.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_94.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_95.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_96.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_97.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_98.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_99.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/html_node/cvs_toc.html?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/info/cvs-infonfo.tar.gz?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/ps/cvs.ps.gz?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/texi/cvs.texinfo.tar.gz?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/software/cvs/manual/text/cvs.txt?cvsroot=www&r1=1.2&r2=0
Patches:
Index: .bash_profile
===================================================================
RCS file: .bash_profile
diff -N .bash_profile
--- .bash_profile 25 Feb 2001 22:29:02 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,4 +0,0 @@
-# ~/.bash_profile: executed by bash(1) for login shells.
-# $Id: .bash_profile,v 1.1 2001/02/25 22:29:02 webcvs Exp $
-
-umask 000
Index: .symlinks
===================================================================
RCS file: .symlinks
diff -N .symlinks
--- .symlinks 7 Feb 2008 11:17:18 -0000 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1 +0,0 @@
-cvs.html index.html
Index: cvs.html
===================================================================
RCS file: cvs.html
diff -N cvs.html
--- cvs.html 24 Oct 2011 19:36:03 -0000 1.6
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,126 +0,0 @@
-<html><head>
-<title>CVS</title>
-</head><body>
-
-<h2>CVS</h2>
-
-<p>(CVS is not a GNU package, but we host this page about it anyway, for
-your hacking pleasure.)
-
-<!-- Contributing author: Frank Warmerdam, address@hidden -->
-
-<H4><A HREF="#TOCintroduction" NAME="introduction">Introduction to CVS</A></H4>
-<P>
-CVS is a version control system, and important component of
-Source Configuration Management (SCM).
-Using it, you can record the history of sources files, and documents.
-It fills a similar role to the free software
-<A HREF="/software/rcs/rcs.html">RCS</A>,
-<A HREF="http://www.xcf.berkeley.edu/~jmacd/prcs.html";>PRCS</A>,
-and <A HREF="http://www.canb.auug.org.au/~millerp/aegis.html";>Aegis</A>
-packages.
-
-<P>
-The <A HREF="http://www.cvshome.org/";>CVS Information
-Page</A> contains detailed, and current information on CVS.
-
-<P>
-The online manual is also available at
-<A HREF="/software/cvs/manual/">www.gnu.org/software/cvs/manual/</A>
-
-<P>
-CVS is a production quality system in wide use around the world, including
-many free software projects.<P>
-
-<P>
-While CVS stores individual file history in the same format as RCS, it
-offers the following significant advantages over RCS:
-
-<UL>
-
-<LI>
-
-It can run scripts which you can supply to log CVS operations or enforce
-site-specific policies.
-
-<LI>
-
-<STRONG>Client/server CVS</STRONG> enables developers scattered by geography
or slow
-modems to function as a single team. The version history is stored on
-a single central server and the client machines have a copy of all the
-files that the developers are working on. Therefore, the network
-between the client and the server must be up to perform CVS operations
-(such as checkins or updates) but need not be up to edit or manipulate the
-current versions of the files. Clients can perform all the same
-operations which
-are available locally.
-
-<LI>
-
-In cases where several developers or teams want to each maintain
-their own version of the files, because of geography and/or policy,
-CVS's <STRONG>vendor branches</STRONG> can import a version from another team
-(even if they don't use CVS), and then CVS can merge the changes from
-the vendor branch with the latest files if that is what is desired.
-
-<LI>
-
-<STRONG>Unreserved checkouts</STRONG>, allowing more than one developer to
work on
-the same files at the same time.
-
-<LI>
-
-CVS provides a flexible <STRONG>modules database</STRONG> that provides a
symbolic
-mapping of names to components of a larger software distribution. It
-applies names to collections of directories and files. A single
-command can manipulate the entire collection.
-
-<LI>
-CVS servers run on most Unix variants, and clients for Windows and VMS
-are also available. CVS will also operate in non-client/server mode on
-Windows 95/NT.
-
-</UL>
-
-<H4><A HREF="#TOCdownloading" NAME="downloading">Downloading CVS</A></H4>
-<P>
-
-CVS can be found on in the subdirectory <CODE>/non-gnu/cvs/</CODE> on your
favorite
-<A HREF="/prep/ftp.html">GNU mirror</A>. For other ways to
-obtain CVS, please read
-<A HREF="/software/software.html#HowToGetSoftware">How to get GNU Software</A>
-
-
-<!-- beginning of final boilerplate ------------------------------------------>
-
-<HR>
-
-Return to <A HREF="/home.html">GNU's home page</A>.
-
-<P>
-Please send FSF & GNU inquiries & questions to
-
-<A HREF="mailto:address@hidden";><EM>address@hidden</EM></A>.
-There are also <A HREF="/home.html#ContactInfo">other ways to contact</A> the
FSF.
-
-<P>
-Please send comments on these web pages to
-<A HREF="mailto:address@hidden";><EM>address@hidden</EM></A>,
-send other questions to
-<A HREF="mailto:address@hidden";><EM>address@hidden</EM></A>.
-
-<P>
-Copyright (C) 1998 Free Software Foundation, Inc.,
-59 Temple Place - Suite 330, Boston, MA 02111, USA
-
-<P>
-Verbatim copying and distribution of this entire article is
-permitted in any medium, provided this notice is preserved.
-<P>
-Updated:
-<!-- hhmts start -->
-22 Jul 2000 prashant
-<!-- hhmts end -->
-<HR>
-</BODY>
-</HTML>
Index: manual/.symlinks
===================================================================
RCS file: manual/.symlinks
diff -N manual/.symlinks
--- manual/.symlinks 7 Nov 2003 20:56:38 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1 +0,0 @@
-cvs.html index.html
Index: manual/cvs.html
===================================================================
RCS file: manual/cvs.html
diff -N manual/cvs.html
--- manual/cvs.html 24 Oct 2011 19:36:11 -0000 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,74 +0,0 @@
-<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
-<HTML>
-<HEAD>
-<TITLE>CVS--Concurrent Versions System - Table of Contents - GNU Project -
Free Software Foundation (FSF)</TITLE>
-<LINK REV="made" HREF="mailto:address@hidden";>
-</HEAD>
-<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000"
VLINK="#9900DD">
-<H1>CVS--Concurrent Versions System - Table of Contents</H1>
-<ADDRESS>Free Software Foundation</ADDRESS>
-<ADDRESS>last updated November 07, 1998</ADDRESS>
-<P>
-<A HREF="/graphics/gnu-head-sm.jpg"><IMG SRC="/graphics/gnu-head-sm.jpg"
- ALT=" [image of the Head of a GNU] "
- WIDTH="129" HEIGHT="122"> (jpeg 7k)</A>
-<A HREF="/graphics/gnu-head.jpg">(jpeg 21k)</A>
-
-<P>
-<P>
-<P><HR><P>
-<P>
-This manual is available in the following formats:
-<P>
-<UL>
- <LI>formatted in <A HREF="html_mono/cvs.html">HTML
- (300K characters)</A> entirely on one web page.
- <P>
- <LI> formatted in <a href="html_chapter/cvs_toc.html">HTML</a>
- with one web page per chapter.
- <p>
- <LI> formatted in <a href="html_node/cvs_toc.html">HTML</a>
- with one web page per node.
- <p>
- <LI>formatted as an
- <A HREF="info/cvs-infonfo.tar.gz">Info document (79K characters
- gzipped tar file)</A>.
- <P>
- <LI>formatted as
- <A HREF="text/cvs.txt">ASCII text (242K characters)</A>.
- <P>
- <LI>formatted as
- <A HREF="dvi/cvs.dvi.gz">a TeX dvi file (119K characters
- gzipped)</A>.
- <P>
- <li>formatted as
- <A href="ps/cvs.ps.gz">a PostScript file (171K characters
- gzipped)</a>.
- <p>
- <LI>the original
- <A HREF="texi/cvs.texinfo.tar.gz">Texinfo source (113K characters
- gzipped tar file)</A>
- <P>
-</UL>
-<P>
-
-<HR>
-
-Return to <A HREF="/home.html">GNU's home page</A>.
-<P>
-FSF & GNU inquiries & questions to
-<A HREF="mailto:address@hidden";><EM>address@hidden</EM></A>.
-Other <A HREF="/home.html#ContactInfo">ways to contact</A> the FSF.
-<P>
-Comments on these web pages to
-<A HREF="mailto:address@hidden";><EM>address@hidden</EM></A>,
-send other questions to
-<A HREF="mailto:address@hidden";><EM>address@hidden</EM></A>.
-<P>
-Copyright (C) 1997, 1998 Free Software Foundation, Inc.,
-59 Temple Place - Suite 330, Boston, MA 02111, USA
-<P>
-Verbatim copying and distribution of this entire article is
-permitted in any medium, provided this notice is preserved.<HR>
-</BODY>
-</HTML>
Index: manual/dvi/cvs.dvi.gz
===================================================================
RCS file: manual/dvi/cvs.dvi.gz
diff -N manual/dvi/cvs.dvi.gz
Binary files /tmp/cvsR2b0Km and /dev/null differ
Index: manual/html_chapter/cvs_1.html
===================================================================
RCS file: manual/html_chapter/cvs_1.html
diff -N manual/html_chapter/cvs_1.html
--- manual/html_chapter/cvs_1.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,278 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - About this manual</TITLE>
-</HEAD>
-<BODY>
-Go to the first, previous, <A HREF="cvs_2.html">next</A>, <A
HREF="cvs_25.html">last</A> section, <A HREF="cvs_toc.html">table of
contents</A>.
-<P><HR><P>
-
-<P>
-Version Management
-<P>
-with
-<P>
-CVS
-<P>
-for CVS 1.9
-<P>
-Per Cederqvist et al
-
-</P>
-<P>
-Copyright (C) 1992, 1993 Signum Support AB
-
-</P>
-<P>
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
-
-</P>
-<P>
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided also that the
-section entitled "GNU General Public License" is included exactly as
-in the original, and provided that the entire resulting derived work is
-distributed under the terms of a permission notice identical to this one.
-
-</P>
-<P>
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions,
-except that the section entitled "GNU General Public License" and
-this permission notice may be included in translations approved by the
-Free Software Foundation instead of in the original English.
-
-</P>
-
-
-
-<H1><A NAME="SEC1" HREF="cvs_toc.html#TOC1">About this manual</A></H1>
-<P>
-<A NAME="IDX1"></A>
-<A NAME="IDX2"></A>
-
-</P>
-<P>
-Up to this point, one of the weakest parts of CVS
-has been the documentation. CVS is a complex
-program. Previous versions of the manual were written
-in the manual page format, which is not really well
-suited for such a complex program.
-
-</P>
-<P>
-When writing this manual, I had several goals in mind:
-
-</P>
-
-<UL>
-<LI>
-
-No knowledge of RCS should be necessary.
-
-<LI>
-
-No previous knowledge of revision control software
-should be necessary. All terms, such as <EM>revision
-numbers</EM>, <EM>revision trees</EM> and <EM>merging</EM> are
-explained as they are introduced.
-
-<LI>
-
-The manual should concentrate on the things CVS users
-want to do, instead of what the CVS commands can do.
-The first part of this manual leads you through things
-you might want to do while doing development, and
-introduces the relevant CVS commands as they are
-needed.
-
-<LI>
-
-Information should be easy to find. In the reference
-manual in the appendices almost all information about
-every CVS command is gathered together. There is also
-an extensive index, and a lot of cross references.
-</UL>
-
-<P>
-<A NAME="IDX3"></A>
-<A NAME="IDX4"></A>
-This manual was contributed by Signum Support AB in
-Sweden. Signum is yet another in the growing list of
-companies that support free software. You are free to
-copy both this manual and the CVS program.
-See section <A HREF="cvs_24.html#SEC154">GNU GENERAL PUBLIC LICENSE</A>, for
the details. Signum Support offers
-support contracts and binary distribution for many
-programs, such as CVS, GNU Emacs, the
-GNU C compiler and others. Write to us for
-more information.
-
-</P>
-
-<PRE>
-Signum Support AB
-Box 2044
-S-580 02 Linkoping
-Sweden
-
-Email: address@hidden
-Phone: +46 (0)13 - 21 46 00
-Fax: +46 (0)13 - 21 47 00
-</PRE>
-
-<P>
-Another company selling support for CVS is Cyclic
-Software, web: <CODE>http://www.cyclic.com/</CODE>, email:
-<CODE>address@hidden</CODE>.
-
-</P>
-
-
-
-<H2><A NAME="SEC2" HREF="cvs_toc.html#TOC2">Checklist for the impatient
reader</A></H2>
-
-<P>
-CVS is a complex system. You will need to read
-the manual to be able to use all of its capabilities.
-There are dangers that can easily be avoided if you
-know about them, and this manual tries to warn you
-about them. This checklist is intended to help you
-avoid the dangers without reading the entire manual.
-If you intend to read the entire manual you can skip
-this table.
-
-</P>
-<DL COMPACT>
-
-<DT>Binary files
-<DD>
-CVS can handle binary files, but
-you must have RCS release 5.5 or later and
-a release of GNU diff that supports the <SAMP>`-a'</SAMP>
-flag (release 1.15 and later are OK). You must also
-configure both RCS and CVS to handle binary
-files when you install them.
-
-Keword substitution can be a source of trouble with
-binary files. See section <A HREF="cvs_17.html#SEC77">Keyword
substitution</A>, for
-solutions.
-
-<DT>The <CODE>admin</CODE> command
-<DD>
-Careless use of the <CODE>admin</CODE> command can cause
-CVS to cease working. See section <A
HREF="cvs_20.html#SEC91">admin--Administration front end for rcs</A>, before
trying
-to use it.
-</DL>
-
-
-
-<H2><A NAME="SEC3" HREF="cvs_toc.html#TOC3">Credits</A></H2>
-
-<P>
-<A NAME="IDX5"></A>
-<A NAME="IDX6"></A>
-Roland Pesch, Cygnus Support <<TT>address@hidden</TT>>
-wrote the manual pages which were distributed with
-CVS 1.3. Appendix A and B contain much text that
-was extracted from them. He also read an early draft
-of this manual and contributed many ideas and
-corrections.
-
-</P>
-<P>
-The mailing-list <CODE>info-cvs</CODE> is sometimes
-informative. I have included information from postings
-made by the following persons:
-David G. Grubbs <<TT>address@hidden</TT>>.
-
-</P>
-<P>
-Some text has been extracted from the man pages for
-RCS.
-
-</P>
-<P>
-The CVS FAQ by David G. Grubbs has provided
-useful material. The FAQ is no longer maintained,
-however, and this manual about the closest thing there
-is to a successor (with respect to documenting how to
-use CVS, at least).
-
-</P>
-<P>
-In addition, the following persons have helped by
-telling me about mistakes I've made:
-Roxanne Brunskill <<TT>address@hidden</TT>>,
-Kathy Dyer <<TT>address@hidden</TT>>,
-Karl Pingle <<TT>address@hidden</TT>>,
-Thomas A Peterson <<TT>address@hidden</TT>>,
-Inge Wallin <<TT>address@hidden</TT>>,
-Dirk Koschuetzki <<TT>address@hidden</TT>>
-and Michael Brown <<TT>address@hidden</TT>>.
-
-</P>
-
-
-<H2><A NAME="SEC4" HREF="cvs_toc.html#TOC4">BUGS</A></H2>
-
-<P>
-<A NAME="IDX7"></A>
-<A NAME="IDX8"></A>
-This manual is known to have room for improvement.
-Here is a list of known deficiencies:
-
-</P>
-
-<UL>
-<LI>
-
-In the examples, the output from CVS is sometimes
-displayed, sometimes not.
-
-<LI>
-
-The input that you are supposed to type in the examples
-should have a different font than the output from the
-computer.
-
-<LI>
-
-This manual should be clearer about what file
-permissions you should set up in the repository, and
-about setuid/setgid.
-
-<LI>
-
-Some of the chapters are not yet complete. They are
-noted by comments in the <TT>`cvs.texinfo'</TT> file.
-
-<LI>
-
-<A NAME="IDX9"></A>
-<A NAME="IDX10"></A>
-<A NAME="IDX11"></A>
-This list is not complete. If you notice any error,
-omission, or something that is unclear, please send
-mail to <TT>address@hidden</TT>.
-</UL>
-
-<P>
-I hope that you will find this manual useful, despite
-the above-mentioned shortcomings.
-
-</P>
-
-<PRE>
-
-Linkoping, October 1993
-Per Cederqvist
-</PRE>
-
-<P><HR><P>
-Go to the first, previous, <A HREF="cvs_2.html">next</A>, <A
HREF="cvs_25.html">last</A> section, <A HREF="cvs_toc.html">table of
contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_10.html
===================================================================
RCS file: manual/html_chapter/cvs_10.html
diff -N manual/html_chapter/cvs_10.html
--- manual/html_chapter/cvs_10.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,100 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Recursive behavior</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_9.html">previous</A>,
<A HREF="cvs_11.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC60" HREF="cvs_toc.html#TOC60">Recursive behavior</A></H1>
-<P>
-<A NAME="IDX239"></A>
-<A NAME="IDX240"></A>
-<A NAME="IDX241"></A>
-<A NAME="IDX242"></A>
-
-</P>
-<P>
-Almost all of the subcommands of CVS work
-recursively when you specify a directory as an
-argument. For instance, consider this directory
-structure:
-
-</P>
-
-<PRE>
- <CODE>$HOME</CODE>
- |
- +--<TT>tc</TT>
- | |
- +--<TT>CVS</TT>
- | (internal CVS files)
- +--<TT>Makefile</TT>
- +--<TT>backend.c</TT>
- +--<TT>driver.c</TT>
- +--<TT>frontend.c</TT>
- +--<TT>parser.c</TT>
- +--<TT>man</TT>
- | |
- | +--<TT>CVS</TT>
- | | (internal CVS files)
- | +--<TT>tc.1</TT>
- |
- +--<TT>testing</TT>
- |
- +--<TT>CVS</TT>
- | (internal CVS files)
- +--<TT>testpgm.t</TT>
- +--<TT>test2.t</TT>
-</PRE>
-
-<P>
-If <TT>`tc'</TT> is the current working directory, the
-following is true:
-
-</P>
-
-<UL>
-<LI>
-
-<SAMP>`cvs update testing'</SAMP> is equivalent to <SAMP>`cvs
-update testing/testpgm.t testing/test2.t'</SAMP>
-
-<LI>
-
-<SAMP>`cvs update testing man'</SAMP> updates all files in the
-subdirectories
-
-<LI>
-
-<SAMP>`cvs update .'</SAMP> or just <SAMP>`cvs update'</SAMP> updates
-all files in the <CODE>tc</CODE> module
-</UL>
-
-<P>
-If no arguments are given to <CODE>update</CODE> it will
-update all files in the current working directory and
-all its subdirectories. In other words, <TT>`.'</TT> is a
-default argument to <CODE>update</CODE>. This is also true
-for most of the CVS subcommands, not only the
-<CODE>update</CODE> command.
-
-</P>
-<P>
-The recursive behavior of the CVS subcommands can be
-turned off with the <SAMP>`-l'</SAMP> option.
-
-</P>
-
-<PRE>
-$ cvs update -l # Don't update files in subdirectories
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_9.html">previous</A>,
<A HREF="cvs_11.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_11.html
===================================================================
RCS file: manual/html_chapter/cvs_11.html
diff -N manual/html_chapter/cvs_11.html
--- manual/html_chapter/cvs_11.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,129 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Adding files to a directory</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_10.html">previous</A>,
<A HREF="cvs_12.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC61" HREF="cvs_toc.html#TOC61">Adding files to a
directory</A></H1>
-<P>
-<A NAME="IDX243"></A>
-
-</P>
-<P>
-To add a new file to a directory, follow these steps.
-
-</P>
-
-<UL>
-<LI>
-
-You must have a working copy of the directory.
-See section <A HREF="cvs_4.html#SEC11">Getting the source</A>.
-
-<LI>
-
-Create the new file inside your working copy of the directory.
-
-<LI>
-
-Use <SAMP>`cvs add <VAR>filename</VAR>'</SAMP> to tell CVS that you
-want to version control the file. If the file contains
-binary data, specify <SAMP>`-kb'</SAMP> (see section <A
HREF="cvs_18.html#SEC83">Handling binary files</A>).
-
-<LI>
-
-Use <SAMP>`cvs commit <VAR>filename</VAR>'</SAMP> to actually check
-in the file into the repository. Other developers
-cannot see the file until you perform this step.
-</UL>
-
-<P>
-You can also use the <CODE>add</CODE> command to add a new
-directory.
-
-</P>
-<P>
-Unlike most other commands, the <CODE>add</CODE> command is
-not recursive. You cannot even type <SAMP>`cvs add
-foo/bar'</SAMP>! Instead, you have to
-
-</P>
-
-<PRE>
-$ cd foo
-$ cvs add bar
-</PRE>
-
-<P>
-<A NAME="IDX244"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs add</B> <I>[<CODE>-k</CODE> kflag] [<CODE>-m</CODE>
message] files ...</I>
-<DD><A NAME="IDX245"></A>
-
-</P>
-<P>
-Schedule <VAR>files</VAR> to be added to the repository.
-The files or directories specified with <CODE>add</CODE> must
-already exist in the current directory. To add a whole
-new directory hierarchy to the source repository (for
-example, files received from a third-party vendor), use
-the <CODE>import</CODE> command instead. See section <A
HREF="cvs_20.html#SEC112">import--Import sources into CVS, using vendor
branches</A>.
-
-</P>
-<P>
-The added files are not placed in the source repository
-until you use <CODE>commit</CODE> to make the change
-permanent. Doing an <CODE>add</CODE> on a file that was
-removed with the <CODE>remove</CODE> command will undo the
-effect of the <CODE>remove</CODE>, unless a <CODE>commit</CODE>
-command intervened. See section <A HREF="cvs_12.html#SEC62">Removing files
from a module</A>, for an
-example.
-
-</P>
-<P>
-The <SAMP>`-k'</SAMP> option specifies the default way that
-this file will be checked out; for more information see
-section <A HREF="cvs_17.html#SEC81">Substitution modes</A>.
-
-</P>
-<P>
-The <SAMP>`-m'</SAMP> option specifies a description for the
-file. This description appears in the history log (if
-it is enabled, see section <A HREF="cvs_21.html#SEC149">The history file</A>).
It will also be
-saved in the version history inside the repository when
-the file is committed. The <CODE>log</CODE> command displays
-this description. The description can be changed using
-<SAMP>`admin -t'</SAMP>. See section <A
HREF="cvs_20.html#SEC91">admin--Administration front end for rcs</A>. If you
omit the
-<SAMP>`-m <VAR>description</VAR>'</SAMP> flag, an empty string will
-be used. You will not be prompted for a description.
-</DL>
-
-</P>
-<P>
-For example, the following commands add the file
-<TT>`backend.c'</TT> to the repository:
-
-</P>
-
-<PRE>
-$ cvs add backend.c
-$ cvs commit -m "Early version. Not yet compilable." backend.c
-</PRE>
-
-<P>
-When you add a file it is added only on the branch
-which you are working on (see section <A
HREF="cvs_8.html#SEC50">Branches</A>). You can
-later merge the additions to another branch if you want
-(see section <A HREF="cvs_9.html#SEC59">Merging can add or remove files</A>).
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_10.html">previous</A>,
<A HREF="cvs_12.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_12.html
===================================================================
RCS file: manual/html_chapter/cvs_12.html
diff -N manual/html_chapter/cvs_12.html
--- manual/html_chapter/cvs_12.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,147 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Removing files from a module</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_11.html">previous</A>,
<A HREF="cvs_13.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC62" HREF="cvs_toc.html#TOC62">Removing files from a
module</A></H1>
-<P>
-<A NAME="IDX246"></A>
-<A NAME="IDX247"></A>
-
-</P>
-<P>
-Modules change. New files are added, and old files
-disappear. Still, you want to be able to retrieve an
-exact copy of old releases of the module.
-
-</P>
-<P>
-Here is what you can do to remove a file from a module,
-but remain able to retrieve old revisions:
-
-</P>
-
-<UL>
-<LI>
-
-Make sure that you have not made any uncommitted
-modifications to the file. See section <A HREF="cvs_4.html#SEC14">Viewing
differences</A>,
-for one way to do that. You can also use the
-<CODE>status</CODE> or <CODE>update</CODE> command. If you remove
-the file without committing your changes, you will of
-course not be able to retrieve the file as it was
-immediately before you deleted it.
-
-<LI>
-
-Remove the file from your working copy of the module.
-You can for instance use <CODE>rm</CODE>.
-
-<LI>
-
-Use <SAMP>`cvs remove <VAR>filename</VAR>'</SAMP> to tell CVS that
-you really want to delete the file.
-
-<LI>
-
-Use <SAMP>`cvs commit <VAR>filename</VAR>'</SAMP> to actually
-perform the removal of the file from the repository.
-</UL>
-
-<P>
-When you commit the removal of the file, CVS
-records the fact that the file no longer exists. It is
-possible for a file to exist on only some branches and
-not on others, or to re-add another file with the same
-name later. CVS will correctly create or not create
-the file, based on the <SAMP>`-r'</SAMP> and <SAMP>`-D'</SAMP> options
-specified to <CODE>checkout</CODE> or <CODE>update</CODE>.
-
-</P>
-<P>
-<A NAME="IDX248"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs remove</B> <I>[<CODE>-lR</CODE>] files ...</I>
-<DD><A NAME="IDX249"></A>
-
-</P>
-<P>
-Schedule file(s) to be removed from the repository
-(files which have not already been removed from the
-working directory are not processed). This command
-does not actually remove the file from the repository
-until you commit the removal. The <SAMP>`-R'</SAMP> option
-(the default) specifies that it will recurse into
-subdirectories; <SAMP>`-l'</SAMP> specifies that it will not.
-</DL>
-
-</P>
-<P>
-Here is an example of removing several files:
-
-</P>
-
-<PRE>
-$ cd test
-$ rm ?.c
-$ cvs remove
-cvs remove: Removing .
-cvs remove: scheduling a.c for removal
-cvs remove: scheduling b.c for removal
-cvs remove: use 'cvs commit' to remove these files permanently
-$ cvs ci -m "Removed unneeded files"
-cvs commit: Examining .
-cvs commit: Committing .
-</PRE>
-
-<P>
-If you change your mind you can easily resurrect the
-file before you commit it, using the <CODE>add</CODE>
-command.
-
-</P>
-
-<PRE>
-$ ls
-CVS ja.h oj.c
-$ rm oj.c
-$ cvs remove oj.c
-cvs remove: scheduling oj.c for removal
-cvs remove: use 'cvs commit' to remove this file permanently
-$ cvs add oj.c
-U oj.c
-cvs add: oj.c, version 1.1.1.1, resurrected
-</PRE>
-
-<P>
-If you realize your mistake before you run the
-<CODE>remove</CODE> command you can use <CODE>update</CODE> to
-resurrect the file:
-
-</P>
-
-<PRE>
-$ rm oj.c
-$ cvs update oj.c
-cvs update: warning: oj.c was lost
-U oj.c
-</PRE>
-
-<P>
-When you remove a file it is added only on the branch
-which you are working on (see section <A
HREF="cvs_8.html#SEC50">Branches</A>). You can
-later merge the additions to another branch if you want
-(see section <A HREF="cvs_9.html#SEC59">Merging can add or remove files</A>).
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_11.html">previous</A>,
<A HREF="cvs_13.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_13.html
===================================================================
RCS file: manual/html_chapter/cvs_13.html
diff -N manual/html_chapter/cvs_13.html
--- manual/html_chapter/cvs_13.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,162 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Tracking third-party sources</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_12.html">previous</A>,
<A HREF="cvs_14.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC63" HREF="cvs_toc.html#TOC63">Tracking third-party
sources</A></H1>
-<P>
-<A NAME="IDX250"></A>
-<A NAME="IDX251"></A>
-
-</P>
-<P>
-If you modify a program to better fit your site, you
-probably want to include your modifications when the next
-release of the program arrives. CVS can help you with
-this task.
-
-</P>
-<P>
-<A NAME="IDX252"></A>
-<A NAME="IDX253"></A>
-<A NAME="IDX254"></A>
-In the terminology used in CVS, the supplier of the
-program is called a <EM>vendor</EM>. The unmodified
-distribution from the vendor is checked in on its own
-branch, the <EM>vendor branch</EM>. CVS reserves branch
-1.1.1 for this use.
-
-</P>
-<P>
-When you modify the source and commit it, your revision
-will end up on the main trunk. When a new release is
-made by the vendor, you commit it on the vendor branch
-and copy the modifications onto the main trunk.
-
-</P>
-<P>
-Use the <CODE>import</CODE> command to create and update
-the vendor branch. After a successful <CODE>import</CODE>
-the vendor branch is made the `head' revision, so
-anyone that checks out a copy of the file gets that
-revision. When a local modification is committed it is
-placed on the main trunk, and made the `head'
-revision.
-
-</P>
-
-
-
-<H2><A NAME="SEC64" HREF="cvs_toc.html#TOC64">Importing a module for the first
time</A></H2>
-<P>
-<A NAME="IDX255"></A>
-
-</P>
-<P>
-Use the <CODE>import</CODE> command to check in the sources
-for the first time. When you use the <CODE>import</CODE>
-command to track third-party sources, the <EM>vendor
-tag</EM> and <EM>release tags</EM> are useful. The
-<EM>vendor tag</EM> is a symbolic name for the branch
-(which is always 1.1.1, unless you use the <SAMP>`-b
-<VAR>branch</VAR>'</SAMP> flag---See section <A
HREF="cvs_20.html#SEC113">import options</A>). The
-<EM>release tags</EM> are symbolic names for a particular
-release, such as <SAMP>`FSF_0_04'</SAMP>.
-
-</P>
-<P>
-<A NAME="IDX256"></A>
-Suppose you use <CODE>wdiff</CODE> (a variant of <CODE>diff</CODE>
-that ignores changes that only involve whitespace), and
-are going to make private modifications that you want
-to be able to use even when new releases are made in
-the future. You start by importing the source to your
-repository:
-
-</P>
-
-<PRE>
-$ tar xfz wdiff-0.04.tar.gz
-$ cd wdiff-0.04
-$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
-</PRE>
-
-<P>
-The vendor tag is named <SAMP>`FSF_DIST'</SAMP> in the above
-example, and the only release tag assigned is
-<SAMP>`WDIFF_0_04'</SAMP>.
-
-</P>
-
-
-<H2><A NAME="SEC65" HREF="cvs_toc.html#TOC65">Updating a module with the
import command</A></H2>
-
-<P>
-When a new release of the source arrives, you import it into the
-repository with the same <CODE>import</CODE> command that you used to set up
-the repository in the first place. The only difference is that you
-specify a different release tag this time.
-
-</P>
-
-<PRE>
-$ tar xfz wdiff-0.05.tar.gz
-$ cd wdiff-0.05
-$ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
-</PRE>
-
-<P>
-For files that have not been modified locally, the newly created
-revision becomes the head revision. If you have made local
-changes, <CODE>import</CODE> will warn you that you must merge the changes
-into the main trunk, and tell you to use <SAMP>`checkout -j'</SAMP> to do so.
-
-</P>
-
-<PRE>
-$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
-</PRE>
-
-<P>
-The above command will check out the latest revision of
-<SAMP>`wdiff'</SAMP>, merging the changes made on the vendor branch
<SAMP>`FSF_DIST'</SAMP>
-since yesterday into the working copy. If any conflicts arise during
-the merge they should be resolved in the normal way (see section <A
HREF="cvs_7.html#SEC40">Conflicts example</A>). Then, the modified files may
be committed.
-
-</P>
-<P>
-Using a date, as suggested above, assumes that you do
-not import more than one release of a product per
-day. If you do, you can always use something like this
-instead:
-
-</P>
-
-<PRE>
-$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
-</PRE>
-
-<P>
-In this case, the two above commands are equivalent.
-
-</P>
-
-
-<H2><A NAME="SEC66" HREF="cvs_toc.html#TOC66">How to handle binary files with
cvs import</A></H2>
-
-<P>
-Use the <SAMP>`-k'</SAMP> wrapper option to tell import which
-files are binary. See section <A HREF="cvs_21.html#SEC138">The cvswrappers
file</A>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_12.html">previous</A>,
<A HREF="cvs_14.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_14.html
===================================================================
RCS file: manual/html_chapter/cvs_14.html
diff -N manual/html_chapter/cvs_14.html
--- manual/html_chapter/cvs_14.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,195 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Moving and renaming files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_13.html">previous</A>,
<A HREF="cvs_15.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC67" HREF="cvs_toc.html#TOC67">Moving and renaming
files</A></H1>
-<P>
-<A NAME="IDX257"></A>
-<A NAME="IDX258"></A>
-<A NAME="IDX259"></A>
-
-</P>
-<P>
-Moving files to a different directory or renaming them
-is not difficult, but some of the ways in which this
-works may be non-obvious. (Moving or renaming a
-directory is even harder. See section <A HREF="cvs_15.html#SEC71">Moving and
renaming directories</A>).
-
-</P>
-<P>
-The examples below assume that the file <VAR>old</VAR> is renamed to
-<VAR>new</VAR>.
-
-</P>
-
-
-
-<H2><A NAME="SEC68" HREF="cvs_toc.html#TOC68">The Normal way to Rename</A></H2>
-
-<P>
-The normal way to move a file is to copy <VAR>old</VAR> to
-<VAR>new</VAR>, and then issue the normal CVS commands
-to remove <VAR>old</VAR> from the repository, and add
-<VAR>new</VAR> to it. (Both <VAR>old</VAR> and <VAR>new</VAR> could
-contain relative paths, for example <TT>`foo/bar.c'</TT>).
-
-</P>
-
-<PRE>
-$ mv <VAR>old</VAR> <VAR>new</VAR>
-$ cvs remove <VAR>old</VAR>
-$ cvs add <VAR>new</VAR>
-$ cvs commit -m "Renamed <VAR>old</VAR> to <VAR>new</VAR>" <VAR>old</VAR>
<VAR>new</VAR>
-</PRE>
-
-<P>
-This is the simplest way to move a file, it is not
-error-prone, and it preserves the history of what was
-done. Note that to access the history of the file you
-must specify the old or the new name, depending on what
-portion of the history you are accessing. For example,
-<CODE>cvs log <VAR>old</VAR></CODE> will give the log up until the
-time of the rename.
-
-</P>
-<P>
-When <VAR>new</VAR> is committed its revision numbers will
-start at 1.0 again, so if that bothers you, use the
-<SAMP>`-r rev'</SAMP> option to commit (see section <A
HREF="cvs_20.html#SEC100">commit options</A>)
-
-</P>
-
-
-<H2><A NAME="SEC69" HREF="cvs_toc.html#TOC69">Moving the history file</A></H2>
-
-<P>
-This method is more dangerous, since it involves moving
-files inside the repository. Read this entire section
-before trying it out!
-
-</P>
-
-<PRE>
-$ cd $CVSROOT/<VAR>module</VAR>
-$ mv <VAR>old</VAR>,v <VAR>new</VAR>,v
-</PRE>
-
-<P>
-Advantages:
-
-</P>
-
-<UL>
-<LI>
-
-The log of changes is maintained intact.
-
-<LI>
-
-The revision numbers are not affected.
-</UL>
-
-<P>
-Disadvantages:
-
-</P>
-
-<UL>
-<LI>
-
-Old releases of the module cannot easily be fetched from the
-repository. (The file will show up as <VAR>new</VAR> even
-in revisions from the time before it was renamed).
-
-<LI>
-
-There is no log information of when the file was renamed.
-
-<LI>
-
-Nasty things might happen if someone accesses the history file
-while you are moving it. Make sure no one else runs any of the CVS
-commands while you move it.
-</UL>
-
-
-
-<H2><A NAME="SEC70" HREF="cvs_toc.html#TOC70">Copying the history file</A></H2>
-
-<P>
-This way also involves direct modifications to the
-repository. It is safe, but not without drawbacks.
-
-</P>
-
-<PRE>
-# Copy the RCS file inside the repository
-$ cd $CVSROOT/<VAR>module</VAR>
-$ cp <VAR>old</VAR>,v <VAR>new</VAR>,v
-# Remove the old file
-$ cd ~/<VAR>module</VAR>
-$ rm <VAR>old</VAR>
-$ cvs remove <VAR>old</VAR>
-$ cvs commit <VAR>old</VAR>
-# Remove all tags from <VAR>new</VAR>
-$ cvs update <VAR>new</VAR>
-$ cvs log <VAR>new</VAR> # Remember the non-branch tag names
-$ cvs tag -d <VAR>tag1</VAR> <VAR>new</VAR>
-$ cvs tag -d <VAR>tag2</VAR> <VAR>new</VAR>
-...
-</PRE>
-
-<P>
-By removing the tags you will be able to check out old
-revisions of the module.
-
-</P>
-<P>
-Advantages:
-
-</P>
-
-<UL>
-<LI>
-
-Checking out old revisions works correctly, as long as
-you use <SAMP>`-r<VAR>tag</VAR>'</SAMP> and not
<SAMP>`-D<VAR>date</VAR>'</SAMP>
-to retrieve the revisions.
-
-<LI>
-
-The log of changes is maintained intact.
-
-<LI>
-
-The revision numbers are not affected.
-</UL>
-
-<P>
-Disadvantages:
-
-</P>
-
-<UL>
-<LI>
-
-You cannot easily see the history of the file across the rename.
-
-<LI>
-
-Unless you use the <SAMP>`-r rev'</SAMP> (see section <A
HREF="cvs_20.html#SEC100">commit options</A>) flag when <VAR>new</VAR> is
committed its revision
-numbers will start at 1.0 again.
-</UL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_13.html">previous</A>,
<A HREF="cvs_15.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_15.html
===================================================================
RCS file: manual/html_chapter/cvs_15.html
diff -N manual/html_chapter/cvs_15.html
--- manual/html_chapter/cvs_15.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,82 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Moving and renaming
directories</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_14.html">previous</A>,
<A HREF="cvs_16.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC71" HREF="cvs_toc.html#TOC71">Moving and renaming
directories</A></H1>
-<P>
-<A NAME="IDX260"></A>
-<A NAME="IDX261"></A>
-<A NAME="IDX262"></A>
-
-</P>
-<P>
-If you want to be able to retrieve old versions of the
-module, you must move each file in the directory
-with the CVS commands. See section <A HREF="cvs_14.html#SEC68">The Normal way
to Rename</A>. The old, empty
-directory will remain inside the repository, but it
-will not appear in your workspace when you check out
-the module in the future.
-
-</P>
-<P>
-If you really want to rename or delete a directory, you
-can do it like this:
-
-</P>
-
-<OL>
-<LI>
-
-Inform everyone who has a copy of the module that the
-directory will be renamed. They should commit all
-their changes, and remove their working copies of the
-module, before you take the steps below.
-
-<LI>
-
-Rename the directory inside the repository.
-
-
-<PRE>
-$ cd $CVSROOT/<VAR>module</VAR>
-$ mv <VAR>old-dir</VAR> <VAR>new-dir</VAR>
-</PRE>
-
-<LI>
-
-Fix the CVS administrative files, if necessary (for
-instance if you renamed an entire module).
-
-<LI>
-
-Tell everyone that they can check out the module and continue
-working.
-
-</OL>
-
-<P>
-If someone had a working copy of the module the CVS commands will
-cease to work for him, until he removes the directory
-that disappeared inside the repository.
-
-</P>
-<P>
-It is almost always better to move the files in the
-directory instead of moving the directory. If you move the
-directory you are unlikely to be able to retrieve old
-releases correctly, since they probably depend on the
-name of the directories.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_14.html">previous</A>,
<A HREF="cvs_16.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_16.html
===================================================================
RCS file: manual/html_chapter/cvs_16.html
diff -N manual/html_chapter/cvs_16.html
--- manual/html_chapter/cvs_16.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,165 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - History browsing</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_15.html">previous</A>,
<A HREF="cvs_17.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC72" HREF="cvs_toc.html#TOC72">History browsing</A></H1>
-<P>
-<A NAME="IDX263"></A>
-<A NAME="IDX264"></A>
-<A NAME="IDX265"></A>
-
-</P>
-
-<P>
-Once you have used CVS to store a version control
-history--what files have changed when, how, and by
-whom, there are a variety of mechanisms for looking
-through the history.
-
-</P>
-
-
-
-<H2><A NAME="SEC73" HREF="cvs_toc.html#TOC73">Log messages</A></H2>
-
-<P>
-Whenever you commit a file you specify a log message.
-
-</P>
-<P>
-To look through the log messages which have been
-specified for every revision which has been committed,
-use the <CODE>cvs log</CODE> command (see section <A
HREF="cvs_20.html#SEC116">log--Print out log information for files</A>).
-
-</P>
-
-
-<H2><A NAME="SEC74" HREF="cvs_toc.html#TOC74">The history database</A></H2>
-
-<P>
-You can use the history file (see section <A HREF="cvs_21.html#SEC149">The
history file</A>) to
-log various CVS actions. To retrieve the
-information from the history file, use the <CODE>cvs
-history</CODE> command (see section <A HREF="cvs_20.html#SEC110">history--Show
status of files and users</A>).
-
-</P>
-
-
-<H2><A NAME="SEC75" HREF="cvs_toc.html#TOC75">User-defined logging</A></H2>
-
-<P>
-You can customize CVS to log various kinds of
-actions, in whatever manner you choose. These
-mechanisms operate by executing a script at various
-times. The script might append a message to a file
-listing the information and the programmer who created
-it, or send mail to a group of developers, or, perhaps,
-post a message to a particular newsgroup. To log
-commits, use the <TT>`loginfo'</TT> file (see section <A
HREF="cvs_21.html#SEC144">Loginfo</A>).
-To log commits, checkouts, exports, and tags,
-respectively, you can also use the <SAMP>`-i'</SAMP>,
-<SAMP>`-o'</SAMP>, <SAMP>`-e'</SAMP>, and <SAMP>`-t'</SAMP> options in the
-modules file. For a more flexible way of giving
-notifications to various users, which requires less in
-the way of keeping centralized scripts up to date, use
-the <CODE>cvs watch add</CODE> command (see section <A
HREF="cvs_7.html#SEC45">Telling CVS to notify you</A>); this command is useful
even if you are not
-using <CODE>cvs watch on</CODE>.
-
-</P>
-<P>
-<A NAME="IDX266"></A>
-The <TT>`taginfo'</TT> file defines programs to execute
-when someone executes a <CODE>tag</CODE> or <CODE>rtag</CODE>
-command. The <TT>`taginfo'</TT> file has the standard form
-for administrative files (see section <A HREF="cvs_21.html#SEC136">Reference
manual for the Administrative files</A>), where each line is a regular
expression
-followed by a command to execute. The arguments passed
-to the command are, in order, the <VAR>tagname</VAR>,
-<VAR>operation</VAR> (<CODE>add</CODE> for <CODE>tag</CODE>,
-<CODE>mov</CODE> for <CODE>tag -F</CODE>, and <CODE>del</CODE> for
-<CODE>tag -d</CODE>), <VAR>repository</VAR>, and any remaining are
-pairs of <VAR>filename</VAR> <VAR>revision</VAR>. A non-zero
-exit of the filter program will cause the tag to be
-aborted.
-
-</P>
-
-
-<H2><A NAME="SEC76" HREF="cvs_toc.html#TOC76">Annotate command</A></H2>
-<P>
-<A NAME="IDX267"></A>
-
-</P>
-<P>
-<DL>
-<DT><U>Command:</U> <B>cvs annotate</B> <I>[<CODE>-lf</CODE>] [<CODE>-r
rev</CODE>|<CODE>-D date</CODE>] files ...</I>
-<DD><A NAME="IDX268"></A>
-
-</P>
-<P>
-For each file in <VAR>files</VAR>, print the head revision
-of the trunk, together with information on the last
-modification for each line. For example:
-
-</P>
-
-<PRE>
-$ cvs annotate ssfile
-Annotations for ssfile
-***************
-1.1 (mary 27-Mar-96): ssfile line 1
-1.2 (joe 28-Mar-96): ssfile line 2
-</PRE>
-
-<P>
-The file <TT>`ssfile'</TT> currently contains two lines.
-The <CODE>ssfile line 1</CODE> line was checked in by
-<CODE>mary</CODE> on March 27. Then, on March 28, <CODE>joe</CODE>
-added a line <CODE>ssfile line 2</CODE>, without modifying
-the <CODE>ssfile line 1</CODE> line. This report doesn't
-tell you anything about lines which have been deleted
-or replaced; you need to use <CODE>cvs diff</CODE> for that
-(see section <A HREF="cvs_20.html#SEC105">diff--Run diffs between
revisions</A>).
-
-</P>
-</DL>
-
-<P>
-These standard options are available with
-<CODE>annotate</CODE> (see section <A HREF="cvs_20.html#SEC90">Common command
options</A>, for a complete
-description of them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Annotate the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
-<VAR>tag</VAR>'</SAMP> flags. If no matching revision is found,
-annotate the most recent revision (instead of ignoring
-the file).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory. See section <A
HREF="cvs_10.html#SEC60">Recursive behavior</A>.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Annotate revision <VAR>tag</VAR>.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_15.html">previous</A>,
<A HREF="cvs_17.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_17.html
===================================================================
RCS file: manual/html_chapter/cvs_17.html
diff -N manual/html_chapter/cvs_17.html
--- manual/html_chapter/cvs_17.html 8 Jun 2009 20:46:50 -0000 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,376 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Keyword substitution</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_16.html">previous</A>,
<A HREF="cvs_18.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC77" HREF="cvs_toc.html#TOC77">Keyword substitution</A></H1>
-<P>
-<A NAME="IDX269"></A>
-<A NAME="IDX270"></A>
-<A NAME="IDX271"></A>
-
-</P>
-
-<P>
-As long as you edit source files inside your working
-copy of a module you can always find out the state of
-your files via <SAMP>`cvs status'</SAMP> and <SAMP>`cvs log'</SAMP>.
-But as soon as you export the files from your
-development environment it becomes harder to identify
-which revisions they are.
-
-</P>
-<P>
-RCS uses a mechanism known as <EM>keyword
-substitution</EM> (or <EM>keyword expansion</EM>) to help
-identifying the files. Embedded strings of the form
-<CODE>$<VAR>keyword</VAR>$</CODE> and
-<CODE>$<VAR>keyword</VAR>:...$</CODE> in a file are replaced
-with strings of the form
-<CODE>$<VAR>keyword</VAR>:<VAR>value</VAR>$</CODE> whenever you obtain
-a new revision of the file.
-
-</P>
-
-
-
-<H2><A NAME="SEC78" HREF="cvs_toc.html#TOC78">RCS Keywords</A></H2>
-<P>
-<A NAME="IDX272"></A>
-
-</P>
-<P>
-This is a list of the keywords that RCS currently
-(in release 5.6.0.1) supports:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>$Author: ward $</CODE>
-<DD>
-<A NAME="IDX273"></A>
-
-The login name of the user who checked in the revision.
-
-<A NAME="IDX274"></A>
-<DT><CODE>$Date: 2009/06/08 20:46:50 $</CODE>
-<DD>
-The date and time (UTC) the revision was checked in.
-
-<A NAME="IDX275"></A>
-<DT><CODE>$Header:
/web/www/www/software/cvs/manual/html_chapter/Attic/cvs_17.html,v 1.2
2009/06/08 20:46:50 ward Exp $</CODE>
-<DD>
-A standard header containing the full pathname of the
-RCS file, the revision number, the date (UTC), the
-author, the state, and the locker (if locked). Files
-will normally never be locked when you use CVS.
-
-<A NAME="IDX276"></A>
-<DT><CODE>$Id: cvs_17.html,v 1.2 2009/06/08 20:46:50 ward Exp $</CODE>
-<DD>
-Same as <CODE>$Header:
/web/www/www/software/cvs/manual/html_chapter/Attic/cvs_17.html,v 1.2
2009/06/08 20:46:50 ward Exp $</CODE>, except that the RCS
-filename is without a path.
-
-<A NAME="IDX277"></A>
-<DT><CODE>$Name: $</CODE>
-<DD>
-Tag name used to check out this file.
-
-<A NAME="IDX278"></A>
-<DT><CODE>$Locker: $</CODE>
-<DD>
-The login name of the user who locked the revision
-(empty if not locked, and thus almost always useless
-when you are using CVS).
-
-<A NAME="IDX279"></A>
-<DT><CODE>$Log: cvs_17.html,v $
-<DT><CODE>Revision 1.2 2009/06/08 20:46:50 ward
-<DT><CODE>changes that were lost from the CVS tree due to the savannah crash
of 2009/05/29
-<DT><CODE>
-<DT><CODE>Revision 1.1 2003/11/07 20:55:32 sinuhe
-<DT><CODE>Add manual.
-<DT><CODE></CODE>
-<DD>
-The log message supplied during commit, preceded by a
-header containing the RCS filename, the revision
-number, the author, and the date (UTC). Existing log
-messages are <EM>not</EM> replaced. Instead, the new log
-message is inserted after <CODE>$Log: cvs_17.html,v $
-message is inserted after <CODE>Revision 1.1 2003/11/07 20:55:32 sinuhe
-message is inserted after <CODE>Add manual.
-message is inserted after <CODE></CODE>.
-Each new line is prefixed with a <EM>comment leader</EM>
-which RCS guesses from the file name extension.
-It can be changed with <CODE>cvs admin -c</CODE>.
-See section <A HREF="cvs_20.html#SEC92">admin options</A>. This keyword is
useful for
-accumulating a complete change log in a source file,
-but for several reasons it can be problematic.
-See section <A HREF="cvs_17.html#SEC82">Problems with the $Log: cvs_17.html,v $
-See section <A HREF="cvs_17.html#SEC82">Problems with the Revision 1.1
2003/11/07 20:55:32 sinuhe
-See section <A HREF="cvs_17.html#SEC82">Problems with the Add manual.
-See section <A HREF="cvs_17.html#SEC82">Problems with the keyword.</A>.
-
-<A NAME="IDX280"></A>
-<DT><CODE>$RCSfile: cvs_17.html,v $</CODE>
-<DD>
-The name of the RCS file without a path.
-
-<A NAME="IDX281"></A>
-<DT><CODE>$Revision: 1.2 $</CODE>
-<DD>
-The revision number assigned to the revision.
-
-<A NAME="IDX282"></A>
-<DT><CODE>$Source:
/web/www/www/software/cvs/manual/html_chapter/Attic/cvs_17.html,v $</CODE>
-<DD>
-The full pathname of the RCS file.
-
-<A NAME="IDX283"></A>
-<DT><CODE>$State: Exp $</CODE>
-<DD>
-The state assigned to the revision. States can be
-assigned with <CODE>cvs admin -s</CODE>---See section <A
HREF="cvs_20.html#SEC92">admin options</A>.
-
-</DL>
-
-
-
-<H2><A NAME="SEC79" HREF="cvs_toc.html#TOC79">Using keywords</A></H2>
-
-<P>
-To include a keyword string you simply include the
-relevant text string, such as <CODE>$Id: cvs_17.html,v 1.2 2009/06/08 20:46:50
ward Exp $</CODE>, inside the
-file, and commit the file. CVS will automatically
-expand the string as part of the commit operation.
-
-</P>
-<P>
-It is common to embed <CODE>$</CODE>Id$ string in the
-C source code. This example shows the first few lines
-of a typical file, after keyword substitution has been
-performed:
-
-</P>
-
-<PRE>
-static char *rcsid="$Id: cvs_17.html,v 1.2 2009/06/08 20:46:50 ward Exp $";
-/* The following lines will prevent <CODE>gcc</CODE> version 2.<VAR>x</VAR>
- from issuing an "unused variable" warning. */
-#if __GNUC__ == 2
-#define USE(var) static void * use_##var = (&use_##var, (void *) &var)
-USE (rcsid);
-#endif
-</PRE>
-
-<P>
-Even though a clever optimizing compiler could remove
-the unused variable <CODE>rcsid</CODE>, most compilers tend
-to include the string in the binary. Some compilers
-have a <CODE>#pragma</CODE> directive to include literal text
-in the binary.
-
-</P>
-<P>
-<A NAME="IDX284"></A>
-The <CODE>ident</CODE> command (which is part of the RCS
-package) can be used to extract keywords and their
-values from a file. This can be handy for text files,
-but it is even more useful for extracting keywords from
-binary files.
-
-</P>
-
-<PRE>
-$ ident samp.c
-samp.c:
- $Id: cvs_17.html,v 1.2 2009/06/08 20:46:50 ward Exp $
-$ gcc samp.c
-$ ident a.out
-a.out:
- $Id: cvs_17.html,v 1.2 2009/06/08 20:46:50 ward Exp $
-</PRE>
-
-<P>
-<A NAME="IDX285"></A>
-SCCS is another popular revision control system.
-It has a command, <CODE>what</CODE>, which is very similar to
-<CODE>ident</CODE> and used for the same purpose. Many sites
-without RCS have SCCS. Since <CODE>what</CODE>
-looks for the character sequence <CODE>@(#)</CODE> it is
-easy to include keywords that are detected by either
-command. Simply prefix the RCS keyword with the
-magic SCCS phrase, like this:
-
-</P>
-
-<PRE>
-static char *id="@(#) $Id: cvs_17.html,v 1.2 2009/06/08 20:46:50 ward Exp $";
-</PRE>
-
-
-
-<H2><A NAME="SEC80" HREF="cvs_toc.html#TOC80">Avoiding substitution</A></H2>
-
-<P>
-Keyword substitution has its disadvantages. Sometimes
-you might want the literal text string
-<SAMP>`$'</SAMP>Author$ to appear inside a file without
-RCS interpreting it as a keyword and expanding it
-into something like <SAMP>`$'</SAMP>Author: ceder $.
-
-</P>
-<P>
-There is unfortunately no way to selectively turn off
-keyword substitution. You can use <SAMP>`-ko'</SAMP>
-(see section <A HREF="cvs_17.html#SEC81">Substitution modes</A>) to turn off
keyword
-substitution entirely.
-
-</P>
-<P>
-In many cases you can avoid using RCS keywords in
-the source, even though they appear in the final
-product. For example, the source for this manual
-contains <SAMP>address@hidden'</SAMP> whenever the text
-<SAMP>`$'</SAMP>Author$ should appear. In <CODE>nroff</CODE>
-and <CODE>troff</CODE> you can embed the null-character
-<CODE>\&</CODE> inside the keyword for a similar effect.
-
-</P>
-
-
-<H2><A NAME="SEC81" HREF="cvs_toc.html#TOC81">Substitution modes</A></H2>
-<P>
-<A NAME="IDX286"></A>
-<A NAME="IDX287"></A>
-
-</P>
-<P>
-Each file has a stored default substitution mode, and
-each working directory copy of a file also has a
-substitution mode. The former is set by the <SAMP>`-k'</SAMP>
-option to <CODE>cvs add</CODE> and <CODE>cvs admin</CODE>; the
-latter is set by the -k or -A options to <CODE>cvs
-checkout</CODE> or <CODE>cvs update</CODE>. <CODE>cvs diff</CODE> also
-has a <SAMP>`-k'</SAMP> option. For some examples,
-See section <A HREF="cvs_18.html#SEC83">Handling binary files</A>.
-
-</P>
-<P>
-The modes available are:
-
-</P>
-<DL COMPACT>
-
-<DT><SAMP>`-kkv'</SAMP>
-<DD>
-Generate keyword strings using the default form, e.g.
-<CODE>$</CODE>Revision: 5.7 $ for the <CODE>Revision</CODE>
-keyword.
-
-<DT><SAMP>`-kkvl'</SAMP>
-<DD>
-Like <SAMP>`-kkv'</SAMP>, except that a locker's name is always
-inserted if the given revision is currently locked.
-This option is normally not useful when CVS is used.
-
-<DT><SAMP>`-kk'</SAMP>
-<DD>
-Generate only keyword names in keyword strings; omit
-their values. For example, for the <CODE>Revision</CODE>
-keyword, generate the string <CODE>$</CODE>Revision$
-instead of <CODE>$</CODE>Revision: 5.7 $. This option
-is useful to ignore differences due to keyword
-substitution when comparing different revisions of a
-file.
-
-<DT><SAMP>`-ko'</SAMP>
-<DD>
-Generate the old keyword string, present in the working
-file just before it was checked in. For example, for
-the <CODE>Revision</CODE> keyword, generate the string
-<CODE>$</CODE>Revision: 1.1 $ instead of
-<CODE>$</CODE>Revision: 5.7 $ if that is how the
-string appeared when the file was checked in.
-
-<DT><SAMP>`-kb'</SAMP>
-<DD>
-Like <SAMP>`-ko'</SAMP>, but also inhibit conversion of line
-endings between the canonical form in which they are
-stored in the repository (linefeed only), and the form
-appropriate to the operating system in use on the
-client. For systems, like unix, which use linefeed
-only to terminate lines, this is the same as
-<SAMP>`-ko'</SAMP>. For more information on binary files, see
-section <A HREF="cvs_18.html#SEC83">Handling binary files</A>.
-
-<DT><SAMP>`-kv'</SAMP>
-<DD>
-Generate only keyword values for keyword strings. For
-example, for the <CODE>Revision</CODE> keyword, generate the string
-<CODE>5.7</CODE> instead of <CODE>$</CODE>Revision: 5.7 $.
-This can help generate files in programming languages
-where it is hard to strip keyword delimiters like
-<CODE>$</CODE>Revision: $ from a string. However,
-further keyword substitution cannot be performed once
-the keyword names are removed, so this option should be
-used with care.
-
-One often would like to use <SAMP>`-kv'</SAMP> with <CODE>cvs
-export</CODE>---see section <A HREF="cvs_20.html#SEC108">export--Export
sources from CVS, similar to checkout</A>. But be aware that doesn't
-handle an export containing binary files correctly.
-
-</DL>
-
-
-
-<H2><A NAME="SEC82" HREF="cvs_toc.html#TOC82">Problems with the $Log:
cvs_17.html,v $
-<H2><A NAME="SEC82" HREF="cvs_toc.html#TOC82">Problems with the Revision 1.1
2003/11/07 20:55:32 sinuhe
-<H2><A NAME="SEC82" HREF="cvs_toc.html#TOC82">Problems with the Add manual.
-<H2><A NAME="SEC82" HREF="cvs_toc.html#TOC82">Problems with the
keyword.</A></H2>
-
-<P>
-The <CODE>$</CODE>Log$ keyword is somewhat
-controversial. As long as you are working on your
-development system the information is easily accessible
-even if you do not use the <CODE>$</CODE>Log$
-keyword--just do a <CODE>cvs log</CODE>. Once you export
-the file the history information might be useless
-anyhow.
-
-</P>
-<P>
-A more serious concern is that RCS is not good at
-handling <CODE>$</CODE>Log$ entries when a branch is
-merged onto the main trunk. Conflicts often result
-from the merging operation.
-
-</P>
-<P>
-People also tend to "fix" the log entries in the file
-(correcting spelling mistakes and maybe even factual
-errors). If that is done the information from
-<CODE>cvs log</CODE> will not be consistent with the
-information inside the file. This may or may not be a
-problem in real life.
-
-</P>
-<P>
-It has been suggested that the <CODE>$</CODE>Log$
-keyword should be inserted <EM>last</EM> in the file, and
-not in the files header, if it is to be used at all.
-That way the long list of change messages will not
-interfere with everyday source file browsing.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_16.html">previous</A>,
<A HREF="cvs_18.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_18.html
===================================================================
RCS file: manual/html_chapter/cvs_18.html
diff -N manual/html_chapter/cvs_18.html
--- manual/html_chapter/cvs_18.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,111 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Handling binary files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_17.html">previous</A>,
<A HREF="cvs_19.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC83" HREF="cvs_toc.html#TOC83">Handling binary files</A></H1>
-<P>
-<A NAME="IDX288"></A>
-
-</P>
-<P>
-There are two issues with using CVS to store
-binary files. The first is that CVS by default
-convert line endings between the canonical form in
-which they are stored in the repository (linefeed
-only), and the form appropriate to the operating system
-in use on the client (for example, carriage return
-followed by line feed for Windows NT).
-
-</P>
-<P>
-The second is that a binary file might happen to
-contain data which looks like a keyword (see section <A
HREF="cvs_17.html#SEC77">Keyword substitution</A>), so keyword expansion must
be turned
-off.
-
-</P>
-<P>
-The <SAMP>`-kb'</SAMP> option available with some CVS
-commands insures that neither line ending conversion
-nor keyword expansion will be done. If you are using
-an old version of RCS without this option, and you
-are using an operating system, such as unix, which
-terminates lines with linefeeds only, you can use
-<SAMP>`-ko'</SAMP> instead; if you are on another operating
-system, upgrade to a version of RCS, such as 5.7
-or later, which supports <SAMP>`-kb'</SAMP>.
-
-</P>
-<P>
-Here is an example of how you can create a new file
-using the <SAMP>`-kb'</SAMP> flag:
-
-</P>
-
-<PRE>
-$ echo '$Id: cvs_18.html,v 1.1 2003/11/07 20:55:32 sinuhe Exp $' > kotest
-$ cvs add -kb -m"A test file" kotest
-$ cvs ci -m"First checkin; contains a keyword" kotest
-</PRE>
-
-<P>
-If a file accidentally gets added without <SAMP>`-kb'</SAMP>,
-one can use the <CODE>cvs admin</CODE> command to recover.
-For example:
-
-</P>
-
-<PRE>
-$ echo '$Id: cvs_18.html,v 1.1 2003/11/07 20:55:32 sinuhe Exp $' > kotest
-$ cvs add -m"A test file" kotest
-$ cvs ci -m"First checkin; contains a keyword" kotest
-$ cvs admin -kb kotest
-$ cvs update -A kotest
-$ cvs commit -m "make it binary" kotest # For non-unix systems
-</PRE>
-
-<P>
-When you check in the file <TT>`kotest'</TT> the keywords
-are expanded. (Try the above example, and do a
-<CODE>cat kotest</CODE> after every command). The <CODE>cvs
-admin -kb</CODE> command sets the default keyword
-substitution method for this file, but it does not
-alter the working copy of the file that you have. The
-easiest way to get the unexpanded version of
-<TT>`kotest'</TT> is <CODE>cvs update -A</CODE>. If you need to
-cope with line endings (that is, you are using a
-CVS client on a non-unix system), then you need to
-check in a new copy of the file, as shown by the
-<CODE>cvs commit</CODE> command above.
-
-</P>
-<P>
-However, in using <CODE>cvs admin -k</CODE> to change the
-keyword expansion, be aware that the keyword expansion
-mode is not version controlled. This means that, for
-example, that if you have a text file in old releases,
-and a binary file with the same name in new releases,
-CVS provides no way to check out the file in text
-or binary mode depending on what version you are
-checking out. There is no good workaround for this
-problem.
-
-</P>
-<P>
-You can also set a default for whether <CODE>cvs add</CODE>
-and <CODE>cvs import</CODE> treat a file as binary based on
-its name; for example you could say that files who
-names end in <SAMP>`.exe'</SAMP> are binary. See section <A
HREF="cvs_21.html#SEC138">The cvswrappers file</A>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_17.html">previous</A>,
<A HREF="cvs_19.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_19.html
===================================================================
RCS file: manual/html_chapter/cvs_19.html
diff -N manual/html_chapter/cvs_19.html
--- manual/html_chapter/cvs_19.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,75 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Revision management</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_18.html">previous</A>,
<A HREF="cvs_20.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC84" HREF="cvs_toc.html#TOC84">Revision management</A></H1>
-<P>
-<A NAME="IDX289"></A>
-
-</P>
-
-<P>
-If you have read this far, you probably have a pretty
-good grasp on what CVS can do for you. This
-chapter talks a little about things that you still have
-to decide.
-
-</P>
-<P>
-If you are doing development on your own using CVS
-you could probably skip this chapter. The questions
-this chapter takes up become more important when more
-than one person is working in a repository.
-
-</P>
-
-
-
-<H2><A NAME="SEC85" HREF="cvs_toc.html#TOC85">When to commit?</A></H2>
-<P>
-<A NAME="IDX290"></A>
-<A NAME="IDX291"></A>
-<A NAME="IDX292"></A>
-
-</P>
-<P>
-Your group should decide which policy to use regarding
-commits. Several policies are possible, and as your
-experience with CVS grows you will probably find
-out what works for you.
-
-</P>
-<P>
-If you commit files too quickly you might commit files
-that do not even compile. If your partner updates his
-working sources to include your buggy file, he will be
-unable to compile the code. On the other hand, other
-persons will not be able to benefit from the
-improvements you make to the code if you commit very
-seldom, and conflicts will probably be more common.
-
-</P>
-<P>
-It is common to only commit files after making sure
-that they can be compiled. Some sites require that the
-files pass a test suite. Policies like this can be
-enforced using the commitinfo file
-(see section <A HREF="cvs_21.html#SEC141">Commitinfo</A>), but you should
think twice before
-you enforce such a convention. By making the
-development environment too controlled it might become
-too regimented and thus counter-productive to the real
-goal, which is to get software written.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_18.html">previous</A>,
<A HREF="cvs_20.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_2.html
===================================================================
RCS file: manual/html_chapter/cvs_2.html
diff -N manual/html_chapter/cvs_2.html
--- manual/html_chapter/cvs_2.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,247 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - What is CVS?</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_1.html">previous</A>,
<A HREF="cvs_3.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC5" HREF="cvs_toc.html#TOC5">What is CVS?</A></H1>
-<P>
-<A NAME="IDX12"></A>
-<A NAME="IDX13"></A>
-<A NAME="IDX14"></A>
-
-</P>
-<P>
-CVS is a version control system. Using it, you can
-record the history of your source files.
-
-</P>
-
-<P>
-For example, bugs sometimes creep in when
-software is modified, and you might not detect the bug
-until a long time after you make the modification.
-With CVS, you can easily retrieve old versions to see
-exactly which change caused the bug. This can
-sometimes be a big help.
-
-</P>
-<P>
-You could of course save every version of every file
-you have ever created. This would
-however waste an enormous amount of disk space. CVS
-stores all the versions of a file in a single file in a
-clever way that only stores the differences between
-versions.
-
-</P>
-<P>
-CVS also helps you if you are part of a group of people working
-on the same project. It is all too easy to overwrite
-each others' changes unless you are extremely careful.
-Some editors, like GNU Emacs, try to make sure that
-the same file is never modified by two people at the
-same time. Unfortunately, if someone is using another
-editor, that safeguard will not work. CVS solves this problem
-by insulating the different developers from each other. Every
-developer works in his own directory, and CVS merges
-the work when each developer is done.
-
-</P>
-<P>
-<A NAME="IDX15"></A>
-<A NAME="IDX16"></A>
-<A NAME="IDX17"></A>
-<A NAME="IDX18"></A>
-CVS started out as a bunch of shell scripts written by
-Dick Grune, posted to <CODE>comp.sources.unix</CODE> in the volume 6
-release of December, 1986. While no actual code from
-these shell scripts is present in the current version
-of CVS much of the CVS conflict resolution algorithms
-come from them.
-
-</P>
-<P>
-In April, 1989, Brian Berliner designed and coded CVS.
-Jeff Polk later helped Brian with the design of the CVS
-module and vendor branch support.
-
-</P>
-<P>
-<A NAME="IDX19"></A>
-You can get CVS via anonymous ftp from a number of
-sites, for instance <TT>prep.ai.mit.edu</TT> in
-<TT>`pub/gnu'</TT>.
-
-</P>
-<P>
-<A NAME="IDX20"></A>
-<A NAME="IDX21"></A>
-<A NAME="IDX22"></A>
-There is a mailing list, known as <CODE>info-cvs</CODE>,
-devoted to CVS. To subscribe or
-unsubscribe
-send a message to
-<CODE>address@hidden</CODE>. Please be
-specific about your email address. As of May 1996,
-subscription requests are handled by a busy human
-being, so you cannot expect to be added or removed
-immediately. The usenet group
-<CODE>comp.software.config-mgmt</CODE> is also a suitable
-place for CVS discussions (along with other
-configuration management systems).
-
-</P>
-
-
-
-<H2><A NAME="SEC6" HREF="cvs_toc.html#TOC6">CVS is not...</A></H2>
-
-<P>
-CVS can do a lot of things for you, but it does
-not try to be everything for everyone.
-
-</P>
-<DL COMPACT>
-
-<DT>CVS is not a build system.
-<DD>
-Though the structure of your repository and modules
-file interact with your build system
-(e.g. <TT>`Makefile'</TT>s), they are essentially
-independent.
-
-CVS does not dictate how you build anything. It
-merely stores files for retrieval in a tree structure
-you devise.
-
-CVS does not dictate how to use disk space in the
-checked out working directories. If you write your
-<TT>`Makefile'</TT>s or scripts in every directory so they
-have to know the relative positions of everything else,
-you wind up requiring the entire repository to be
-checked out.
-
-If you modularize your work, and construct a build
-system that will share files (via links, mounts,
-<CODE>VPATH</CODE> in <TT>`Makefile'</TT>s, etc.), you can
-arrange your disk usage however you like.
-
-But you have to remember that <EM>any</EM> such system is
-a lot of work to construct and maintain. CVS does
-not address the issues involved.
-
-Of course, you should place the tools created to
-support such a build system (scripts, <TT>`Makefile'</TT>s,
-etc) under CVS.
-
-Figuring out what files need to be rebuilt when
-something changes is, again, something to be handled
-outside the scope of CVS. One traditional
-approach is to use <CODE>make</CODE> for building, and use
-some automated tool for generating the depencies which
-<CODE>make</CODE> uses.
-
-<DT>CVS is not a substitute for management.
-<DD>
-Your managers and project leaders are expected to talk
-to you frequently enough to make certain you are aware
-of schedules, merge points, branch names and release
-dates. If they don't, CVS can't help.
-
-CVS is an instrument for making sources dance to
-your tune. But you are the piper and the composer. No
-instrument plays itself or writes its own music.
-
-<DT>CVS is not a substitute for developer communication.
-<DD>
-When faced with conflicts within a single file, most
-developers manage to resolve them without too much
-effort. But a more general definition of "conflict"
-includes problems too difficult to solve without
-communication between developers.
-
-CVS cannot determine when simultaneous changes
-within a single file, or across a whole collection of
-files, will logically conflict with one another. Its
-concept of a <EM>conflict</EM> is purely textual, arising
-when two changes to the same base file are near enough
-to spook the merge (i.e. <CODE>diff3</CODE>) command.
-
-CVS does not claim to help at all in figuring out
-non-textual or distributed conflicts in program logic.
-
-For example: Say you change the arguments to function
-<CODE>X</CODE> defined in file <TT>`A'</TT>. At the same time,
-someone edits file <TT>`B'</TT>, adding new calls to
-function <CODE>X</CODE> using the old arguments. You are
-outside the realm of CVS's competence.
-
-Acquire the habit of reading specs and talking to your
-peers.
-
-<DT>CVS does not have change control
-<DD>
-Change control refers to a number of things. First of
-all it can mean <EM>bug-tracking</EM>, that is being able
-to keep a database of reported bugs and the status of
-each one (is it fixed? in what release? has the bug
-submitter agreed that it is fixed?). For interfacing
-CVS to an external bug-tracking system, see the
-<TT>`rcsinfo'</TT> and <TT>`editinfo'</TT> files
-(see section <A HREF="cvs_21.html#SEC136">Reference manual for the
Administrative files</A>).
-
-Another aspect of change control is keeping track of
-the fact that changes to several files were in fact
-changed together as one logical change. If you check
-in several files in a single <CODE>cvs commit</CODE>
-operation, CVS then forgets that those files were
-checked in together, and the fact that they have the
-same log message is the only thing tying them
-together. Keeping a GNU style <TT>`ChangeLog'</TT>
-can help somewhat.
-
-Another aspect of change control, in some systems, is
-the ability to keep track of the status of each
-change. Some changes have been written by a developer,
-others have been reviewed by a second developer, and so
-on. Generally, the way to do this with CVS is to
-generate a diff (using <CODE>cvs diff</CODE> or <CODE>diff</CODE>)
-and email it to someone who can then apply it using the
-<CODE>patch</CODE> utility. This is very flexible, but
-depends on mechanisms outside CVS to make sure
-nothing falls through the cracks.
-
-<DT>CVS is not an automated testing program
-<DD>
-It should be possible to enforce mandatory use of a
-testsuite using the <CODE>commitinfo</CODE> file. I haven't
-heard a lot about projects trying to do that or whether
-there are subtle gotchas, however.
-
-<DT>CVS does not have a builtin process model
-<DD>
-Some systems provide ways to ensure that changes or
-releases go through various steps, with various
-approvals as needed. Generally, one can accomplish
-this with CVS but it might be a little more work.
-In some cases you'll want to use the <TT>`commitinfo'</TT>,
-<TT>`loginfo'</TT>, <TT>`rcsinfo'</TT>, or <TT>`editinfo'</TT>
-files, to require that certain steps be performed
-before cvs will allow a checkin. Also consider whether
-features such as branches and tags can be used to
-perform tasks such as doing work in a development tree
-and then merging certain changes over to a stable tree
-only once they have been proven.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_1.html">previous</A>,
<A HREF="cvs_3.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_20.html
===================================================================
RCS file: manual/html_chapter/cvs_20.html
diff -N manual/html_chapter/cvs_20.html
--- manual/html_chapter/cvs_20.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,3145 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Reference manual for CVS
commands</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_19.html">previous</A>,
<A HREF="cvs_21.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC86" HREF="cvs_toc.html#TOC86">Reference manual for CVS
commands</A></H1>
-<P>
-<A NAME="IDX293"></A>
-<A NAME="IDX294"></A>
-<A NAME="IDX295"></A>
-
-</P>
-
-<P>
-This appendix describes how to invoke CVS, and
-describes in detail those subcommands of CVS which
-are not fully described elsewhere. To look up a
-particular subcommand, see section <A HREF="cvs_25.html#SEC155">Index</A>.
-
-</P>
-
-
-
-<H2><A NAME="SEC87" HREF="cvs_toc.html#TOC87">Overall structure of CVS
commands</A></H2>
-<P>
-<A NAME="IDX296"></A>
-<A NAME="IDX297"></A>
-<A NAME="IDX298"></A>
-<A NAME="IDX299"></A>
-
-</P>
-<P>
-The overall format of all CVS commands is:
-
-</P>
-
-<PRE>
-cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
-</PRE>
-
-<DL COMPACT>
-
-<DT><CODE>cvs</CODE>
-<DD>
-The name of the CVS program.
-
-<DT><CODE>cvs_options</CODE>
-<DD>
-Some options that affect all sub-commands of CVS. These are
-described below.
-
-<DT><CODE>cvs_command</CODE>
-<DD>
-One of several different sub-commands. Some of the commands have
-aliases that can be used instead; those aliases are noted in the
-reference manual for that command. There are only two situations
-where you may omit <SAMP>`cvs_command'</SAMP>: <SAMP>`cvs -H'</SAMP> elicits a
-list of available commands, and <SAMP>`cvs -v'</SAMP> displays version
-information on CVS itself.
-
-<DT><CODE>command_options</CODE>
-<DD>
-Options that are specific for the command.
-
-<DT><CODE>command_args</CODE>
-<DD>
-Arguments to the commands.
-</DL>
-
-<P>
-There is unfortunately some confusion between
-<CODE>cvs_options</CODE> and <CODE>command_options</CODE>.
-<SAMP>`-l'</SAMP>, when given as a <CODE>cvs_option</CODE>, only
-affects some of the commands. When it is given as a
-<CODE>command_option</CODE> is has a different meaning, and
-is accepted by more commands. In other words, do not
-take the above categorization too seriously. Look at
-the documentation instead.
-
-</P>
-
-
-<H2><A NAME="SEC88" HREF="cvs_toc.html#TOC88">Default options and the ~/.cvsrc
file</A></H2>
-<P>
-<A NAME="IDX300"></A>
-<A NAME="IDX301"></A>
-
-</P>
-<P>
-There are some <CODE>command_options</CODE> that are used so
-often that you might have set up an alias or some other
-means to make sure you always specify that option. One
-example (the one that drove the implementation of the
-.cvsrc support, actually) is that many people find the
-default output of the <SAMP>`diff'</SAMP> command to be very
-hard to read, and that either context diffs or unidiffs
-are much easier to understand.
-
-</P>
-<P>
-The <TT>`~/.cvsrc'</TT> file is a way that you can add
-default options to <CODE>cvs_commands</CODE> within cvs,
-instead of relying on aliases or other shell scripts.
-
-</P>
-<P>
-The format of the <TT>`~/.cvsrc'</TT> file is simple. The
-file is searched for a line that begins with the same
-name as the <CODE>cvs_command</CODE> being executed. If a
-match is found, then the remainder of the line is split
-up (at whitespace characters) into separate options and
-added to the command arguments <EM>before</EM> any
-options from the command line.
-
-</P>
-<P>
-If a command has two names (e.g., <CODE>checkout</CODE> and
-<CODE>co</CODE>), the official name, not necessarily the one
-used on the command line, will be used to match against
-the file. So if this is the contents of the user's
-<TT>`~/.cvsrc'</TT> file:
-
-</P>
-
-<PRE>
-log -N
-diff -u
-update -P
-co -P
-</PRE>
-
-<P>
-the command <SAMP>`cvs checkout foo'</SAMP> would have the
-<SAMP>`-P'</SAMP> option added to the arguments, as well as
-<SAMP>`cvs co foo'</SAMP>.
-
-</P>
-<P>
-With the example file above, the output from <SAMP>`cvs
-diff foobar'</SAMP> will be in unidiff format. <SAMP>`cvs diff
--c foobar'</SAMP> will provide context diffs, as usual.
-Getting "old" format diffs would be slightly more
-complicated, because <CODE>diff</CODE> doesn't have an option
-to specify use of the "old" format, so you would need
-<SAMP>`cvs -f diff foobar'</SAMP>.
-
-</P>
-<P>
-In place of the command name you can use <CODE>cvs</CODE> to
-specify global options (see section <A HREF="cvs_20.html#SEC89">Global
options</A>). For
-example the following line in <TT>`.cvsrc'</TT>
-
-</P>
-
-<PRE>
-cvs -z6
-</PRE>
-
-<P>
-causes CVS to use compression level 6
-
-</P>
-
-
-<H2><A NAME="SEC89" HREF="cvs_toc.html#TOC89">Global options</A></H2>
-<P>
-<A NAME="IDX302"></A>
-<A NAME="IDX303"></A>
-<A NAME="IDX304"></A>
-
-</P>
-<P>
-The available <SAMP>`cvs_options'</SAMP> (that are given to the
-left of <SAMP>`cvs_command'</SAMP>) are:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b <VAR>bindir</VAR></CODE>
-<DD>
-<A NAME="IDX305"></A>
- <A NAME="IDX306"></A>
-
-Use <VAR>bindir</VAR> as the directory where RCS programs are
-located. Overrides the setting of the <CODE>$RCSBIN</CODE> environment
-variable and any precompiled directory. This parameter should be
-specified as an absolute pathname.
-
-<A NAME="IDX307"></A>
-<A NAME="IDX308"></A>
-<DT><CODE>-T <VAR>tempdir</VAR></CODE>
-<DD>
-Use <VAR>tempdir</VAR> as the directory where temporary files are
-located. Overrides the setting of the <CODE>$TMPDIR</CODE> environment
-variable and any precompiled directory. This parameter should be
-specified as an absolute pathname.
-
-<A NAME="IDX309"></A>
-<A NAME="IDX310"></A>
-<DT><CODE>-d <VAR>cvs_root_directory</VAR></CODE>
-<DD>
-Use <VAR>cvs_root_directory</VAR> as the root directory
-pathname of the repository. Overrides the setting of
-the <CODE>$CVSROOT</CODE> environment variable. See section <A
HREF="cvs_5.html#SEC15">The Repository</A>.
-
-<A NAME="IDX311"></A>
-<A NAME="IDX312"></A>
-<DT><CODE>-e <VAR>editor</VAR></CODE>
-<DD>
-Use <VAR>editor</VAR> to enter revision log information. Overrides the
-setting of the <CODE>$CVSEDITOR</CODE> and <CODE>$EDITOR</CODE> environment
variables.
-
-<DT><CODE>-f</CODE>
-<DD>
-Do not read the <TT>`~/.cvsrc'</TT> file. This
-option is most often used because of the
-non-orthogonality of the CVS option set. For
-example, the <SAMP>`cvs log'</SAMP> option <SAMP>`-N'</SAMP> (turn off
-display of tag names) does not have a corresponding
-option to turn the display on. So if you have
-<SAMP>`-N'</SAMP> in the <TT>`~/.cvsrc'</TT> entry for <SAMP>`log'</SAMP>,
-you may need to use <SAMP>`-f'</SAMP> to show the tag names.
-
-<DT><CODE>-H</CODE>
-<DD>
-Display usage information about the specified <SAMP>`cvs_command'</SAMP>
-(but do not actually execute the command). If you don't specify
-a command name, <SAMP>`cvs -H'</SAMP> displays a summary of all the
-commands available.
-
-<DT><CODE>-l</CODE>
-<DD>
-Do not log the cvs_command in the command history (but execute it
-anyway). See section <A HREF="cvs_20.html#SEC110">history--Show status of
files and users</A>, for information on command history.
-
-<A NAME="IDX313"></A>
-<DT><CODE>-n</CODE>
-<DD>
-Do not change any files. Attempt to execute the
-<SAMP>`cvs_command'</SAMP>, but only to issue reports; do not remove,
-update, or merge any existing files, or create any new files.
-
-<DT><CODE>-Q</CODE>
-<DD>
-Cause the command to be really quiet; the command will only
-generate output for serious problems.
-
-<DT><CODE>-q</CODE>
-<DD>
-Cause the command to be somewhat quiet; informational messages,
-such as reports of recursion through subdirectories, are
-suppressed.
-
-<A NAME="IDX314"></A>
-<DT><CODE>-r</CODE>
-<DD>
-Make new working files files read-only. Same effect
-as if the <CODE>$CVSREAD</CODE> environment variable is set
-(see section <A HREF="cvs_22.html#SEC151">All environment variables which
affect CVS</A>). The default is to
-make working files writable, unless watches are on
-(see section <A HREF="cvs_7.html#SEC43">Mechanisms to track who is editing
files</A>).
-
-<DT><CODE>-s <VAR>variable</VAR>=<VAR>value</VAR></CODE>
-<DD>
-Set a user variable (see section <A HREF="cvs_21.html#SEC150">Expansions in
administrative files</A>).
-
-<A NAME="IDX315"></A>
-<DT><CODE>-t</CODE>
-<DD>
-Trace program execution; display messages showing the steps of
-CVS activity. Particularly useful with <SAMP>`-n'</SAMP> to explore the
-potential impact of an unfamiliar command.
-
-<DT><CODE>-v</CODE>
-<DD>
-Display version and copyright information for CVS.
-
-<A NAME="IDX316"></A>
-<A NAME="IDX317"></A>
-<DT><CODE>-w</CODE>
-<DD>
-Make new working files read-write. Overrides the
-setting of the <CODE>$CVSREAD</CODE> environment variable.
-Files are created read-write by default, unless <CODE>$CVSREAD</CODE> is
-set or <SAMP>`-r'</SAMP> is given.
-
-<DT><CODE>-x</CODE>
-<DD>
-Encrypt all communication between the client and the
-server. Only has an effect on the CVS client. As
-of this writing, this is only implemented when using a
-Kerberos connection (see section <A HREF="cvs_5.html#SEC30">Direct connection
with kerberos</A>).
-Encryption support is not available by default; it must
-be enabled using a special configure option,
-<TT>`--enable-encryption'</TT>, when you build CVS.
-
-<DT><CODE>-z <VAR>gzip-level</VAR></CODE>
-<DD>
-Set the compression level. Only has an effect on the
-CVS client.
-
-</DL>
-
-
-
-<H2><A NAME="SEC90" HREF="cvs_toc.html#TOC90">Common command options</A></H2>
-<P>
-<A NAME="IDX318"></A>
-<A NAME="IDX319"></A>
-
-</P>
-<P>
-This section describes the <SAMP>`command_options'</SAMP> that
-are available across several CVS commands. These
-options are always given to the right of
-<SAMP>`cvs_command'</SAMP>. Not all
-commands support all of these options; each option is
-only supported for commands where it makes sense.
-However, when a command has one of these options you
-can almost always count on the same behavior of the
-option as in other commands. (Other command options,
-which are listed with the individual commands, may have
-different behavior from one CVS command to the other).
-
-</P>
-<P>
-<STRONG>Warning:</STRONG> the <SAMP>`history'</SAMP> command is an exception;
it supports
-many options that conflict even with these standard options.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date_spec</VAR></CODE>
-<DD>
-<A NAME="IDX320"></A>
- <A NAME="IDX321"></A>
- <A NAME="IDX322"></A>
-
-Use the most recent revision no later than <VAR>date_spec</VAR>.
-<VAR>date_spec</VAR> is a single argument, a date description
-specifying a date in the past.
-
-The specification is <EM>sticky</EM> when you use it to make a
-private copy of a source file; that is, when you get a working
-file using <SAMP>`-D'</SAMP>, CVS records the date you specified, so that
-further updates in the same directory will use the same date
-(for more information on sticky tags/dates, see section <A
HREF="cvs_8.html#SEC54">Sticky tags</A>).
-
-<A NAME="IDX323"></A>
-<A NAME="IDX324"></A>
-A wide variety of date formats are supported by
-CVS. The <VAR>date_spec</VAR> is interpreted as being
-in the local timezone, unless a specific timezone is
-specified. Examples of valid date specifications
-include:
-
-
-<PRE>
- 1 month ago
- 2 hours ago
- 400000 seconds ago
- last year
- last Monday
- yesterday
- a fortnight ago
- 3/31/92 10:00:07 PST
- January 23, 1987 10:05pm
- 22:00 GMT
-</PRE>
-
-<SAMP>`-D'</SAMP> is available with the <CODE>checkout</CODE>,
-<CODE>diff</CODE>, <CODE>export</CODE>, <CODE>history</CODE>,
-<CODE>rdiff</CODE>, <CODE>rtag</CODE>, and <CODE>update</CODE> commands.
-(The <CODE>history</CODE> command uses this option in a
-slightly different way; see section <A HREF="cvs_20.html#SEC111">history
options</A>). Note
-that when specifying a date like <SAMP>`3/31/92'</SAMP> it is
-<CODE><VAR>month</VAR>/<VAR>day</VAR>/<VAR>year</VAR></CODE>. So
-<SAMP>`1/4/96'</SAMP> is January 4, not March 1.
-
-Remember to quote the argument to the <SAMP>`-D'</SAMP>
-flag so that your shell doesn't interpret spaces as
-argument separators. A command using the <SAMP>`-D'</SAMP>
-flag can look like this:
-
-
-<PRE>
-$ cvs diff -D "1 hour ago" cvs.texinfo
-</PRE>
-
-<A NAME="IDX325"></A>
-<DT><CODE>-f</CODE>
-<DD>
-When you specify a particular date or tag to CVS commands, they
-normally ignore files that do not contain the tag (or did not
-exist prior to the date) that you specified. Use the <SAMP>`-f'</SAMP> option
-if you want files retrieved even when there is no match for the
-tag or date. (The most recent revision of the file
-will be used).
-
-<SAMP>`-f'</SAMP> is available with these commands: <CODE>checkout</CODE>,
-<CODE>export</CODE>, <CODE>rdiff</CODE>, <CODE>rtag</CODE>, and
<CODE>update</CODE>.
-
-<STRONG>Warning:</STRONG> The <CODE>commit</CODE> command also has a
-<SAMP>`-f'</SAMP> option, but it has a different behavior for
-that command. See section <A HREF="cvs_20.html#SEC100">commit options</A>.
-
-<DT><CODE>-H</CODE>
-<DD>
-Help; describe the options available for this command. This is
-the only option supported for all CVS commands.
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Alter the default RCS processing of keywords.
-See section <A HREF="cvs_17.html#SEC77">Keyword substitution</A>, for the
meaning of
-<VAR>kflag</VAR>. Your <VAR>kflag</VAR> specification is
-<EM>sticky</EM> when you use it to create a private copy
-of a source file; that is, when you use this option
-with the <CODE>checkout</CODE> or <CODE>update</CODE> commands,
-CVS associates your selected <VAR>kflag</VAR> with the
-file, and continues to use it with future update
-commands on the same file until you specify otherwise.
-
-The <SAMP>`-k'</SAMP> option is available with the <CODE>add</CODE>,
-<CODE>checkout</CODE>, <CODE>diff</CODE> and
-<CODE>update</CODE> commands.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory, rather than
-recursing through subdirectories.
-
-<STRONG>Warning:</STRONG> this is not the same
-as the overall <SAMP>`cvs -l'</SAMP> option, which you can specify to the
-left of a cvs command!
-
-Available with the following commands: <CODE>checkout</CODE>,
-<CODE>commit</CODE>, <CODE>diff</CODE>, <CODE>export</CODE>, <CODE>log</CODE>,
-<CODE>remove</CODE>, <CODE>rdiff</CODE>, <CODE>rtag</CODE>,
-<CODE>status</CODE>, <CODE>tag</CODE>, and <CODE>update</CODE>.
-
-<A NAME="IDX326"></A>
-<A NAME="IDX327"></A>
-<DT><CODE>-m <VAR>message</VAR></CODE>
-<DD>
-Use <VAR>message</VAR> as log information, instead of
-invoking an editor.
-
-Available with the following commands: <CODE>add</CODE>,
-<CODE>commit</CODE> and <CODE>import</CODE>.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any checkout/commit/tag program. (A program can be
-specified to run on each of these activities, in the modules
-database (see section <A HREF="cvs_21.html#SEC137">The modules file</A>); this
option bypasses it).
-
-<STRONG>Warning:</STRONG> this is not the same as the overall <SAMP>`cvs
-n'</SAMP>
-option, which you can specify to the left of a cvs command!
-
-Available with the <CODE>checkout</CODE>, <CODE>commit</CODE>,
<CODE>export</CODE>,
-and <CODE>rtag</CODE> commands.
-
-<DT><CODE>-P</CODE>
-<DD>
-Prune (remove) directories that are empty after being updated, on
-<CODE>checkout</CODE>, or <CODE>update</CODE>. Normally, an empty directory
-(one that is void of revision-controlled files) is left alone.
-Specifying <SAMP>`-P'</SAMP> will cause these directories to be silently
-removed from your checked-out sources. This does not remove the
-directory from the repository, only from your checked out copy.
-Note that this option is implied by the <SAMP>`-r'</SAMP> or <SAMP>`-D'</SAMP>
-options of <CODE>checkout</CODE> and <CODE>export</CODE>.
-
-<DT><CODE>-p</CODE>
-<DD>
-Pipe the files retrieved from the repository to standard output,
-rather than writing them in the current directory. Available
-with the <CODE>checkout</CODE> and <CODE>update</CODE> commands.
-
-<DT><CODE>-W</CODE>
-<DD>
-Specify file names that should be filtered. You can
-use this option repeatedly. The spec can be a file
-name pattern of the same type that you can specify in
-the <TT>`.cvswrappers'</TT> file.
-Avaliable with the following commands: <CODE>import</CODE>,
-and <CODE>update</CODE>.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use the revision specified by the <VAR>tag</VAR> argument instead of the
-default <EM>head</EM> revision. As well as arbitrary tags defined
-with the <CODE>tag</CODE> or <CODE>rtag</CODE> command, two special tags are
-always available: <SAMP>`HEAD'</SAMP> refers to the most recent version
-available in the repository, and <SAMP>`BASE'</SAMP> refers to the
-revision you last checked out into the current working directory.
-
-The tag specification is sticky when you use this
-with <CODE>checkout</CODE> or <CODE>update</CODE> to make your own
-copy of a file: CVS remembers the tag and continues to use it on
-future update commands, until you specify otherwise (for more information
-on sticky tags/dates, see section <A HREF="cvs_8.html#SEC54">Sticky tags</A>).
The
-tag can be either a symbolic or numeric tag.
-See section <A HREF="cvs_8.html#SEC51">Tags--Symbolic revisions</A>.
-
-Specifying the <SAMP>`-q'</SAMP> global option along with the
-<SAMP>`-r'</SAMP> command option is often useful, to suppress
-the warning messages when the RCS history file
-does not contain the specified tag.
-
-<STRONG>Warning:</STRONG> this is not the same as the overall `cvs -r' option,
-which you can specify to the left of a cvs command!
-
-<SAMP>`-r'</SAMP> is available with the <CODE>checkout</CODE>,
<CODE>commit</CODE>,
-<CODE>diff</CODE>, <CODE>history</CODE>, <CODE>export</CODE>,
<CODE>rdiff</CODE>,
-<CODE>rtag</CODE>, and <CODE>update</CODE> commands.
-
-</DL>
-
-
-
-<H2><A NAME="SEC91" HREF="cvs_toc.html#TOC91">admin--Administration front end
for rcs</A></H2>
-<P>
-<A NAME="IDX328"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Requires: repository, working directory.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: rcs
-</UL>
-
-<P>
-This is the CVS interface to assorted administrative RCS
-facilities, documented in rcs(1). <CODE>admin</CODE> simply passes
-all its options and arguments to the <CODE>rcs</CODE> command; it does
-no filtering or other processing. This command <EM>does</EM> work
-recursively, however, so extreme care should be used.
-
-</P>
-<P>
-If there is a group whose name matches a compiled in
-value which defaults to <CODE>cvsadmin</CODE>, only members
-of that group can use <CODE>cvs admin</CODE>. To disallow
-<CODE>cvs admin</CODE> for all users, create a group with no
-users in it.
-
-</P>
-
-
-
-<H3><A NAME="SEC92" HREF="cvs_toc.html#TOC92">admin options</A></H3>
-
-<P>
-Not all valid <CODE>rcs</CODE> options are useful together
-with CVS. Some even makes it impossible to use
-CVS until you undo the effect!
-
-</P>
-<P>
-This description of the available options is based on
-the <SAMP>`rcs(1)'</SAMP> man page, but modified to suit
-readers that are more interrested in CVS than
-RCS.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-A<VAR>oldfile</VAR></CODE>
-<DD>
-Might not work together with CVS. Append the
-access list of <VAR>oldfile</VAR> to the access list of the
-RCS file.
-
-<DT><CODE>-a<VAR>logins</VAR></CODE>
-<DD>
-Might not work together with CVS. Append the
-login names appearing in the comma-separated list
-<VAR>logins</VAR> to the access list of the RCS file.
-
-<DT><CODE>-b[<VAR>rev</VAR>]</CODE>
-<DD>
-When used with bare RCS, this
-option sets the default branch to <VAR>rev</VAR>; in
-CVS sticky tags (see section <A HREF="cvs_8.html#SEC54">Sticky tags</A>) are a
better
-way to decide which branch you want to work on. With
-CVS, this option can be used to control behavior
-with respect to the vendor branch.
-
-<DT><CODE>-c<VAR>string</VAR></CODE>
-<DD>
-Useful with CVS. Sets the comment leader to
-<VAR>string</VAR>. The comment leader is printed before
-every log message line generated by the keyword
-<CODE>$</CODE>Log$ (see section <A HREF="cvs_17.html#SEC77">Keyword
substitution</A>).
-This is useful for programming languages without
-multi-line comments. RCS initially guesses the
-value of the comment leader from the file name
-extension when the file is first committed.
-
-<DT><CODE>-e[<VAR>logins</VAR>]</CODE>
-<DD>
-Might not work together with CVS. Erase the login
-names appearing in the comma-separated list
-<VAR>logins</VAR> from the access list of the RCS file. If
-<VAR>logins</VAR> is omitted, erase the entire access list.
-
-<DT><CODE>-I</CODE>
-<DD>
-Run interactively, even if the standard input is not a
-terminal.
-
-<DT><CODE>-i</CODE>
-<DD>
-Useless with CVS. When using bare RCS, this
-is used to create and initialize a new RCS file,
-without depositing a revision.
-
-<DT><CODE>-k<VAR>subst</VAR></CODE>
-<DD>
-Useful with CVS. Set the default keyword
-substitution to <VAR>subst</VAR>. See section <A
HREF="cvs_17.html#SEC77">Keyword substitution</A>. Giving an explicit
<SAMP>`-k'</SAMP> option to
-<CODE>cvs update</CODE>, <CODE>cvs export</CODE>, or <CODE>cvs
-checkout</CODE> overrides this default.
-
-<DT><CODE>-l[<VAR>rev</VAR>]</CODE>
-<DD>
-Lock the revision with number <VAR>rev</VAR>. If a branch
-is given, lock the latest revision on that branch. If
-<VAR>rev</VAR> is omitted, lock the latest revision on the
-default branch.
-
-This can be used in conjunction with the
-<TT>`rcslock.pl'</TT> script in the <TT>`contrib'</TT>
-directory of the CVS source distribution to
-provide reserved checkouts (where only one user can be
-editing a given file at a time). See the comments in
-that file for details (and see the <TT>`README'</TT> file
-in that directory for disclaimers about the unsupported
-nature of contrib). According to comments in that
-file, locking must set to strict (which is the default).
-
-<DT><CODE>-L</CODE>
-<DD>
-Set locking to strict. Strict locking means that the
-owner of an RCS file is not exempt from locking for
-checkin. For use with CVS, strict locking must be
-set; see the discussion under the <SAMP>`-l'</SAMP> option above.
-
-<A NAME="IDX329"></A>
-<A NAME="IDX330"></A>
-<A NAME="IDX331"></A>
-<A NAME="IDX332"></A>
-<A NAME="IDX333"></A>
-<DT><CODE>-m<VAR>rev</VAR>:<VAR>msg</VAR></CODE>
-<DD>
-Replace the log message of revision <VAR>rev</VAR> with
-<VAR>msg</VAR>.
-
-<DT><CODE>-N<VAR>name</VAR>[:[<VAR>rev</VAR>]]</CODE>
-<DD>
-Act like <SAMP>`-n'</SAMP>, except override any previous
-assignment of <VAR>name</VAR>.
-
-<DT><CODE>-n<VAR>name</VAR>[:[<VAR>rev</VAR>]]</CODE>
-<DD>
-Associate the symbolic name <VAR>name</VAR> with the branch
-or revision <VAR>rev</VAR>. It is normally better to use
-<SAMP>`cvs tag'</SAMP> or <SAMP>`cvs rtag'</SAMP> instead. Delete the
-symbolic name if both <SAMP>`:'</SAMP> and <VAR>rev</VAR> are
-omitted; otherwise, print an error message if
-<VAR>name</VAR> is already associated with another number.
-If <VAR>rev</VAR> is symbolic, it is expanded before
-association. A <VAR>rev</VAR> consisting of a branch number
-followed by a <SAMP>`.'</SAMP> stands for the current latest
-revision in the branch. A <SAMP>`:'</SAMP> with an empty
-<VAR>rev</VAR> stands for the current latest revision on the
-default branch, normally the trunk. For example,
-<SAMP>`rcs -n<VAR>name</VAR>: RCS/*'</SAMP> associates <VAR>name</VAR> with the
-current latest revision of all the named RCS files;
-this contrasts with <SAMP>`rcs -n<VAR>name</VAR>:$ RCS/*'</SAMP> which
-associates <VAR>name</VAR> with the revision numbers
-extracted from keyword strings in the corresponding
-working files.
-
-<A NAME="IDX334"></A>
-<A NAME="IDX335"></A>
-<A NAME="IDX336"></A>
-<DT><CODE>-o<VAR>range</VAR></CODE>
-<DD>
-Potentially useful, but dangerous, with CVS (see below).
-Deletes (<EM>outdates</EM>) the revisions given by
-<VAR>range</VAR>. A range consisting of a single revision
-number means that revision. A range consisting of a
-branch number means the latest revision on that branch.
-A range of the form <SAMP>`<VAR>rev1</VAR>:<VAR>rev2</VAR>'</SAMP> means
-revisions <VAR>rev1</VAR> to <VAR>rev2</VAR> on the same branch,
-<SAMP>`:<VAR>rev</VAR>'</SAMP> means from the beginning of the
-branch containing <VAR>rev</VAR> up to and including
-<VAR>rev</VAR>, and <SAMP>`<VAR>rev</VAR>:'</SAMP> means from revision
-<VAR>rev</VAR> to the end of the branch containing
-<VAR>rev</VAR>. None of the outdated revisions may have
-branches or locks.
-
-Due to the way CVS handles branches <VAR>rev</VAR>
-cannot be specified symbolically if it is a branch.
-See section <A HREF="cvs_23.html#SEC153">Magic branch numbers</A>, for an
explanation.
-
-Make sure that no-one has checked out a copy of the
-revision you outdate. Strange things will happen if he
-starts to edit it and tries to check it back in. For
-this reason, this option is not a good way to take back
-a bogus commit; commit a new revision undoing the bogus
-change instead (see section <A HREF="cvs_9.html#SEC58">Merging differences
between any two revisions</A>).
-
-<DT><CODE>-q</CODE>
-<DD>
-Run quietly; do not print diagnostics.
-
-<DT><CODE>-s<VAR>state</VAR>[:<VAR>rev</VAR>]</CODE>
-<DD>
-Useful with CVS. Set the state attribute of the
-revision <VAR>rev</VAR> to <VAR>state</VAR>. If <VAR>rev</VAR> is a
-branch number, assume the latest revision on that
-branch. If <VAR>rev</VAR> is omitted, assume the latest
-revision on the default branch. Any identifier is
-acceptable for <VAR>state</VAR>. A useful set of states is
-<SAMP>`Exp'</SAMP> (for experimental), <SAMP>`Stab'</SAMP> (for
-stable), and <SAMP>`Rel'</SAMP> (for released). By default,
-the state of a new revision is set to <SAMP>`Exp'</SAMP> when
-it is created. The state is visible in the output from
-<VAR>cvs log</VAR> (see section <A HREF="cvs_20.html#SEC116">log--Print out
log information for files</A>), and in the
-<SAMP>`$'</SAMP>Log$ and <SAMP>`$'</SAMP>State$ keywords
-(see section <A HREF="cvs_17.html#SEC77">Keyword substitution</A>). Note that
CVS
-uses the <CODE>dead</CODE> state for its own purposes; to
-take a file to or from the <CODE>dead</CODE> state use
-commands like <CODE>cvs remove</CODE> and <CODE>cvs add</CODE>, not
-<CODE>cvs admin -s</CODE>.
-
-<DT><CODE>-t[<VAR>file</VAR>]</CODE>
-<DD>
-Useful with CVS. Write descriptive text from the
-contents of the named <VAR>file</VAR> into the RCS file,
-deleting the existing text. The <VAR>file</VAR> pathname
-may not begin with <SAMP>`-'</SAMP>. If <VAR>file</VAR> is omitted,
-obtain the text from standard input, terminated by
-end-of-file or by a line containing <SAMP>`.'</SAMP> by itself.
-Prompt for the text if interaction is possible; see
-<SAMP>`-I'</SAMP>. The descriptive text can be seen in the
-output from <SAMP>`cvs log'</SAMP> (see section <A
HREF="cvs_20.html#SEC116">log--Print out log information for files</A>).
-
-<DT><CODE>-t-<VAR>string</VAR></CODE>
-<DD>
-Similar to <SAMP>`-t<VAR>file</VAR>'</SAMP>. Write descriptive text
-from the <VAR>string</VAR> into the RCS file, deleting
-the existing text.
-
-<DT><CODE>-U</CODE>
-<DD>
-Set locking to non-strict. Non-strict locking means
-that the owner of a file need not lock a revision for
-checkin. For use with CVS, strict locking must be
-set; see the discussion under the <SAMP>`-l'</SAMP> option
-above.
-
-<DT><CODE>-u[<VAR>rev</VAR>]</CODE>
-<DD>
-See the option <SAMP>`-l'</SAMP> above, for a discussion of
-using this option with CVS. Unlock the revision
-with number <VAR>rev</VAR>. If a branch is given, unlock
-the latest revision on that branch. If <VAR>rev</VAR> is
-omitted, remove the latest lock held by the caller.
-Normally, only the locker of a revision may unlock it.
-Somebody else unlocking a revision breaks the lock.
-This causes a mail message to be sent to the original
-locker. The message contains a commentary solicited
-from the breaker. The commentary is terminated by
-end-of-file or by a line containing <CODE>.</CODE> by itself.
-
-<DT><CODE>-V<VAR>n</VAR></CODE>
-<DD>
-Emulate RCS version <VAR>n</VAR>. Use -V<VAR>n</VAR> to make
-an RCS file acceptable to RCS version <VAR>n</VAR>
-by discarding information that would confuse version
-<VAR>n</VAR>.
-
-<DT><CODE>-x<VAR>suffixes</VAR></CODE>
-<DD>
-Useless with CVS. Use <VAR>suffixes</VAR> to
-characterize RCS files.
-</DL>
-
-
-
-<H3><A NAME="SEC93" HREF="cvs_toc.html#TOC93">admin examples</A></H3>
-
-
-
-<H4><A NAME="SEC94" HREF="cvs_toc.html#TOC94">Outdating is dangerous</A></H4>
-
-<P>
-First, an example of how <EM>not</EM> to use the
-<CODE>admin</CODE> command. It is included to stress the
-fact that this command can be quite dangerous unless
-you know <EM>exactly</EM> what you are doing.
-
-</P>
-<P>
-The <SAMP>`-o'</SAMP> option can be used to <EM>outdate</EM> old revisions
-from the history file. If you are short on disc this option
-might help you. But think twice before using it--there is no
-way short of restoring the latest backup to undo this command!
-
-</P>
-<P>
-The next line is an example of a command that you would
-<EM>not</EM> like to execute.
-
-</P>
-
-<PRE>
-$ cvs admin -o:R_1_02 .
-</PRE>
-
-<P>
-The above command will delete all revisions up to, and
-including, the revision that corresponds to the tag
-R_1_02. But beware! If there are files that have not
-changed between R_1_02 and R_1_03 the file will have
-<EM>the same</EM> numerical revision number assigned to
-the tags R_1_02 and R_1_03. So not only will it be
-impossible to retrieve R_1_02; R_1_03 will also have to
-be restored from the tapes!
-
-</P>
-
-
-<H4><A NAME="SEC95" HREF="cvs_toc.html#TOC95">Comment leaders</A></H4>
-<P>
-<A NAME="IDX337"></A>
-<A NAME="IDX338"></A>
-<A NAME="IDX339"></A>
-
-</P>
-<P>
-If you use the <CODE>$</CODE>Log$ keyword and you do
-not agree with the guess for comment leader that
-CVS has done, you can enforce your will with
-<CODE>cvs admin -c</CODE>. This might be suitable for
-<CODE>nroff</CODE> source:
-
-</P>
-
-<PRE>
-$ cvs admin -c'.\" ' *.man
-$ rm *.man
-$ cvs update
-</PRE>
-
-<P>
-The two last steps are to make sure that you get the
-versions with correct comment leaders in your working
-files.
-
-</P>
-
-
-<H2><A NAME="SEC96" HREF="cvs_toc.html#TOC96">checkout--Check out sources for
editing</A></H2>
-<P>
-<A NAME="IDX340"></A>
-<A NAME="IDX341"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: checkout [options] modules...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: working directory.
-<LI>
-
-Synonyms: co, get
-</UL>
-
-<P>
-Make a working directory containing copies of the
-source files specified by <VAR>modules</VAR>. You must execute
-<CODE>checkout</CODE> before using most of the other CVS
-commands, since most of them operate on your working
-directory.
-
-</P>
-<P>
-The <VAR>modules</VAR> part of the command are either
-symbolic names for some
-collection of source directories and files, or paths to
-directories or files in the repository. The symbolic
-names are defined in the <SAMP>`modules'</SAMP> file.
-See section <A HREF="cvs_21.html#SEC137">The modules file</A>.
-
-</P>
-<P>
-Depending on the modules you specify, <CODE>checkout</CODE> may
-recursively create directories and populate them with
-the appropriate source files. You can then edit these
-source files at any time (regardless of whether other
-software developers are editing their own copies of the
-sources); update them to include new changes applied by
-others to the source repository; or commit your work as
-a permanent change to the source repository.
-
-</P>
-<P>
-Note that <CODE>checkout</CODE> is used to create
-directories. The top-level directory created is always
-added to the directory where <CODE>checkout</CODE> is
-invoked, and usually has the same name as the specified
-module. In the case of a module alias, the created
-sub-directory may have a different name, but you can be
-sure that it will be a sub-directory, and that
-<CODE>checkout</CODE> will show the relative path leading to
-each file as it is extracted into your private work
-area (unless you specify the <SAMP>`-Q'</SAMP> global option).
-
-</P>
-<P>
-The files created by <CODE>checkout</CODE> are created
-read-write, unless the <SAMP>`-r'</SAMP> option to CVS
-(see section <A HREF="cvs_20.html#SEC89">Global options</A>) is specified, the
-<CODE>CVSREAD</CODE> environment variable is specified
-(see section <A HREF="cvs_22.html#SEC151">All environment variables which
affect CVS</A>), or a watch is in
-effect for that file (see section <A HREF="cvs_7.html#SEC43">Mechanisms to
track who is editing files</A>).
-
-</P>
-<P>
-Running <CODE>checkout</CODE> on a directory that was already
-built by a prior <CODE>checkout</CODE> is also permitted, and
-has the same effect as specifying the <SAMP>`-d'</SAMP> option
-to the <CODE>update</CODE> command, that is, any new
-directories that have been created in the repository
-will appear in your work area. See section <A
HREF="cvs_20.html#SEC132">update--Bring work tree in sync with repository</A>.
-
-</P>
-<P>
-For the output produced by the <CODE>checkout</CODE> command
-see section <A HREF="cvs_20.html#SEC134">update output</A>.
-
-</P>
-
-
-
-<H3><A NAME="SEC97" HREF="cvs_toc.html#TOC97">checkout options</A></H3>
-
-<P>
-These standard options are supported by <CODE>checkout</CODE>
-(see section <A HREF="cvs_20.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-This option is sticky, and implies <SAMP>`-P'</SAMP>. See
-section <A HREF="cvs_8.html#SEC54">Sticky tags</A>, for more information on
sticky tags/dates.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
-<VAR>tag</VAR>'</SAMP> flags. If no matching revision is found,
-retrieve the most recent revision (instead of ignoring
-the file).
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Process RCS keywords according to <VAR>kflag</VAR>. See
-co(1). This option is sticky; future updates of
-this file in this working directory will use the same
-<VAR>kflag</VAR>. The <CODE>status</CODE> command can be viewed
-to see the sticky options. See section <A
HREF="cvs_20.html#SEC128">status--Display status information on checked out
files</A>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any checkout program (as specified
-with the <SAMP>`-o'</SAMP> option in the modules file;
-see section <A HREF="cvs_21.html#SEC137">The modules file</A>).
-
-<DT><CODE>-P</CODE>
-<DD>
-Prune empty directories.
-
-<DT><CODE>-p</CODE>
-<DD>
-Pipe files to the standard output.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use revision <VAR>tag</VAR>. This option is sticky, and implies
<SAMP>`-P'</SAMP>.
-See section <A HREF="cvs_8.html#SEC54">Sticky tags</A>, for more information
on sticky tags/dates.
-</DL>
-
-<P>
-In addition to those, you can use these special command
-options with <CODE>checkout</CODE>:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-A</CODE>
-<DD>
-Reset any sticky tags, dates, or <SAMP>`-k'</SAMP> options.
-See section <A HREF="cvs_8.html#SEC54">Sticky tags</A>, for more information
on sticky tags/dates.
-
-<DT><CODE>-c</CODE>
-<DD>
-Copy the module file, sorted, to the standard output,
-instead of creating or modifying any files or
-directories in your working directory.
-
-<DT><CODE>-d <VAR>dir</VAR></CODE>
-<DD>
-Create a directory called <VAR>dir</VAR> for the working
-files, instead of using the module name. Unless you
-also use <SAMP>`-N'</SAMP>, the paths created under <VAR>dir</VAR>
-will be as short as possible.
-
-<DT><CODE>-j <VAR>tag</VAR></CODE>
-<DD>
-With two <SAMP>`-j'</SAMP> options, merge changes from the
-revision specified with the first <SAMP>`-j'</SAMP> option to
-the revision specified with the second <SAMP>`j'</SAMP> option,
-into the working directory.
-
-With one <SAMP>`-j'</SAMP> option, merge changes from the
-ancestor revision to the revision specified with the
-<SAMP>`-j'</SAMP> option, into the working directory. The
-ancestor revision is the common ancestor of the
-revision which the working directory is based on, and
-the revision specified in the <SAMP>`-j'</SAMP> option.
-
-In addition, each -j option can contain an optional
-date specification which, when used with branches, can
-limit the chosen revision to one within a specific
-date. An optional date is specified by adding a colon
-(:) to the tag:
-<SAMP>`-j<VAR>Symbolic_Tag</VAR>:<VAR>Date_Specifier</VAR>'</SAMP>.
-
-See section <A HREF="cvs_9.html#SEC55">Merging</A>.
-
-<DT><CODE>-N</CODE>
-<DD>
-Only useful together with <SAMP>`-d <VAR>dir</VAR>'</SAMP>. With this
-option, CVS will not shorten module paths in your
-working directory. (Normally, CVS shortens paths as
-much as possible when you specify an explicit target
-directory).
-
-<DT><CODE>-s</CODE>
-<DD>
-Like <SAMP>`-c'</SAMP>, but include the status of all modules,
-and sort it by the status string. See section <A
HREF="cvs_21.html#SEC137">The modules file</A>, for
-info about the <SAMP>`-s'</SAMP> option that is used inside the
-modules file to set the module status.
-</DL>
-
-
-
-<H3><A NAME="SEC98" HREF="cvs_toc.html#TOC98">checkout examples</A></H3>
-
-<P>
-Get a copy of the module <SAMP>`tc'</SAMP>:
-
-</P>
-
-<PRE>
-$ cvs checkout tc
-</PRE>
-
-<P>
-Get a copy of the module <SAMP>`tc'</SAMP> as it looked one day
-ago:
-
-</P>
-
-<PRE>
-$ cvs checkout -D yesterday tc
-</PRE>
-
-
-
-<H2><A NAME="SEC99" HREF="cvs_toc.html#TOC99">commit--Check files into the
repository</A></H2>
-<P>
-<A NAME="IDX342"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Version 1.3 Synopsis: commit [-lnR] [-m 'log_message' |
--f file] [-r revision] [files...]
-<LI>
-
-Version 1.3.1 Synopsis: commit [-lnRf] [-m 'log_message' |
--F file] [-r revision] [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: ci
-</UL>
-
-<P>
-<STRONG>Warning:</STRONG> The <SAMP>`-f <VAR>file</VAR>'</SAMP> option will
-probably be renamed to <SAMP>`-F <VAR>file</VAR>'</SAMP>, and <SAMP>`-f'</SAMP>
-will be given a new behavior in future releases of CVS.
-
-</P>
-<P>
-Use <CODE>commit</CODE> when you want to incorporate changes
-from your working source files into the source
-repository.
-
-</P>
-<P>
-If you don't specify particular files to commit, all of
-the files in your working current directory are
-examined. <CODE>commit</CODE> is careful to change in the
-repository only those files that you have really
-changed. By default (or if you explicitly specify the
-<SAMP>`-R'</SAMP> option), files in subdirectories are also
-examined and committed if they have changed; you can
-use the <SAMP>`-l'</SAMP> option to limit <CODE>commit</CODE> to the
-current directory only.
-
-</P>
-<P>
-<CODE>commit</CODE> verifies that the selected files are up
-to date with the current revisions in the source
-repository; it will notify you, and exit without
-committing, if any of the specified files must be made
-current first with <CODE>update</CODE> (see section <A
HREF="cvs_20.html#SEC132">update--Bring work tree in sync with repository</A>).
-<CODE>commit</CODE> does not call the <CODE>update</CODE> command
-for you, but rather leaves that for you to do when the
-time is right.
-
-</P>
-<P>
-When all is well, an editor is invoked to allow you to
-enter a log message that will be written to one or more
-logging programs (see section <A HREF="cvs_21.html#SEC137">The modules
file</A>, and see section <A HREF="cvs_21.html#SEC144">Loginfo</A>)
-and placed in the RCS history file inside the
-repository. This log message can be retrieved with the
-<CODE>log</CODE> command; See section <A HREF="cvs_20.html#SEC116">log--Print
out log information for files</A>. You can specify the
-log message on the command line with the <SAMP>`-m
-<VAR>message</VAR>'</SAMP> option, and thus avoid the editor invocation,
-or use the <SAMP>`-f <VAR>file</VAR>'</SAMP> option to specify
-that the argument file contains the log message.
-
-</P>
-
-
-
-<H3><A NAME="SEC100" HREF="cvs_toc.html#TOC100">commit options</A></H3>
-
-<P>
-These standard options are supported by <CODE>commit</CODE>
-(see section <A HREF="cvs_20.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any module program.
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-
-<DT><CODE>-r <VAR>revision</VAR></CODE>
-<DD>
-Commit to <VAR>revision</VAR>. <VAR>revision</VAR> must be
-either a branch, or a revision on the main trunk that
-is higher than any existing revision number. You
-cannot commit to a specific revision on a branch.
-</DL>
-
-<P>
-<CODE>commit</CODE> also supports these options:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-F <VAR>file</VAR></CODE>
-<DD>
-This option is present in CVS releases 1.3-s3 and
-later. Read the log message from <VAR>file</VAR>, instead
-of invoking an editor.
-
-<DT><CODE>-f</CODE>
-<DD>
-This option is present in CVS 1.3-s3 and later releases
-of CVS. Note that this is not the standard behavior of
-the <SAMP>`-f'</SAMP> option as defined in See section <A
HREF="cvs_20.html#SEC90">Common command options</A>.
-
-Force CVS to commit a new revision even if you haven't
-made any changes to the file. If the current revision
-of <VAR>file</VAR> is 1.7, then the following two commands
-are equivalent:
-
-
-<PRE>
-$ cvs commit -f <VAR>file</VAR>
-$ cvs commit -r 1.8 <VAR>file</VAR>
-</PRE>
-
-<DT><CODE>-f <VAR>file</VAR></CODE>
-<DD>
-This option is present in CVS releases 1.3, 1.3-s1 and
-1.3-s2. Note that this is not the standard behavior of
-the <SAMP>`-f'</SAMP> option as defined in See section <A
HREF="cvs_20.html#SEC90">Common command options</A>.
-
-Read the log message from <VAR>file</VAR>, instead
-of invoking an editor.
-
-<DT><CODE>-m <VAR>message</VAR></CODE>
-<DD>
-Use <VAR>message</VAR> as the log message, instead of
-invoking an editor.
-</DL>
-
-
-
-<H3><A NAME="SEC101" HREF="cvs_toc.html#TOC101">commit examples</A></H3>
-
-
-
-<H4><A NAME="SEC102" HREF="cvs_toc.html#TOC102">New major release
number</A></H4>
-
-<P>
-When you make a major release of your product, you
-might want the revision numbers to track your major
-release number. You should normally not care about
-the revision numbers, but this is a thing that many
-people want to do, and it can be done without doing any
-harm.
-
-</P>
-<P>
-To bring all your files up to the RCS revision 3.0
-(including those that haven't changed), you might do:
-
-</P>
-
-<PRE>
-$ cvs commit -r 3.0
-</PRE>
-
-<P>
-Note that it is generally a bad idea to try to make the
-RCS revision number equal to the current release number
-of your product. You should think of the revision
-number as an internal number that the CVS package
-maintains, and that you generally never need to care
-much about. Using the <CODE>tag</CODE> and <CODE>rtag</CODE>
-commands you can give symbolic names to the releases
-instead. See section <A HREF="cvs_20.html#SEC130">tag--Add a symbolic tag to
checked out versions of files</A> and See section <A
HREF="cvs_20.html#SEC126">rtag--Add a symbolic tag to a module</A>.
-
-</P>
-<P>
-Note that the number you specify with <SAMP>`-r'</SAMP> must be
-larger than any existing revision number. That is, if
-revision 3.0 exists, you cannot <SAMP>`cvs commit
--r 1.3'</SAMP>.
-
-</P>
-
-
-<H4><A NAME="SEC103" HREF="cvs_toc.html#TOC103">Committing to a branch</A></H4>
-
-<P>
-You can commit to a branch revision (one that has an
-even number of dots) with the <SAMP>`-r'</SAMP> option. To
-create a branch revision, use the <SAMP>`-b'</SAMP> option
-of the <CODE>rtag</CODE> or <CODE>tag</CODE> commands (see section <A
HREF="cvs_20.html#SEC130">tag--Add a symbolic tag to checked out versions of
files</A>
-or see section <A HREF="cvs_20.html#SEC126">rtag--Add a symbolic tag to a
module</A>). Then, either <CODE>checkout</CODE> or
-<CODE>update</CODE> can be used to base your sources on the
-newly created branch. From that point on, all
-<CODE>commit</CODE> changes made within these working sources
-will be automatically added to a branch revision,
-thereby not disturbing main-line development in any
-way. For example, if you had to create a patch to the
-1.2 version of the product, even though the 2.0 version
-is already under development, you might do:
-
-</P>
-
-<PRE>
-$ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
-$ cvs checkout -r FCS1_2_Patch product_module
-$ cd product_module
-[[ hack away ]]
-$ cvs commit
-</PRE>
-
-<P>
-This works automatically since the <SAMP>`-r'</SAMP> option is
-sticky.
-
-</P>
-
-
-<H4><A NAME="SEC104" HREF="cvs_toc.html#TOC104">Creating the branch after
editing</A></H4>
-
-<P>
-Say you have been working on some extremely
-experimental software, based on whatever revision you
-happened to checkout last week. If others in your
-group would like to work on this software with you, but
-without disturbing main-line development, you could
-commit your change to a new branch. Others can then
-checkout your experimental stuff and utilize the full
-benefit of CVS conflict resolution. The scenario might
-look like:
-
-</P>
-
-<PRE>
-[[ hacked sources are present ]]
-$ cvs tag -b EXPR1
-$ cvs update -r EXPR1
-$ cvs commit
-</PRE>
-
-<P>
-The <CODE>update</CODE> command will make the <SAMP>`-r
-EXPR1'</SAMP> option sticky on all files. Note that your
-changes to the files will never be removed by the
-<CODE>update</CODE> command. The <CODE>commit</CODE> will
-automatically commit to the correct branch, because the
-<SAMP>`-r'</SAMP> is sticky. You could also do like this:
-
-</P>
-
-<PRE>
-[[ hacked sources are present ]]
-$ cvs tag -b EXPR1
-$ cvs commit -r EXPR1
-</PRE>
-
-<P>
-but then, only those files that were changed by you
-will have the <SAMP>`-r EXPR1'</SAMP> sticky flag. If you hack
-away, and commit without specifying the <SAMP>`-r EXPR1'</SAMP>
-flag, some files may accidentally end up on the main
-trunk.
-
-</P>
-<P>
-To work with you on the experimental change, others
-would simply do
-
-</P>
-
-<PRE>
-$ cvs checkout -r EXPR1 whatever_module
-</PRE>
-
-
-
-<H2><A NAME="SEC105" HREF="cvs_toc.html#TOC105">diff--Run diffs between
revisions</A></H2>
-<P>
-<A NAME="IDX343"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: diff [-l] [rcsdiff_options] [[-r rev1 | -D date1] [-r rev2 | -D
date2]] [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-The <CODE>diff</CODE> command is used to compare different
-revisions of files. The default action is to compare
-your working files with the revisions they were based
-on, and report any differences that are found.
-
-</P>
-<P>
-If any file names are given, only those files are
-compared. If any directories are given, all files
-under them will be compared.
-
-</P>
-<P>
-The exit status will be 0 if no differences were found,
-1 if some differences were found, and 2 if any error
-occurred.
-
-</P>
-
-
-
-<H3><A NAME="SEC106" HREF="cvs_toc.html#TOC106">diff options</A></H3>
-
-<P>
-These standard options are supported by <CODE>diff</CODE>
-(see section <A HREF="cvs_20.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-See <SAMP>`-r'</SAMP> for how this affects the comparison.
-
-CVS can be configured to pass the <SAMP>`-D'</SAMP> option
-through to <CODE>rcsdiff</CODE> (which in turn passes it on
-to <CODE>diff</CODE>. GNU diff uses <SAMP>`-D'</SAMP> as a way to
-put <CODE>cpp</CODE>-style <SAMP>`#define'</SAMP> statements around the output
-differences. There is no way short of testing to
-figure out how CVS was configured. In the default
-configuration CVS will use the <SAMP>`-D <VAR>date</VAR>'</SAMP> option.
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Process RCS keywords according to <VAR>kflag</VAR>. See
-co(1).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-R</CODE>
-<DD>
-Examine directories recursively. This option is on by
-default.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Compare with revision <VAR>tag</VAR>. Zero, one or two
-<SAMP>`-r'</SAMP> options can be present. With no <SAMP>`-r'</SAMP>
-option, the working file will be compared with the
-revision it was based on. With one <SAMP>`-r'</SAMP>, that
-revision will be compared to your current working file.
-With two <SAMP>`-r'</SAMP> options those two revisions will be
-compared (and your working file will not affect the
-outcome in any way).
-
-One or both <SAMP>`-r'</SAMP> options can be replaced by a
-<SAMP>`-D <VAR>date</VAR>'</SAMP> option, described above.
-</DL>
-
-<P>
-Any other options that are found are passed through to
-<CODE>rcsdiff</CODE>, which in turn passes them to
-<CODE>diff</CODE>. The exact meaning of the options depends
-on which <CODE>diff</CODE> you are using. The long options
-introduced in GNU diff 2.0 are not yet supported in
-CVS. See the documentation for your <CODE>diff</CODE> to see
-which options are supported.
-
-</P>
-
-
-<H3><A NAME="SEC107" HREF="cvs_toc.html#TOC107">diff examples</A></H3>
-
-<P>
-The following line produces a Unidiff (<SAMP>`-u'</SAMP> flag)
-between revision 1.14 and 1.19 of
-<TT>`backend.c'</TT>. Due to the <SAMP>`-kk'</SAMP> flag no
-keywords are substituted, so differences that only depend
-on keyword substitution are ignored.
-
-</P>
-
-<PRE>
-$ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
-</PRE>
-
-<P>
-Suppose the experimental branch EXPR1 was based on a
-set of files tagged RELEASE_1_0. To see what has
-happened on that branch, the following can be used:
-
-</P>
-
-<PRE>
-$ cvs diff -r RELEASE_1_0 -r EXPR1
-</PRE>
-
-<P>
-A command like this can be used to produce a context
-diff between two releases:
-
-</P>
-
-<PRE>
-$ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
-</PRE>
-
-<P>
-If you are maintaining ChangeLogs, a command like the following
-just before you commit your changes may help you write
-the ChangeLog entry. All local modifications that have
-not yet been committed will be printed.
-
-</P>
-
-<PRE>
-$ cvs diff -u | less
-</PRE>
-
-
-
-<H2><A NAME="SEC108" HREF="cvs_toc.html#TOC108">export--Export sources from
CVS, similar to checkout</A></H2>
-<P>
-<A NAME="IDX344"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: export [-flNn] [-r rev|-D date] [-k subst] [-d dir] module...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: current directory.
-</UL>
-
-<P>
-This command is a variant of <CODE>checkout</CODE>; use it
-when you want a copy of the source for module without
-the CVS administrative directories. For example, you
-might use <CODE>export</CODE> to prepare source for shipment
-off-site. This command requires that you specify a
-date or tag (with <SAMP>`-D'</SAMP> or <SAMP>`-r'</SAMP>), so that you
-can count on reproducing the source you ship to others.
-
-</P>
-<P>
-One often would like to use <SAMP>`-kv'</SAMP> with <CODE>cvs
-export</CODE>. This causes any RCS keywords to be
-expanded such that an import done at some other site
-will not lose the keyword revision information. But be
-aware that doesn't handle an export containing binary
-files correctly. Also be aware that after having used
-<SAMP>`-kv'</SAMP>, one can no longer use the <CODE>ident</CODE>
-command (which is part of the RCS suite--see
-ident(1)) which looks for RCS keyword strings. If
-you want to be able to use <CODE>ident</CODE> you must not
-use <SAMP>`-kv'</SAMP>.
-
-</P>
-
-
-
-<H3><A NAME="SEC109" HREF="cvs_toc.html#TOC109">export options</A></H3>
-
-<P>
-These standard options are supported by <CODE>export</CODE>
-(see section <A HREF="cvs_20.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-If no matching revision is found, retrieve the most
-recent revision (instead of ignoring the file).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any checkout program.
-
-<DT><CODE>-R</CODE>
-<DD>
-Export directories recursively. This is on by default.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use revision <VAR>tag</VAR>.
-</DL>
-
-<P>
-In addition, these options (that are common to
-<CODE>checkout</CODE> and <CODE>export</CODE>) are also supported:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-d <VAR>dir</VAR></CODE>
-<DD>
-Create a directory called <VAR>dir</VAR> for the working
-files, instead of using the module name. Unless you
-also use <SAMP>`-N'</SAMP>, the paths created under <VAR>dir</VAR>
-will be as short as possible.
-
-<DT><CODE>-k <VAR>subst</VAR></CODE>
-<DD>
-Set keyword expansion mode (see section <A
HREF="cvs_17.html#SEC81">Substitution modes</A>).
-
-<DT><CODE>-N</CODE>
-<DD>
-Only useful together with <SAMP>`-d <VAR>dir</VAR>'</SAMP>. With this
-option, CVS will not shorten module paths in your
-working directory. (Normally, CVS shortens paths as
-much as possible when you specify an explicit target
-directory.)
-</DL>
-
-
-
-<H2><A NAME="SEC110" HREF="cvs_toc.html#TOC110">history--Show status of files
and users</A></H2>
-<P>
-<A NAME="IDX345"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: history [-report] [-flags] [-options args] [files...]
-<LI>
-
-Requires: the file <TT>`$CVSROOT/CVSROOT/history'</TT>
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-CVS can keep a history file that tracks each use of the
-<CODE>checkout</CODE>, <CODE>commit</CODE>, <CODE>rtag</CODE>,
-<CODE>update</CODE>, and <CODE>release</CODE> commands. You can
-use <CODE>history</CODE> to display this information in
-various formats.
-
-</P>
-<P>
-Logging must be enabled by creating the file
-<TT>`$CVSROOT/CVSROOT/history'</TT>.
-
-</P>
-<P>
-<STRONG>Warning:</STRONG> <CODE>history</CODE> uses <SAMP>`-f'</SAMP>,
<SAMP>`-l'</SAMP>,
-<SAMP>`-n'</SAMP>, and <SAMP>`-p'</SAMP> in ways that conflict with the
-normal use inside CVS (see section <A HREF="cvs_20.html#SEC90">Common command
options</A>).
-
-</P>
-
-
-
-<H3><A NAME="SEC111" HREF="cvs_toc.html#TOC111">history options</A></H3>
-
-<P>
-Several options (shown above as <SAMP>`-report'</SAMP>) control what
-kind of report is generated:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-c</CODE>
-<DD>
-Report on each time commit was used (i.e., each time
-the repository was modified).
-
-<DT><CODE>-e</CODE>
-<DD>
-Everything (all record types); equivalent to specifying
-<SAMP>`-xMACFROGWUT'</SAMP>.
-
-<DT><CODE>-m <VAR>module</VAR></CODE>
-<DD>
-Report on a particular module. (You can meaningfully
-use <SAMP>`-m'</SAMP> more than once on the command line.)
-
-<DT><CODE>-o</CODE>
-<DD>
-Report on checked-out modules.
-
-<DT><CODE>-T</CODE>
-<DD>
-Report on all tags.
-
-<DT><CODE>-x <VAR>type</VAR></CODE>
-<DD>
-Extract a particular set of record types <VAR>type</VAR> from the CVS
-history. The types are indicated by single letters,
-which you may specify in combination.
-
-Certain commands have a single record type:
-
-<DL COMPACT>
-
-<DT><CODE>F</CODE>
-<DD>
-release
-<DT><CODE>O</CODE>
-<DD>
-checkout
-<DT><CODE>T</CODE>
-<DD>
-rtag
-</DL>
-
-One of four record types may result from an update:
-
-<DL COMPACT>
-
-<DT><CODE>C</CODE>
-<DD>
-A merge was necessary but collisions were
-detected (requiring manual merging).
-<DT><CODE>G</CODE>
-<DD>
-A merge was necessary and it succeeded.
-<DT><CODE>U</CODE>
-<DD>
-A working file was copied from the repository.
-<DT><CODE>W</CODE>
-<DD>
-The working copy of a file was deleted during
-update (because it was gone from the repository).
-</DL>
-
-One of three record types results from commit:
-
-<DL COMPACT>
-
-<DT><CODE>A</CODE>
-<DD>
-A file was added for the first time.
-<DT><CODE>M</CODE>
-<DD>
-A file was modified.
-<DT><CODE>R</CODE>
-<DD>
-A file was removed.
-</DL>
-</DL>
-
-<P>
-The options shown as <SAMP>`-flags'</SAMP> constrain or expand
-the report without requiring option arguments:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-a</CODE>
-<DD>
-Show data for all users (the default is to show data
-only for the user executing <CODE>history</CODE>).
-
-<DT><CODE>-l</CODE>
-<DD>
-Show last modification only.
-
-<DT><CODE>-w</CODE>
-<DD>
-Show only the records for modifications done from the
-same working directory where <CODE>history</CODE> is
-executing.
-</DL>
-
-<P>
-The options shown as <SAMP>`-options <VAR>args</VAR>'</SAMP> constrain the
report
-based on an argument:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b <VAR>str</VAR></CODE>
-<DD>
-Show data back to a record containing the string
-<VAR>str</VAR> in either the module name, the file name, or
-the repository path.
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Show data since <VAR>date</VAR>. This is slightly different
-from the normal use of <SAMP>`-D <VAR>date</VAR>'</SAMP>, which
-selects the newest revision older than <VAR>date</VAR>.
-
-<DT><CODE>-p <VAR>repository</VAR></CODE>
-<DD>
-Show data for a particular source repository (you
-can specify several <SAMP>`-p'</SAMP> options on the same command
-line).
-
-<DT><CODE>-r <VAR>rev</VAR></CODE>
-<DD>
-Show records referring to revisions since the revision
-or tag named <VAR>rev</VAR> appears in individual RCS
-files. Each RCS file is searched for the revision or
-tag.
-
-<DT><CODE>-t <VAR>tag</VAR></CODE>
-<DD>
-Show records since tag <VAR>tag</VAR> was last added to the the
-history file. This differs from the <SAMP>`-r'</SAMP> flag
-above in that it reads only the history file, not the
-RCS files, and is much faster.
-
-<DT><CODE>-u <VAR>name</VAR></CODE>
-<DD>
-Show records for user <VAR>name</VAR>.
-</DL>
-
-
-
-<H2><A NAME="SEC112" HREF="cvs_toc.html#TOC112">import--Import sources into
CVS, using vendor branches</A></H2>
-<P>
-<A NAME="IDX346"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: import [-options] repository vendortag releasetag...
-<LI>
-
-Requires: Repository, source distribution directory.
-<LI>
-
-Changes: repository.
-</UL>
-
-<P>
-Use <CODE>import</CODE> to incorporate an entire source
-distribution from an outside source (e.g., a source
-vendor) into your source repository directory. You can
-use this command both for initial creation of a
-repository, and for wholesale updates to the module
-from the outside source. See section <A HREF="cvs_13.html#SEC63">Tracking
third-party sources</A>, for
-a discussion on this subject.
-
-</P>
-<P>
-The <VAR>repository</VAR> argument gives a directory name
-(or a path to a directory) under the CVS root directory
-for repositories; if the directory did not exist,
-import creates it.
-
-</P>
-<P>
-When you use import for updates to source that has been
-modified in your source repository (since a prior
-import), it will notify you of any files that conflict
-in the two branches of development; use <SAMP>`checkout
--j'</SAMP> to reconcile the differences, as import instructs
-you to do.
-
-</P>
-<P>
-If CVS decides a file should be ignored
-(see section <A HREF="cvs_21.html#SEC148">Ignoring files via cvsignore</A>),
it does not import it and prints
-<SAMP>`I '</SAMP> followed by the filename (see section <A
HREF="cvs_20.html#SEC114">import output</A>, for a
-complete description of the output).
-
-</P>
-<P>
-If the file <TT>`$CVSROOT/CVSROOT/cvswrappers'</TT> exists,
-any file whose names match the specifications in that
-file will be treated as packages and the appropriate
-filtering will be performed on the file/directory
-before being imported, See section <A HREF="cvs_21.html#SEC138">The
cvswrappers file</A>.
-
-</P>
-<P>
-The outside source is saved in a first-level RCS
-branch, by default 1.1.1. Updates are leaves of this
-branch; for example, files from the first imported
-collection of source will be revision 1.1.1.1, then
-files from the first imported update will be revision
-1.1.1.2, and so on.
-
-</P>
-<P>
-At least three arguments are required.
-<VAR>repository</VAR> is needed to identify the collection
-of source. <VAR>vendortag</VAR> is a tag for the entire
-branch (e.g., for 1.1.1). You must also specify at
-least one <VAR>releasetag</VAR> to identify the files at
-the leaves created each time you execute <CODE>import</CODE>.
-
-</P>
-
-
-
-<H3><A NAME="SEC113" HREF="cvs_toc.html#TOC113">import options</A></H3>
-
-<P>
-This standard option is supported by <CODE>import</CODE>
-(see section <A HREF="cvs_20.html#SEC90">Common command options</A>, for a
complete description):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-m <VAR>message</VAR></CODE>
-<DD>
-Use <VAR>message</VAR> as log information, instead of
-invoking an editor.
-</DL>
-
-<P>
-There are three additional special options.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b <VAR>branch</VAR></CODE>
-<DD>
-Specify a first-level branch other than 1.1.1. Unless
-the <SAMP>`-b <VAR>branch</VAR>'</SAMP> flag is given, revisions will
-<EM>always</EM> be made to the branch 1.1.1--even if a
-<VAR>vendortag</VAR> that matches another branch is given!
-What happens in that case, is that the tag will be
-reset to 1.1.1. Warning: This behavior might change
-in the future.
-
-<DT><CODE>-k <VAR>subst</VAR></CODE>
-<DD>
-Indicate the RCS keyword expansion mode desired. This
-setting will apply to all files created during the
-import, but not to any files that previously existed in
-the repository. See section <A HREF="cvs_17.html#SEC81">Substitution
modes</A> for a
-list of valid <SAMP>`-k'</SAMP> settings.
-
-<DT><CODE>-I <VAR>name</VAR></CODE>
-<DD>
-Specify file names that should be ignored during
-import. You can use this option repeatedly. To avoid
-ignoring any files at all (even those ignored by
-default), specify `-I !'.
-
-<VAR>name</VAR> can be a file name pattern of the same type
-that you can specify in the <TT>`.cvsignore'</TT> file.
-See section <A HREF="cvs_21.html#SEC148">Ignoring files via cvsignore</A>.
-
-<DT><CODE>-W <VAR>spec</VAR></CODE>
-<DD>
-Specify file names that should be filtered during
-import. You can use this option repeatedly.
-
-<VAR>spec</VAR> can be a file name pattern of the same type
-that you can specify in the <TT>`.cvswrappers'</TT>
-file. See section <A HREF="cvs_21.html#SEC138">The cvswrappers file</A>.
-</DL>
-
-
-
-<H3><A NAME="SEC114" HREF="cvs_toc.html#TOC114">import output</A></H3>
-
-<P>
-<CODE>import</CODE> keeps you informed of its progress by printing a line
-for each file, preceded by one character indicating the status of the file:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>U <VAR>file</VAR></CODE>
-<DD>
-The file already exists in the repository and has not been locally
-modified; a new revision has been created (if necessary).
-
-<DT><CODE>N <VAR>file</VAR></CODE>
-<DD>
-The file is a new file which has been added to the repository.
-
-<DT><CODE>C <VAR>file</VAR></CODE>
-<DD>
-The file already exists in the repository but has been locally modified;
-you will have to merge the changes.
-
-<DT><CODE>I <VAR>file</VAR></CODE>
-<DD>
-The file is being ignored (see section <A HREF="cvs_21.html#SEC148">Ignoring
files via cvsignore</A>).
-
-<DT><CODE>L <VAR>file</VAR></CODE>
-<DD>
-The file is a symbolic link; at the moment (and for the forseeable
-future), symbolic links are ignored.
-(Various options in the <TT>`modules'</TT> file can be used
-to recreate symbolic links on checkout, update, etc.;
-see section <A HREF="cvs_21.html#SEC137">The modules file</A>.)
-</DL>
-
-
-
-<H3><A NAME="SEC115" HREF="cvs_toc.html#TOC115">import examples</A></H3>
-
-<P>
-See section <A HREF="cvs_13.html#SEC63">Tracking third-party sources</A>, and
See section <A HREF="cvs_6.html#SEC33">Creating a directory tree from a number
of files</A>.
-
-</P>
-
-
-<H2><A NAME="SEC116" HREF="cvs_toc.html#TOC116">log--Print out log information
for files</A></H2>
-<P>
-<A NAME="IDX347"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: log [options] [files...]
-<LI>
-
-Requires: repository, working directory.
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-Display log information for files. <CODE>log</CODE> used to
-call the RCS utility <CODE>rlog</CODE>. Although this
-is no longer true in the current sources, this history
-determines the format of the output and the options,
-which are not quite in the style of the other CVS
-commands.
-
-</P>
-<P>
-<A NAME="IDX348"></A>
-<A NAME="IDX349"></A>
-The output includes the location of the RCS file,
-the <EM>head</EM> revision (the latest revision on the
-trunk), all symbolic names (tags) and some other
-things. For each revision, the revision number, the
-author, the number of lines added/deleted and the log
-message are printed. All times are displayed in
-Coordinated Universal Time (UTC). (Other parts of
-CVS print times in the local timezone).
-
-</P>
-
-
-
-<H3><A NAME="SEC117" HREF="cvs_toc.html#TOC117">log options</A></H3>
-
-<P>
-By default, <CODE>log</CODE> prints all information that is
-available. All other options restrict the output.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b</CODE>
-<DD>
-Print information about the revisions on the default
-branch, normally the highest branch on the trunk.
-
-<DT><CODE>-d <VAR>dates</VAR></CODE>
-<DD>
-Print information about revisions with a checkin
-date/time in the range given by the
-semicolon-separated list of dates. The date formats
-accepted are those accepted by the <SAMP>`-D'</SAMP> option to
-many other CVS commands (see section <A HREF="cvs_20.html#SEC90">Common
command options</A>).
-Dates can be combined into ranges as follows:
-
-<DL COMPACT>
-
-<DT><CODE><VAR>d1</VAR><<VAR>d2</VAR></CODE>
-<DD>
-<DT><CODE><VAR>d2</VAR>><VAR>d1</VAR></CODE>
-<DD>
-Select the revisions that were deposited between
-<VAR>d1</VAR> and <VAR>d2</VAR>.
-
-<DT><CODE><<VAR>d</VAR></CODE>
-<DD>
-<DT><CODE><VAR>d</VAR>></CODE>
-<DD>
-Select all revisions dated <VAR>d</VAR> or earlier.
-
-<DT><CODE><VAR>d</VAR><</CODE>
-<DD>
-<DT><CODE>><VAR>d</VAR></CODE>
-<DD>
-Select all revisions dated <VAR>d</VAR> or later.
-
-<DT><CODE><VAR>d</VAR></CODE>
-<DD>
-Select the single, latest revision dated <VAR>d</VAR> or
-earlier.
-</DL>
-
-The <SAMP>`>'</SAMP> or <SAMP>`<'</SAMP> characters may be followed by
-<SAMP>`='</SAMP> to indicate an inclusive range rather than an
-exclusive one.
-
-Note that the separator is a semicolon (;).
-
-<DT><CODE>-h</CODE>
-<DD>
-Print only the RCS pathname, working pathname, head,
-default branch, access list, locks, symbolic names, and
-suffix.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory. (Default
-is to run recursively).
-
-<DT><CODE>-N</CODE>
-<DD>
-Do not print the list of tags for this file. This
-option can be very useful when your site uses a lot of
-tags, so rather than "more"'ing over 3 pages of tag
-information, the log information is presented without
-tags at all.
-
-<DT><CODE>-R</CODE>
-<DD>
-Print only the name of the RCS history file.
-
-<DT><CODE>-r<VAR>revisions</VAR></CODE>
-<DD>
-Print information about revisions given in the
-comma-separated list <VAR>revisions</VAR> of revisions and
-ranges. The following table explains the available
-range formats:
-
-<DL COMPACT>
-
-<DT><CODE><VAR>rev1</VAR>:<VAR>rev2</VAR></CODE>
-<DD>
-Revisions <VAR>rev1</VAR> to <VAR>rev2</VAR> (which must be on
-the same branch).
-
-<DT><CODE>:<VAR>rev</VAR></CODE>
-<DD>
-Revisions from the beginning of the branch up to
-and including <VAR>rev</VAR>.
-
-<DT><CODE><VAR>rev</VAR>:</CODE>
-<DD>
-Revisions starting with <VAR>rev</VAR> to the end of the
-branch containing <VAR>rev</VAR>.
-
-<DT><CODE><VAR>branch</VAR></CODE>
-<DD>
-An argument that is a branch means all revisions on
-that branch.
-
-<DT><CODE><VAR>branch1</VAR>:<VAR>branch2</VAR></CODE>
-<DD>
-A range of branches means all revisions
-on the branches in that range.
-
-<DT><CODE><VAR>branch</VAR>.</CODE>
-<DD>
-The latest revision in <VAR>branch</VAR>.
-</DL>
-
-A bare <SAMP>`-r'</SAMP> with no revisions means the latest
-revision on the default branch, normally the trunk.
-There can be no space between the <SAMP>`-r'</SAMP> option and
-its argument.
-
-<DT><CODE>-s <VAR>states</VAR></CODE>
-<DD>
-Print information about revisions whose state
-attributes match one of the states given in the
-comma-separated list <VAR>states</VAR>.
-
-<DT><CODE>-t</CODE>
-<DD>
-Print the same as <SAMP>`-h'</SAMP>, plus the descriptive text.
-
-<DT><CODE>-w<VAR>logins</VAR></CODE>
-<DD>
-Print information about revisions checked in by users
-with login names appearing in the comma-separated list
-<VAR>logins</VAR>. If <VAR>logins</VAR> is omitted, the user's
-login is assumed. There can be no space between the
-<SAMP>`-w'</SAMP> option and its argument.
-</DL>
-
-<P>
-<CODE>log</CODE> prints the intersection of the revisions
-selected with the options <SAMP>`-d'</SAMP>, <SAMP>`-s'</SAMP>, and
-<SAMP>`-w'</SAMP>, intersected with the union of the revisions
-selected by <SAMP>`-b'</SAMP> and <SAMP>`-r'</SAMP>.
-
-</P>
-
-
-<H3><A NAME="SEC118" HREF="cvs_toc.html#TOC118">log examples</A></H3>
-
-<P>
-Contributed examples are gratefully accepted.
-
-</P>
-
-
-<H2><A NAME="SEC119" HREF="cvs_toc.html#TOC119">rdiff---'patch' format diffs
between releases</A></H2>
-<P>
-<A NAME="IDX350"></A>
-
-</P>
-
-<UL>
-<LI>
-
-rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: nothing.
-<LI>
-
-Synonym: patch
-</UL>
-
-<P>
-Builds a Larry Wall format patch(1) file between two
-releases, that can be fed directly into the patch
-program to bring an old release up-to-date with the new
-release. (This is one of the few CVS commands that
-operates directly from the repository, and doesn't
-require a prior checkout.) The diff output is sent to
-the standard output device.
-
-</P>
-<P>
-You can specify (using the standard <SAMP>`-r'</SAMP> and
-<SAMP>`-D'</SAMP> options) any combination of one or two
-revisions or dates. If only one revision or date is
-specified, the patch file reflects differences between
-that revision or date and the current head revisions in
-the RCS file.
-
-</P>
-<P>
-Note that if the software release affected is contained
-in more than one directory, then it may be necessary to
-specify the <SAMP>`-p'</SAMP> option to the patch command when
-patching the old sources, so that patch is able to find
-the files that are located in other directories.
-
-</P>
-
-
-
-<H3><A NAME="SEC120" HREF="cvs_toc.html#TOC120">rdiff options</A></H3>
-
-<P>
-These standard options are supported by <CODE>rdiff</CODE>
-(see section <A HREF="cvs_20.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-If no matching revision is found, retrieve the most
-recent revision (instead of ignoring the file).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; don't descend subdirectories.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use revision <VAR>tag</VAR>.
-</DL>
-
-<P>
-In addition to the above, these options are available:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-c</CODE>
-<DD>
-Use the context diff format. This is the default format.
-
-<DT><CODE>-s</CODE>
-<DD>
-Create a summary change report instead of a patch. The
-summary includes information about files that were
-changed or added between the releases. It is sent to
-the standard output device. This is useful for finding
-out, for example, which files have changed between two
-dates or revisions.
-
-<DT><CODE>-t</CODE>
-<DD>
-A diff of the top two revisions is sent to the standard
-output device. This is most useful for seeing what the
-last change to a file was.
-
-<DT><CODE>-u</CODE>
-<DD>
-Use the unidiff format for the context diffs.
-This option is not available if your diff does not
-support the unidiff format. Remember that old versions
-of the <CODE>patch</CODE> program can't handle the unidiff
-format, so if you plan to post this patch to the net
-you should probably not use <SAMP>`-u'</SAMP>.
-
-<DT><CODE>-V <VAR>vn</VAR></CODE>
-<DD>
-Expand RCS keywords according to the rules current in
-RCS version <VAR>vn</VAR> (the expansion format changed with
-RCS version 5).
-</DL>
-
-
-
-<H3><A NAME="SEC121" HREF="cvs_toc.html#TOC121">rdiff examples</A></H3>
-
-<P>
-Suppose you receive mail from <TT>address@hidden</TT> asking for an
-update from release 1.2 to 1.4 of the tc compiler. You
-have no such patches on hand, but with CVS that can
-easily be fixed with a command such as this:
-
-</P>
-
-<PRE>
-$ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
-$$ Mail -s 'The patches you asked for' address@hidden
-</PRE>
-
-<P>
-Suppose you have made release 1.3, and forked a branch
-called <SAMP>`R_1_3fix'</SAMP> for bugfixes. <SAMP>`R_1_3_1'</SAMP>
-corresponds to release 1.3.1, which was made some time
-ago. Now, you want to see how much development has been
-done on the branch. This command can be used:
-
-</P>
-
-<PRE>
-$ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name
-cvs rdiff: Diffing module-name
-File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6
-File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4
-File bar.h,v changed from revision 1.29.2.1 to 1.2
-</PRE>
-
-
-
-<H2><A NAME="SEC122" HREF="cvs_toc.html#TOC122">release--Indicate that a
Module is no longer in use</A></H2>
-<P>
-<A NAME="IDX351"></A>
-
-</P>
-
-<UL>
-<LI>
-
-release [-d] directories...
-<LI>
-
-Requires: Working directory.
-<LI>
-
-Changes: Working directory, history log.
-</UL>
-
-<P>
-This command is meant to safely cancel the effect of
-<SAMP>`cvs checkout'</SAMP>. Since CVS doesn't lock files, it
-isn't strictly necessary to use this command. You can
-always simply delete your working directory, if you
-like; but you risk losing changes you may have
-forgotten, and you leave no trace in the CVS history
-file (see section <A HREF="cvs_21.html#SEC149">The history file</A>) that
you've abandoned your
-checkout.
-
-</P>
-<P>
-Use <SAMP>`cvs release'</SAMP> to avoid these problems. This
-command checks that no uncommitted changes are
-present; that you are executing it from immediately
-above a CVS working directory; and that the repository
-recorded for your files is the same as the repository
-defined in the module database.
-
-</P>
-<P>
-If all these conditions are true, <SAMP>`cvs release'</SAMP>
-leaves a record of its execution (attesting to your
-intentionally abandoning your checkout) in the CVS
-history log.
-
-</P>
-
-
-
-<H3><A NAME="SEC123" HREF="cvs_toc.html#TOC123">release options</A></H3>
-
-<P>
-The <CODE>release</CODE> command supports one command option:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-d</CODE>
-<DD>
-Delete your working copy of the file if the release
-succeeds. If this flag is not given your files will
-remain in your working directory.
-
-<STRONG>Warning:</STRONG> The <CODE>release</CODE> command deletes
-all directories and files recursively. This
-has the very serious side-effect that any directory
-that you have created inside your checked-out sources,
-and not added to the repository (using the <CODE>add</CODE>
-command; see section <A HREF="cvs_11.html#SEC61">Adding files to a
directory</A>) will be silently deleted--even
-if it is non-empty!
-</DL>
-
-
-
-<H3><A NAME="SEC124" HREF="cvs_toc.html#TOC124">release output</A></H3>
-
-<P>
-Before <CODE>release</CODE> releases your sources it will
-print a one-line message for any file that is not
-up-to-date.
-
-</P>
-<P>
-<STRONG>Warning:</STRONG> Any new directories that you have
-created, but not added to the CVS directory hierarchy
-with the <CODE>add</CODE> command (see section <A
HREF="cvs_11.html#SEC61">Adding files to a directory</A>) will be
-silently ignored (and deleted, if <SAMP>`-d'</SAMP> is
-specified), even if they contain files.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>U <VAR>file</VAR></CODE>
-<DD>
-There exists a newer revision of this file in the
-repository, and you have not modified your local copy
-of the file.
-
-<DT><CODE>A <VAR>file</VAR></CODE>
-<DD>
-The file has been added to your private copy of the
-sources, but has not yet been committed to the
-repository. If you delete your copy of the sources
-this file will be lost.
-
-<DT><CODE>R <VAR>file</VAR></CODE>
-<DD>
-The file has been removed from your private copy of the
-sources, but has not yet been removed from the
-repository, since you have not yet committed the
-removal. See section <A HREF="cvs_20.html#SEC99">commit--Check files into the
repository</A>.
-
-<DT><CODE>M <VAR>file</VAR></CODE>
-<DD>
-The file is modified in your working directory. There
-might also be a newer revision inside the repository.
-
-<DT><CODE>? <VAR>file</VAR></CODE>
-<DD>
-<VAR>file</VAR> is in your working directory, but does not
-correspond to anything in the source repository, and is
-not in the list of files for CVS to ignore (see the
-description of the <SAMP>`-I'</SAMP> option, and
-see section <A HREF="cvs_21.html#SEC148">Ignoring files via cvsignore</A>).
If you remove your working
-sources, this file will be lost.
-
-Note that no warning message like this is printed for
-spurious directories that CVS encounters. The
-directory, and all its contents, are silently ignored.
-
-</DL>
-
-
-
-<H3><A NAME="SEC125" HREF="cvs_toc.html#TOC125">release examples</A></H3>
-
-<P>
-Release the module, and delete your local working copy
-of the files.
-
-</P>
-
-<PRE>
-$ cd .. # You must stand immediately above the
- # sources when you issue <SAMP>`cvs release'</SAMP>.
-$ cvs release -d tc
-You have [0] altered files in this repository.
-Are you sure you want to release (and delete) module `tc': y
-$
-</PRE>
-
-
-
-<H2><A NAME="SEC126" HREF="cvs_toc.html#TOC126">rtag--Add a symbolic tag to a
module</A></H2>
-<P>
-<A NAME="IDX352"></A>
-
-</P>
-
-<UL>
-<LI>
-
-rtag [-falnR] [-b] [-d] [-r tag | -Ddate] symbolic_tag modules...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: rfreeze
-</UL>
-
-<P>
-You can use this command to assign symbolic tags to
-particular, explicitly specified source revisions in
-the repository. <CODE>rtag</CODE> works directly on the
-repository contents (and requires no prior checkout).
-Use <CODE>tag</CODE> instead (see section <A
HREF="cvs_20.html#SEC130">tag--Add a symbolic tag to checked out versions of
files</A>), to base the
-selection of revisions on the contents of your
-working directory.
-
-</P>
-<P>
-If you attempt to use a tag name that already exists,
-CVS will complain and not overwrite that tag. Use
-the <SAMP>`-F'</SAMP> option to force the new tag value.
-
-</P>
-
-
-
-<H3><A NAME="SEC127" HREF="cvs_toc.html#TOC127">rtag options</A></H3>
-
-<P>
-These standard options are supported by <CODE>rtag</CODE>
-(see section <A HREF="cvs_20.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Tag the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
<VAR>tag</VAR>'</SAMP>
-flags. If no matching revision is found, use the most
-recent revision (instead of ignoring the file).
-
-<DT><CODE>-F</CODE>
-<DD>
-Overwrite an existing tag of the same name on a
-different revision. This option is new in CVS
-1.4. The old behavior is matched by <SAMP>`cvs tag -F'</SAMP>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any tag program that was specified with the
-<SAMP>`-t'</SAMP> flag inside the <TT>`modules'</TT> file.
-(see section <A HREF="cvs_21.html#SEC137">The modules file</A>).
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Only tag those files that contain <VAR>tag</VAR>. This can
-be used to rename a tag: tag only the files identified
-by the old tag, then delete the old tag, leaving the
-new tag on exactly the same files as the old tag.
-</DL>
-
-<P>
-In addition to the above common options, these options
-are available:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-a</CODE>
-<DD>
-Use the <SAMP>`-a'</SAMP> option to have <CODE>rtag</CODE> look in the
-<TT>`Attic'</TT> (see section <A HREF="cvs_12.html#SEC62">Removing files from
a module</A>) for removed files
-that contain the specified tag. The tag is removed from
-these files, which makes it convenient to re-use a
-symbolic tag as development continues (and files get
-removed from the up-coming distribution).
-
-<DT><CODE>-b</CODE>
-<DD>
-Make the tag a branch tag. See section <A
HREF="cvs_8.html#SEC50">Branches</A>.
-
-<DT><CODE>-d</CODE>
-<DD>
-Delete the tag instead of creating it.
-
-In general, tags (often the symbolic names of software
-distributions) should not be removed, but the <SAMP>`-d'</SAMP>
-option is available as a means to remove completely
-obsolete symbolic names if necessary (as might be the
-case for an Alpha release, or if you mistagged a
-module).
-</DL>
-
-
-
-<H2><A NAME="SEC128" HREF="cvs_toc.html#TOC128">status--Display status
information on checked out files</A></H2>
-<P>
-<A NAME="IDX353"></A>
-
-</P>
-
-
-<UL>
-<LI>
-
-status [-lR] [-v] [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-Display a brief report on the current status of files
-with respect to the source repository. For information
-on the basic output see section <A HREF="cvs_7.html#SEC38">File status</A>.
For
-information on the <CODE>Sticky tag</CODE> and <CODE>Sticky
-date</CODE> output, see section <A HREF="cvs_8.html#SEC54">Sticky tags</A>.
For information
-on the <CODE>Sticky options</CODE> output, see the <SAMP>`-k'</SAMP>
-option in section <A HREF="cvs_20.html#SEC133">update options</A>.
-
-</P>
-<P>
-You can also use this command to determine the
-potential impact of a <SAMP>`cvs update'</SAMP> on your working
-source directory--but remember that things might
-change in the repository before you run <CODE>update</CODE>.
-
-</P>
-
-
-
-<H3><A NAME="SEC129" HREF="cvs_toc.html#TOC129">status options</A></H3>
-
-<P>
-These standard options are supported by <CODE>status</CODE>
-(see section <A HREF="cvs_20.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-</DL>
-
-<P>
-There is one additional option:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-v</CODE>
-<DD>
-Verbose. In addition to the information normally
-displayed, print all symbolic tags, together with the
-numerical value of the revision or branch they refer
-to. For more information, see section <A
HREF="cvs_8.html#SEC51">Tags--Symbolic revisions</A>
-</DL>
-
-
-
-<H2><A NAME="SEC130" HREF="cvs_toc.html#TOC130">tag--Add a symbolic tag to
checked out versions of files</A></H2>
-<P>
-<A NAME="IDX354"></A>
-
-</P>
-
-<UL>
-<LI>
-
-tag [-lR] [-b] [-c] [-d] symbolic_tag [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: freeze
-</UL>
-
-<P>
-Use this command to assign symbolic tags to the nearest
-repository versions to your working sources. The tags
-are applied immediately to the repository, as with
-<CODE>rtag</CODE>, but the versions are supplied implicitly by the
-CVS records of your working files' history rather than
-applied explicitly.
-
-</P>
-<P>
-One use for tags is to record a snapshot of the
-current sources when the software freeze date of a
-project arrives. As bugs are fixed after the freeze
-date, only those changed sources that are to be part of
-the release need be re-tagged.
-
-</P>
-<P>
-The symbolic tags are meant to permanently record which
-revisions of which files were used in creating a
-software distribution. The <CODE>checkout</CODE> and
-<CODE>update</CODE> commands allow you to extract an exact
-copy of a tagged release at any time in the future,
-regardless of whether files have been changed, added,
-or removed since the release was tagged.
-
-</P>
-<P>
-This command can also be used to delete a symbolic tag,
-or to create a branch. See the options section below.
-
-</P>
-<P>
-If you attempt to use a tag name that already exists,
-CVS will complain and not overwrite that tag. Use
-the <SAMP>`-F'</SAMP> option to force the new tag value.
-
-</P>
-
-
-
-<H3><A NAME="SEC131" HREF="cvs_toc.html#TOC131">tag options</A></H3>
-
-<P>
-These standard options are supported by <CODE>tag</CODE>
-(see section <A HREF="cvs_20.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-F</CODE>
-<DD>
-Overwrite an existing tag of the same name on a
-different revision. This option is new in CVS
-1.4. The old behavior is matched by <SAMP>`cvs tag -F'</SAMP>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-</DL>
-
-<P>
-Two special options are available:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b</CODE>
-<DD>
-The -b option makes the tag a branch tag
-(see section <A HREF="cvs_8.html#SEC50">Branches</A>), allowing concurrent,
isolated
-development. This is most useful for creating a patch
-to a previously released software distribution.
-
-<DT><CODE>-c</CODE>
-<DD>
-The -c option checks that all files which are to be tagged are
-unmodified. This can be used to make sure that you can reconstruct the
-current file contents.
-
-<DT><CODE>-d</CODE>
-<DD>
-Delete a tag.
-
-If you use <SAMP>`cvs tag -d symbolic_tag'</SAMP>, the symbolic
-tag you specify is deleted instead of being added.
-Warning: Be very certain of your ground before you
-delete a tag; doing this permanently discards some
-historical information, which may later turn out to
-be valuable.
-</DL>
-
-
-
-<H2><A NAME="SEC132" HREF="cvs_toc.html#TOC132">update--Bring work tree in
sync with repository</A></H2>
-<P>
-<A NAME="IDX355"></A>
-
-</P>
-
-<UL>
-<LI>
-
-update [-AdflPpR] [-d] [-r tag|-D date] files...
-<LI>
-
-Requires: repository, working directory.
-<LI>
-
-Changes: working directory.
-</UL>
-
-<P>
-After you've run checkout to create your private copy
-of source from the common repository, other developers
-will continue changing the central source. From time
-to time, when it is convenient in your development
-process, you can use the <CODE>update</CODE> command from
-within your working directory to reconcile your work
-with any revisions applied to the source repository
-since your last checkout or update.
-
-</P>
-
-
-
-<H3><A NAME="SEC133" HREF="cvs_toc.html#TOC133">update options</A></H3>
-
-<P>
-These standard options are available with <CODE>update</CODE>
-(see section <A HREF="cvs_20.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D date</CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-This option is sticky, and implies <SAMP>`-P'</SAMP>.
-See section <A HREF="cvs_8.html#SEC54">Sticky tags</A>, for more information
on sticky tags/dates.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
-<VAR>tag</VAR>'</SAMP> flags. If no matching revision is found,
-retrieve the most recent revision (instead of ignoring
-the file).
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Process RCS keywords according to <VAR>kflag</VAR>. See
-co(1). This option is sticky; future updates of
-this file in this working directory will use the same
-<VAR>kflag</VAR>. The <CODE>status</CODE> command can be viewed
-to see the sticky options. See section <A
HREF="cvs_20.html#SEC128">status--Display status information on checked out
files</A>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory. See section <A
HREF="cvs_10.html#SEC60">Recursive behavior</A>.
-
-<DT><CODE>-P</CODE>
-<DD>
-Prune empty directories.
-
-<DT><CODE>-p</CODE>
-<DD>
-Pipe files to the standard output.
-
-<DT><CODE>-R</CODE>
-<DD>
-Operate recursively. This is on by default.
-See section <A HREF="cvs_10.html#SEC60">Recursive behavior</A>.
-
-<DT><CODE>-r tag</CODE>
-<DD>
-Retrieve revision <VAR>tag</VAR>. This option is sticky,
-and implies <SAMP>`-P'</SAMP>.
-See section <A HREF="cvs_8.html#SEC54">Sticky tags</A>, for more information
on sticky tags/dates.
-</DL>
-
-<P>
-These special options are also available with
-<CODE>update</CODE>.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-A</CODE>
-<DD>
-Reset any sticky tags, dates, or <SAMP>`-k'</SAMP> options.
-See section <A HREF="cvs_8.html#SEC54">Sticky tags</A>, for more information
on sticky tags/dates.
-
-<DT><CODE>-d</CODE>
-<DD>
-Create any directories that exist in the repository if
-they're missing from the working directory. Normally,
-<CODE>update</CODE> acts only on directories and files that
-were already enrolled in your working directory.
-
-This is useful for updating directories that were
-created in the repository since the initial checkout;
-but it has an unfortunate side effect. If you
-deliberately avoided certain directories in the
-repository when you created your working directory
-(either through use of a module name or by listing
-explicitly the files and directories you wanted on the
-command line), then updating with <SAMP>`-d'</SAMP> will create
-those directories, which may not be what you want.
-
-<DT><CODE>-I <VAR>name</VAR></CODE>
-<DD>
-Ignore files whose names match <VAR>name</VAR> (in your
-working directory) during the update. You can specify
-<SAMP>`-I'</SAMP> more than once on the command line to specify
-several files to ignore. Use <SAMP>`-I !'</SAMP> to avoid
-ignoring any files at all. See section <A HREF="cvs_21.html#SEC148">Ignoring
files via cvsignore</A>, for other
-ways to make CVS ignore some files.
-
-<DT><CODE>-W<VAR>spec</VAR></CODE>
-<DD>
-Specify file names that should be filtered during
-update. You can use this option repeatedly.
-
-<VAR>spec</VAR> can be a file name pattern of the same type
-that you can specify in the <TT>`.cvswrappers'</TT>
-file. See section <A HREF="cvs_21.html#SEC138">The cvswrappers file</A>.
-
-<DT><CODE>-j<VAR>revision</VAR></CODE>
-<DD>
-With two <SAMP>`-j'</SAMP> options, merge changes from the
-revision specified with the first <SAMP>`-j'</SAMP> option to
-the revision specified with the second <SAMP>`j'</SAMP> option,
-into the working directory.
-
-With one <SAMP>`-j'</SAMP> option, merge changes from the
-ancestor revision to the revision specified with the
-<SAMP>`-j'</SAMP> option, into the working directory. The
-ancestor revision is the common ancestor of the
-revision which the working directory is based on, and
-the revision specified in the <SAMP>`-j'</SAMP> option.
-
-In addition, each -j option can contain an optional
-date specification which, when used with branches, can
-limit the chosen revision to one within a specific
-date. An optional date is specified by adding a colon
-(:) to the tag:
-<SAMP>`-j<VAR>Symbolic_Tag</VAR>:<VAR>Date_Specifier</VAR>'</SAMP>.
-
-See section <A HREF="cvs_9.html#SEC55">Merging</A>.
-
-</DL>
-
-
-
-<H3><A NAME="SEC134" HREF="cvs_toc.html#TOC134">update output</A></H3>
-
-<P>
-<CODE>update</CODE> and <CODE>checkout</CODE> keep you informed of
-its progress by printing a line for each file, preceded
-by one character indicating the status of the file:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>U <VAR>file</VAR></CODE>
-<DD>
-The file was brought up to date with respect to the
-repository. This is done for any file that exists in
-the repository but not in your source, and for files
-that you haven't changed but are not the most recent
-versions available in the repository.
-
-<DT><CODE>A <VAR>file</VAR></CODE>
-<DD>
-The file has been added to your private copy of the
-sources, and will be added to the source repository
-when you run <CODE>commit</CODE> on the file. This is a
-reminder to you that the file needs to be committed.
-
-<DT><CODE>R <VAR>file</VAR></CODE>
-<DD>
-The file has been removed from your private copy of the
-sources, and will be removed from the source repository
-when you run <CODE>commit</CODE> on the file. This is a
-reminder to you that the file needs to be committed.
-
-<DT><CODE>M <VAR>file</VAR></CODE>
-<DD>
-The file is modified in your working directory.
-
-<SAMP>`M'</SAMP> can indicate one of two states for a file
-you're working on: either there were no modifications
-to the same file in the repository, so that your file
-remains as you last saw it; or there were modifications
-in the repository as well as in your copy, but they
-were merged successfully, without conflict, in your
-working directory.
-
-CVS will print some messages if it merges your work,
-and a backup copy of your working file (as it looked
-before you ran <CODE>update</CODE>) will be made. The exact
-name of that file is printed while <CODE>update</CODE> runs.
-
-<DT><CODE>C <VAR>file</VAR></CODE>
-<DD>
-<A NAME="IDX356"></A>
-<A NAME="IDX357"></A>
-A conflict was detected while trying to merge your
-changes to <VAR>file</VAR> with changes from the source
-repository. <VAR>file</VAR> (the copy in your working
-directory) is now the output of the rcsmerge(1) command
-on the two revisions; an unmodified copy of your file
-is also in your working directory, with the name
-<TT>`.#<VAR>file</VAR>.<VAR>revision</VAR>'</TT> where <VAR>revision</VAR>
-is the RCS revision that your modified file started
-from. Resolve the conflict as described in
-section <A HREF="cvs_7.html#SEC40">Conflicts example</A>
-(Note that some systems automatically purge
-files that begin with <TT>`.#'</TT> if they have not been
-accessed for a few days. If you intend to keep a copy
-of your original file, it is a very good idea to rename
-it.) Under VMS, the file name starts with
-<TT>`__'</TT> rather than <TT>`.#'</TT>.
-
-<DT><CODE>? <VAR>file</VAR></CODE>
-<DD>
-<VAR>file</VAR> is in your working directory, but does not
-correspond to anything in the source repository, and is
-not in the list of files for CVS to ignore (see the
-description of the <SAMP>`-I'</SAMP> option, and
-see section <A HREF="cvs_21.html#SEC148">Ignoring files via cvsignore</A>).
-
-Note that no warning message like this is printed for
-spurious directories that CVS encounters. The
-directory, and all its contents, are silently ignored.
-</DL>
-
-
-
-<H3><A NAME="SEC135" HREF="cvs_toc.html#TOC135">update examples</A></H3>
-
-<P>
-The following line will display all files which are not
-up-to-date without actually change anything in your
-working directory. It can be used to check what has
-been going on with the project.
-
-</P>
-
-<PRE>
-$ cvs -n -q update
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_19.html">previous</A>,
<A HREF="cvs_21.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_21.html
===================================================================
RCS file: manual/html_chapter/cvs_21.html
diff -N manual/html_chapter/cvs_21.html
--- manual/html_chapter/cvs_21.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,976 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Reference manual for the
Administrative files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_20.html">previous</A>,
<A HREF="cvs_22.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC136" HREF="cvs_toc.html#TOC136">Reference manual for the
Administrative files</A></H1>
-<P>
-<A NAME="IDX358"></A>
-<A NAME="IDX359"></A>
-<A NAME="IDX360"></A>
-<A NAME="IDX361"></A>
-
-</P>
-<P>
-Inside the repository, in the directory
-<TT>`$CVSROOT/CVSROOT'</TT>, there are a number of
-supportive files for CVS. You can use CVS in a limited
-fashion without any of them, but if they are set up
-properly they can help make life easier. For a
-discussion of how to edit them, See section <A HREF="cvs_5.html#SEC20">The
administrative files</A>.
-
-</P>
-<P>
-The most important of these files is the <TT>`modules'</TT>
-file, which defines the modules inside the repository.
-
-</P>
-
-
-
-<H2><A NAME="SEC137" HREF="cvs_toc.html#TOC137">The modules file</A></H2>
-<P>
-<A NAME="IDX362"></A>
-<A NAME="IDX363"></A>
-
-</P>
-<P>
-The <TT>`modules'</TT> file records your definitions of
-names for collections of source code. CVS will
-use these definitions if you use CVS to update the
-modules file (use normal commands like <CODE>add</CODE>,
-<CODE>commit</CODE>, etc).
-
-</P>
-<P>
-The <TT>`modules'</TT> file may contain blank lines and
-comments (lines beginning with <SAMP>`#'</SAMP>) as well as
-module definitions. Long lines can be continued on the
-next line by specifying a backslash (<SAMP>`\'</SAMP>) as the
-last character on the line.
-
-</P>
-<P>
-A module definition is a single line of the
-<TT>`modules'</TT> file, in either of two formats. In both
-cases, <VAR>mname</VAR> represents the symbolic module name,
-and the remainder of the line is its definition.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE><VAR>mname</VAR> -a <VAR>aliases</VAR>...</CODE>
-<DD>
-This represents the simplest way of defining a module
-<VAR>mname</VAR>. The <SAMP>`-a'</SAMP> flags the definition as a
-simple alias: CVS will treat any use of <VAR>mname</VAR> (as
-a command argument) as if the list of names
-<VAR>aliases</VAR> had been specified instead.
-<VAR>aliases</VAR> may contain either other module names or
-paths. When you use paths in aliases, <CODE>checkout</CODE>
-creates all intermediate directories in the working
-directory, just as if the path had been specified
-explicitly in the CVS arguments.
-
-<DT><CODE><VAR>mname</VAR> [ options ] <VAR>dir</VAR> [ <VAR>files</VAR>... ]
[ &<VAR>module</VAR>... ]</CODE>
-<DD>
-In the simplest case, this form of module definition
-reduces to <SAMP>`<VAR>mname</VAR> <VAR>dir</VAR>'</SAMP>. This defines
-all the files in directory <VAR>dir</VAR> as module mname.
-<VAR>dir</VAR> is a relative path (from <CODE>$CVSROOT</CODE>) to a
-directory of source in the source repository. In this
-case, on checkout, a single directory called
-<VAR>mname</VAR> is created as a working directory; no
-intermediate directory levels are used by default, even
-if <VAR>dir</VAR> was a path involving several directory
-levels.
-
-By explicitly specifying files in the module definition
-after <VAR>dir</VAR>, you can select particular files from
-directory <VAR>dir</VAR>. The sample definition for
-<SAMP>`modules'</SAMP> is an example of a module defined with a
-single file from a particular directory. Here is
-another example:
-
-
-<PRE>
-m4test unsupported/gnu/m4 foreach.m4 forloop.m4
-</PRE>
-
-With this definition, executing <SAMP>`cvs checkout
-m4test'</SAMP> will create a single working directory
-<TT>`m4test'</TT> containing the two files listed, which
-both come from a common directory several levels deep
-in the CVS source repository.
-
-A module definition can refer to other modules by
-including <SAMP>`&<VAR>module</VAR>'</SAMP> in its definition.
-<CODE>checkout</CODE> creates a subdirectory for each such
-module, in your working directory.
-
-<DL COMPACT>
-
-<DT><CODE>-d <VAR>name</VAR></CODE>
-<DD>
-Name the working directory something other than the
-module name.
-
-<A NAME="IDX364"></A>
-<DT><CODE>-e <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are exported. <VAR>prog</VAR> runs with a single
-argument, the module name.
-
-<A NAME="IDX365"></A>
-<DT><CODE>-i <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are committed. <VAR>prog</VAR> runs with a single
-argument, the full pathname of the affected directory
-in a source repository. The <TT>`commitinfo'</TT>,
-<TT>`loginfo'</TT>, and <TT>`editinfo'</TT> files provide other
-ways to call a program on commit.
-
-<A NAME="IDX366"></A>
-<DT><CODE>-o <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are checked out. <VAR>prog</VAR> runs with a single
-argument, the module name.
-
-<A NAME="IDX367"></A>
-<A NAME="IDX368"></A>
-<DT><CODE>-s <VAR>status</VAR></CODE>
-<DD>
-Assign a status to the module. When the module file is
-printed with <SAMP>`cvs checkout -s'</SAMP> the modules are
-sorted according to primarily module status, and
-secondarily according to the module name. This option
-has no other meaning. You can use this option for
-several things besides status: for instance, list the
-person that is responsible for this module.
-
-<A NAME="IDX369"></A>
-<DT><CODE>-t <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are tagged with <CODE>rtag</CODE>. <VAR>prog</VAR> runs
-with two arguments: the module name and the symbolic
-tag specified to <CODE>rtag</CODE>. There is no way to
-specify a program to run when <CODE>tag</CODE> is executed.
-
-<A NAME="IDX370"></A>
-<DT><CODE>-u <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever <SAMP>`cvs
-update'</SAMP> is executed from the top-level directory of the
-checked-out module. <VAR>prog</VAR> runs with a single
-argument, the full path to the source repository for
-this module.
-</DL>
-</DL>
-
-
-
-<H2><A NAME="SEC138" HREF="cvs_toc.html#TOC138">The cvswrappers file</A></H2>
-<P>
-<A NAME="IDX371"></A>
-<A NAME="IDX372"></A>
-<A NAME="IDX373"></A>
-
-</P>
-
-<P>
-Wrappers allow you to set a hook which transforms files on
-their way in and out of CVS. Most or all of the
-wrappers features do not work with client/server CVS.
-
-</P>
-<P>
-The file <TT>`cvswrappers'</TT> defines the script that will be
-run on a file when its name matches a regular
-expresion. There are two scripts that can be run on a
-file or directory. One script is executed on the file/directory
-before being checked into the repository (this is denoted
-with the <CODE>-t</CODE> flag) and the other when the file is
-checked out of the repository (this is denoted with the
-<CODE>-f</CODE> flag)
-
-</P>
-<P>
-The <TT>`cvswrappers'</TT> also has a <SAMP>`-m'</SAMP> option to
-specify the merge methodology that should be used when
-the file is updated. <CODE>MERGE</CODE> means the usual
-CVS behavior: try to merge the files (this
-generally will not work for binary files). <CODE>COPY</CODE>
-means that <CODE>cvs update</CODE> will merely copy one
-version over the other, and require the user using
-mechanisms outside CVS, to insert any necessary
-changes.
-The <SAMP>`-m'</SAMP> wrapper option only affects behavior when
-merging is done on update; it does not affect how files
-are stored. See See section <A HREF="cvs_18.html#SEC83">Handling binary
files</A>, for more on
-binary files.
-
-</P>
-<P>
-The basic format of the file <TT>`cvswrappers'</TT> is:
-
-</P>
-
-<PRE>
-wildcard [option value][option value]...
-
-where option is one of
--f from cvs filter value: path to filter
--t to cvs filter value: path to filter
--m update methodology value: MERGE or COPY
--k keyword expansion value: expansion mode
-
-and value is a single-quote delimited value.
-</PRE>
-
-
-<PRE>
-*.nib -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
-*.c -t 'indent %s %s'
-</PRE>
-
-<P>
-The above example of a <TT>`cvswrappers'</TT> file
-states that all files/directories that end with a <CODE>.nib</CODE>
-should be filtered with the <TT>`wrap'</TT> program before
-checking the file into the repository. The file should
-be filtered though the <TT>`unwrap'</TT> program when the
-file is checked out of the repository. The
-<TT>`cvswrappers'</TT> file also states that a <CODE>COPY</CODE>
-methodology should be used when updating the files in
-the repository (that is no merging should be performed).
-
-</P>
-<P>
-The last example line says that all files that end with
-a <CODE>*.c</CODE> should be filtered with <TT>`indent'</TT>
-before being checked into the repository. Unlike the previous
-example no filtering of the <CODE>*.c</CODE> file is done when
-it is checked out of the repository.
-The <CODE>-t</CODE> filter is called with two arguments,
-the first is the name of the file/directory to filter
-and the second is the pathname to where the resulting
-filtered file should be placed.
-
-</P>
-<P>
-The <CODE>-f</CODE> filter is called with one argument,
-which is the name of the file to filter from. The end
-result of this filter will be a file in the users directory
-that they can work on as they normally would.
-
-</P>
-<P>
-For another example, the following command imports a
-directory, treating files whose name ends in
-<SAMP>`.exe'</SAMP> as binary:
-
-</P>
-
-<PRE>
-cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
-</PRE>
-
-
-
-<H2><A NAME="SEC139" HREF="cvs_toc.html#TOC139">The commit support
files</A></H2>
-<P>
-<A NAME="IDX374"></A>
-
-</P>
-<P>
-The <SAMP>`-i'</SAMP> flag in the <TT>`modules'</TT> file can be
-used to run a certain program whenever files are
-committed (see section <A HREF="cvs_21.html#SEC137">The modules file</A>).
The files described in
-this section provide other, more flexible, ways to run
-programs whenever something is committed.
-
-</P>
-<P>
-There are three kind of programs that can be run on
-commit. They are specified in files in the repository,
-as described below. The following table summarizes the
-file names and the purpose of the corresponding
-programs.
-
-</P>
-<DL COMPACT>
-
-<DT><TT>`commitinfo'</TT>
-<DD>
-The program is responsible for checking that the commit
-is allowed. If it exits with a non-zero exit status
-the commit will be aborted.
-
-<DT><TT>`editinfo'</TT>
-<DD>
-The specified program is used to edit the log message,
-and possibly verify that it contains all required
-fields. This is most useful in combination with the
-<TT>`rcsinfo'</TT> file, which can hold a log message
-template (see section <A HREF="cvs_21.html#SEC147">Rcsinfo</A>).
-
-<DT><TT>`loginfo'</TT>
-<DD>
-The specified program is called when the commit is
-complete. It receives the log message and some
-additional information and can store the log message in
-a file, or mail it to appropriate persons, or maybe
-post it to a local newsgroup, or... Your
-imagination is the limit!
-</DL>
-
-
-
-<H3><A NAME="SEC140" HREF="cvs_toc.html#TOC140">The common syntax</A></H3>
-<P>
-<A NAME="IDX375"></A>
-<A NAME="IDX376"></A>
-<A NAME="IDX377"></A>
-
-</P>
-
-<P>
-The four files <TT>`commitinfo'</TT>, <TT>`loginfo'</TT>,
-<TT>`rcsinfo'</TT> and <TT>`editinfo'</TT> all have a common
-format. The purpose of the files are described later
-on. The common syntax is described here.
-
-</P>
-<P>
-Each line contains the following:
-
-<UL>
-<LI>
-
-A regular expression
-
-<LI>
-
-A whitespace separator--one or more spaces and/or tabs.
-
-<LI>
-
-A file name or command-line template.
-</UL>
-
-<P>
-Blank lines are ignored. Lines that start with the
-character <SAMP>`#'</SAMP> are treated as comments. Long lines
-unfortunately can <EM>not</EM> be broken in two parts in
-any way.
-
-</P>
-<P>
-The first regular expression that matches the current
-directory name in the repository is used. The rest of the line
-is used as a file name or command-line as appropriate.
-
-</P>
-
-
-<H2><A NAME="SEC141" HREF="cvs_toc.html#TOC141">Commitinfo</A></H2>
-<P>
-<A NAME="IDX378"></A>
-<A NAME="IDX379"></A>
-<A NAME="IDX380"></A>
-
-</P>
-<P>
-The <TT>`commitinfo'</TT> file defines programs to execute
-whenever <SAMP>`cvs commit'</SAMP> is about to execute. These
-programs are used for pre-commit checking to verify
-that the modified, added and removed files are really
-ready to be committed. This could be used, for
-instance, to verify that the changed files conform to
-to your site's standards for coding practice.
-
-</P>
-<P>
-As mentioned earlier, each line in the
-<TT>`commitinfo'</TT> file consists of a regular expression
-and a command-line template. The template can include
-a program name and any number of arguments you wish to
-supply to it. The full path to the current source
-repository is appended to the template, followed by the
-file names of any files involved in the commit (added,
-removed, and modified files).
-
-</P>
-<P>
-The first line with a regular expression matching the
-relative path to the module will be used. If the
-command returns a non-zero exit status the commit will
-be aborted.
-
-</P>
-<P>
-<A NAME="IDX381"></A>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-<A NAME="IDX382"></A>
-All occurances of the name <SAMP>`ALL'</SAMP> appearing as a
-regular expression are used in addition to the first
-matching regular expression or the name <SAMP>`DEFAULT'</SAMP>.
-
-</P>
-<P>
-Note: when CVS is accessing a remote repository,
-<TT>`commitinfo'</TT> will be run on the <EM>remote</EM>
-(i.e., server) side, not the client side (see section <A
HREF="cvs_5.html#SEC24">Remote repositories</A>).
-
-</P>
-
-
-
-<H2><A NAME="SEC142" HREF="cvs_toc.html#TOC142">Editinfo</A></H2>
-<P>
-<A NAME="IDX383"></A>
-<A NAME="IDX384"></A>
-<A NAME="IDX385"></A>
-<A NAME="IDX386"></A>
-
-</P>
-<P>
-If you want to make sure that all log messages look the
-same way, you can use the <TT>`editinfo'</TT> file to
-specify a program that is used to edit the log message.
-This program could be a custom-made editor that always
-enforces a certain style of the log message, or maybe a
-simple shell script that calls an editor, and checks
-that the entered message contains the required fields.
-
-</P>
-<P>
-If no matching line is found in the <TT>`editinfo'</TT>
-file, the editor specified in the environment variable
-<CODE>$CVSEDITOR</CODE> is used instead. If that variable is
-not set, then the environment variable <CODE>$EDITOR</CODE>
-is used instead. If that variable is not
-set a precompiled default, normally <CODE>vi</CODE>, will be
-used.
-
-</P>
-<P>
-The <TT>`editinfo'</TT> file is often most useful together
-with the <TT>`rcsinfo'</TT> file, which can be used to
-specify a log message template.
-
-</P>
-<P>
-Each line in the <TT>`editinfo'</TT> file consists of a
-regular expression and a command-line template. The
-template must include a program name, and can include
-any number of arguments. The full path to the current
-log message template file is appended to the template.
-
-</P>
-<P>
-One thing that should be noted is that the <SAMP>`ALL'</SAMP>
-keyword is not supported. If more than one matching
-line is found, the first one is used. This can be
-useful for specifying a default edit script in a
-module, and then overriding it in a subdirectory.
-
-</P>
-<P>
-<A NAME="IDX387"></A>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-If the edit script exits with a non-zero exit status,
-the commit is aborted.
-
-</P>
-<P>
-Note: when CVS is accessing a remote repository,
-or when the <SAMP>`-m'</SAMP> or <SAMP>`-F'</SAMP> options to <CODE>cvs
-commit</CODE> are used, <TT>`editinfo'</TT> will not be consulted.
-There is no good workaround for this.
-
-</P>
-
-
-
-<H3><A NAME="SEC143" HREF="cvs_toc.html#TOC143">Editinfo example</A></H3>
-
-<P>
-The following is a little silly example of a
-<TT>`editinfo'</TT> file, together with the corresponding
-<TT>`rcsinfo'</TT> file, the log message template and an
-editor script. We begin with the log message template.
-We want to always record a bug-id number on the first
-line of the log message. The rest of log message is
-free text. The following template is found in the file
-<TT>`/usr/cvssupport/tc.template'</TT>.
-
-</P>
-
-<PRE>
-BugId:
-</PRE>
-
-<P>
-The script <TT>`/usr/cvssupport/bugid.edit'</TT> is used to
-edit the log message.
-
-</P>
-
-<PRE>
-#!/bin/sh
-#
-# bugid.edit filename
-#
-# Call $EDITOR on FILENAME, and verify that the
-# resulting file contains a valid bugid on the first
-# line.
-if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
-if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
-$CVSEDITOR $1
-until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
-do echo -n "No BugId found. Edit again? ([y]/n)"
- read ans
- case ${ans} in
- n*) exit 1;;
- esac
- $CVSEDITOR $1
-done
-</PRE>
-
-<P>
-The <TT>`editinfo'</TT> file contains this line:
-
-</P>
-
-<PRE>
-^tc /usr/cvssupport/bugid.edit
-</PRE>
-
-<P>
-The <TT>`rcsinfo'</TT> file contains this line:
-
-</P>
-
-<PRE>
-^tc /usr/cvssupport/tc.template
-</PRE>
-
-
-
-<H2><A NAME="SEC144" HREF="cvs_toc.html#TOC144">Loginfo</A></H2>
-<P>
-<A NAME="IDX388"></A>
-<A NAME="IDX389"></A>
-<A NAME="IDX390"></A>
-<A NAME="IDX391"></A>
-<A NAME="IDX392"></A>
-
-</P>
-<P>
-The <TT>`loginfo'</TT> file is used to control where
-<SAMP>`cvs commit'</SAMP> log information is sent. The first
-entry on a line is a regular expression which is tested
-against the directory that the change is being made to,
-relative to the <CODE>$CVSROOT</CODE>. If a match is found, then
-the remainder of the line is a filter program that
-should expect log information on its standard input.
-
-</P>
-<P>
-The filter program may use one and only one % modifier
-(a la printf). If <SAMP>`%s'</SAMP> is specified in the filter
-program, a brief title is included (enclosed in single
-quotes) showing the modified file names.
-
-</P>
-<P>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-All occurances of the name <SAMP>`ALL'</SAMP> appearing as a
-regular expression are used in addition to the first
-matching regular expression or <SAMP>`DEFAULT'</SAMP>.
-
-</P>
-<P>
-The first matching regular expression is used.
-
-</P>
-<P>
-See section <A HREF="cvs_21.html#SEC139">The commit support files</A>, for a
description of the syntax of
-the <TT>`loginfo'</TT> file.
-
-</P>
-<P>
-Note: when CVS is accessing a remote repository,
-<TT>`loginfo'</TT> will be run on the <EM>remote</EM>
-(i.e., server) side, not the client side (see section <A
HREF="cvs_5.html#SEC24">Remote repositories</A>).
-
-</P>
-
-
-
-<H3><A NAME="SEC145" HREF="cvs_toc.html#TOC145">Loginfo example</A></H3>
-
-<P>
-The following <TT>`loginfo'</TT> file, together with the
-tiny shell-script below, appends all log messages
-to the file <TT>`$CVSROOT/CVSROOT/commitlog'</TT>,
-and any commits to the administrative files (inside
-the <TT>`CVSROOT'</TT> directory) are also logged in
-<TT>`/usr/adm/cvsroot-log'</TT>.
-
-</P>
-
-<PRE>
-ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog
-^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log
-</PRE>
-
-<P>
-The shell-script <TT>`/usr/local/bin/cvs-log'</TT> looks
-like this:
-
-</P>
-
-<PRE>
-#!/bin/sh
-(echo "-----------------------------------------------------------------";
- echo -n $USER" ";
- date;
- echo;
- sed '1s+'${CVSROOT}'++') >> $1
-</PRE>
-
-
-
-<H3><A NAME="SEC146" HREF="cvs_toc.html#TOC146">Keeping a checked out
copy</A></H3>
-
-<P>
-<A NAME="IDX393"></A>
-<A NAME="IDX394"></A>
-
-</P>
-<P>
-It is often useful to maintain a directory tree which
-contains files which correspond to the latest version
-in the repository. For example, other developers might
-want to refer to the latest sources without having to
-check them out, or you might be maintaining a web site
-with CVS and want every checkin to cause the files
-used by the web server to be updated.
-
-</P>
-<P>
-The way to do this is by having loginfo invoke
-<CODE>cvs update</CODE>. Doing so in the naive way will
-cause a problem with locks, so the <CODE>cvs update</CODE>
-must be run in the background.
-Here is an example (this should all be on one line):
-
-</P>
-
-<PRE>
-^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs;
- cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
-</PRE>
-
-<P>
-This will cause checkins to repository directories
-starting with <CODE>cyclic-pages</CODE> to update the checked
-out tree in <TT>`/u/www/local-docs'</TT>.
-
-</P>
-
-
-<H2><A NAME="SEC147" HREF="cvs_toc.html#TOC147">Rcsinfo</A></H2>
-<P>
-<A NAME="IDX395"></A>
-<A NAME="IDX396"></A>
-<A NAME="IDX397"></A>
-<A NAME="IDX398"></A>
-
-</P>
-<P>
-The <TT>`rcsinfo'</TT> file can be used to specify a form to
-edit when filling out the commit log. The
-<TT>`rcsinfo'</TT> file has a syntax similar to the
-<TT>`editinfo'</TT>, <TT>`commitinfo'</TT> and <TT>`loginfo'</TT>
-files. See section <A HREF="cvs_21.html#SEC140">The common syntax</A>.
Unlike the other files the second
-part is <EM>not</EM> a command-line template. Instead,
-the part after the regular expression should be a full pathname to
-a file containing the log message template.
-
-</P>
-<P>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-All occurances of the name <SAMP>`ALL'</SAMP> appearing as a
-regular expression are used in addition to the first
-matching regular expression or <SAMP>`DEFAULT'</SAMP>.
-
-</P>
-<P>
-The log message template will be used as a default log
-message. If you specify a log message with <SAMP>`cvs
-commit -m <VAR>message</VAR>'</SAMP> or <SAMP>`cvs commit -f
-<VAR>file</VAR>'</SAMP> that log message will override the
-template.
-
-</P>
-<P>
-See section <A HREF="cvs_21.html#SEC143">Editinfo example</A>, for an example
<TT>`rcsinfo'</TT>
-file.
-
-</P>
-<P>
-When CVS is accessing a remote repository,
-the contents of <TT>`rcsinfo'</TT> at the time a directory
-is first checked out will specify a template which does
-not then change. If you edit <TT>`rcsinfo'</TT> or its
-templates, you may need to check out a new working
-directory.
-
-</P>
-
-
-<H2><A NAME="SEC148" HREF="cvs_toc.html#TOC148">Ignoring files via
cvsignore</A></H2>
-<P>
-<A NAME="IDX399"></A>
-<A NAME="IDX400"></A>
-<A NAME="IDX401"></A>
-
-</P>
-<P>
-There are certain file names that frequently occur
-inside your working copy, but that you don't want to
-put under CVS control. Examples are all the object
-files that you get while you compile your sources.
-Normally, when you run <SAMP>`cvs update'</SAMP>, it prints a
-line for each file it encounters that it doesn't know
-about (see section <A HREF="cvs_20.html#SEC134">update output</A>).
-
-</P>
-<P>
-CVS has a list of files (or sh(1) file name patterns)
-that it should ignore while running <CODE>update</CODE>,
-<CODE>import</CODE> and <CODE>release</CODE>.
-This list is constructed in the following way.
-
-</P>
-
-<UL>
-<LI>
-
-The list is initialized to include certain file name
-patterns: names associated with CVS
-administration, or with other common source control
-systems; common names for patch files, object files,
-archive files, and editor backup files; and other names
-that are usually artifacts of assorted utilities.
-Currently, the default list of ignored file name
-patterns is:
-
-<A NAME="IDX402"></A>
-<A NAME="IDX403"></A>
-
-<PRE>
- RCS SCCS CVS CVS.adm
- RCSLOG cvslog.*
- tags TAGS
- .make.state .nse_depinfo
- *~ #* .#* ,* _$* *$
- *.old *.bak *.BAK *.orig *.rej .del-*
- *.a *.olb *.o *.obj *.so *.exe
- *.Z *.elc *.ln
- core
-</PRE>
-
-<LI>
-
-The per-repository list in
-<TT>`$CVSROOT/CVSROOT/cvsignore'</TT> is appended to
-the list, if that file exists.
-
-<LI>
-
-The per-user list in <TT>`.cvsignore'</TT> in your home
-directory is appended to the list, if it exists.
-
-<LI>
-
-Any entries in the environment variable
-<CODE>$CVSIGNORE</CODE> is appended to the list.
-
-<LI>
-
-Any <SAMP>`-I'</SAMP> options given to CVS is appended.
-
-<LI>
-
-As CVS traverses through your directories, the contents
-of any <TT>`.cvsignore'</TT> will be appended to the list.
-The patterns found in <TT>`.cvsignore'</TT> are only valid
-for the directory that contains them, not for
-any sub-directories.
-</UL>
-
-<P>
-In any of the 5 places listed above, a single
-exclamation mark (<SAMP>`!'</SAMP>) clears the ignore list.
-This can be used if you want to store any file which
-normally is ignored by CVS.
-
-</P>
-
-
-<H2><A NAME="SEC149" HREF="cvs_toc.html#TOC149">The history file</A></H2>
-<P>
-<A NAME="IDX404"></A>
-<A NAME="IDX405"></A>
-
-</P>
-<P>
-The file <TT>`$CVSROOT/CVSROOT/history'</TT> is used
-to log information for the <CODE>history</CODE> command
-(see section <A HREF="cvs_20.html#SEC110">history--Show status of files and
users</A>). This file must be created to turn
-on logging. This is done automatically if the
-<CODE>cvs init</CODE> command is used to set up the
-repository (see section <A HREF="cvs_5.html#SEC23">Creating a repository</A>).
-
-</P>
-<P>
-The file format of the <TT>`history'</TT> file is
-documented only in comments in the CVS source
-code, but generally programs should use the <CODE>cvs
-history</CODE> command to access it anyway, in case the
-format changes with future releases of CVS.
-
-</P>
-
-
-<H2><A NAME="SEC150" HREF="cvs_toc.html#TOC150">Expansions in administrative
files</A></H2>
-
-<P>
-Sometimes in writing an administrative file, you might
-want the file to be able to know various things based
-on environment CVS is running in. There are
-several mechanisms to do that.
-
-</P>
-<P>
-To find the home directory of the user running CVS
-(from the <CODE>HOME</CODE> environment variable), use
-<SAMP>`~'</SAMP> followed by <SAMP>`/'</SAMP> or the end of the line.
-Likewise for the home directory of <VAR>user</VAR>, use
-<SAMP>`~<VAR>user</VAR>'</SAMP>. These variables are expanded on
-the server machine, and don't get any resonable
-expansion if pserver (see section <A HREF="cvs_5.html#SEC26">Direct connection
with password authentication</A>)
-is in used; therefore user variables (see below) may be
-a better choice to customize behavior based on the user
-running CVS.
-
-</P>
-<P>
-One may want to know about various pieces of
-information internal to CVS. A CVS internal
-variable has the syntax <CODE>${<VAR>variable</VAR>}</CODE>,
-where <VAR>variable</VAR> starts with a letter and consists
-of alphanumberic characters and <SAMP>`_'</SAMP>. If the
-character following <VAR>variable</VAR> is a
-non-alphanumeric character other than <SAMP>`_'</SAMP>, the
-<SAMP>`{'</SAMP> and <SAMP>`}'</SAMP> can be omitted. The CVS
-internal variables are:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>CVSROOT</CODE>
-<DD>
-This is the value of the CVS root in use.
-See section <A HREF="cvs_5.html#SEC15">The Repository</A>, for a description
of the various
-ways to specify this.
-
-<DT><CODE>RCSBIN</CODE>
-<DD>
-This is the value CVS is using for where to find
-RCS binaries. See section <A HREF="cvs_20.html#SEC89">Global options</A>, for
a
-description of how to specify this.
-
-<DT><CODE>CVSEDITOR</CODE>
-<DD>
-<DT><CODE>VISUAL</CODE>
-<DD>
-<DT><CODE>EDITOR</CODE>
-<DD>
-These all expand to the same value, which is the editor
-that CVS is using. See section <A HREF="cvs_20.html#SEC89">Global
options</A>, for how
-to specify this.
-
-<DT><CODE>USER</CODE>
-<DD>
-Username of the user running CVS (on the CVS
-server machine).
-</DL>
-
-<P>
-If you want to pass a value to the administrative files
-which the user that is running CVS can specify,
-use a user variable. To expand a user variable, the
-administrative file contains
-<CODE>${=<VAR>variable</VAR>}</CODE>. To set a user variable,
-specify the global option <SAMP>`-s'</SAMP> to CVS, with
-argument <CODE><VAR>variable</VAR>=<VAR>value</VAR></CODE>. It may be
-particularly useful to specify this option via
-<TT>`.cvsrc'</TT> (see section <A HREF="cvs_20.html#SEC88">Default options and
the ~/.cvsrc file</A>).
-
-</P>
-<P>
-For example, if you want the administrative file to
-refer to a test directory you might create a user
-variable <CODE>TESTDIR</CODE>. Then if CVS is invoked
-as <CODE>cvs -s TESTDIR=/work/local/tests</CODE>, and the
-administrative file contains <CODE>sh
-${=TESTDIR}/runtests</CODE>, then that string is expanded
-to <CODE>sh /work/local/tests/runtests</CODE>.
-
-</P>
-<P>
-All other strings containing <SAMP>`$'</SAMP> are reserved;
-there is no way to quote a <SAMP>`$'</SAMP> character so that
-<SAMP>`$'</SAMP> represents itself.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_20.html">previous</A>,
<A HREF="cvs_22.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_22.html
===================================================================
RCS file: manual/html_chapter/cvs_22.html
diff -N manual/html_chapter/cvs_22.html
--- manual/html_chapter/cvs_22.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,234 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - All environment variables which
affect CVS</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_21.html">previous</A>,
<A HREF="cvs_23.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC151" HREF="cvs_toc.html#TOC151">All environment variables
which affect CVS</A></H1>
-<P>
-<A NAME="IDX406"></A>
-<A NAME="IDX407"></A>
-
-</P>
-<P>
-This is a complete list of all environment variables
-that affect CVS.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>$CVSIGNORE</CODE>
-<DD>
-<A NAME="IDX408"></A>
-
-A whitespace-separated list of file name patterns that
-CVS should ignore. See section <A HREF="cvs_21.html#SEC148">Ignoring files via
cvsignore</A>.
-
-<A NAME="IDX409"></A>
-<DT><CODE>$CVSWRAPPERS</CODE>
-<DD>
-A whitespace-separated list of file name patterns that
-CVS should treat as wrappers. See section <A HREF="cvs_21.html#SEC138">The
cvswrappers file</A>.
-
-<A NAME="IDX410"></A>
-<A NAME="IDX411"></A>
-<DT><CODE>$CVSREAD</CODE>
-<DD>
-If this is set, <CODE>checkout</CODE> and <CODE>update</CODE> will
-try hard to make the files in your working directory
-read-only. When this is not set, the default behavior
-is to permit modification of your working files.
-
-<A NAME="IDX412"></A>
-<DT><CODE>$CVSROOT</CODE>
-<DD>
-Should contain the full pathname to the root of the CVS
-source repository (where the RCS history files are
-kept). This information must be available to CVS for
-most commands to execute; if <CODE>$CVSROOT</CODE> is not set,
-or if you wish to override it for one invocation, you
-can supply it on the command line: <SAMP>`cvs -d cvsroot
-cvs_command...'</SAMP> Once you have checked out a working
-directory, CVS stores the appropriate root (in
-the file <TT>`CVS/Root'</TT>), so normally you only need to
-worry about this when initially checking out a working
-directory.
-
-<A NAME="IDX413"></A>
-<A NAME="IDX414"></A>
-<DT><CODE>$EDITOR</CODE>
-<DD>
-<DT><CODE>$CVSEDITOR</CODE>
-<DD>
-Specifies the program to use for recording log messages
-during commit. If not set, the default is
-<SAMP>`/usr/ucb/vi'</SAMP>. <CODE>$CVSEDITOR</CODE> overrides
-<CODE>$EDITOR</CODE>. <CODE>$CVSEDITOR</CODE> does not exist in
-CVS 1.3, but the next release will probably
-include it.
-
-<A NAME="IDX415"></A>
-<DT><CODE>$PATH</CODE>
-<DD>
-If <CODE>$RCSBIN</CODE> is not set, and no path is compiled
-into CVS, it will use <CODE>$PATH</CODE> to try to find all
-programs it uses.
-
-<A NAME="IDX416"></A>
-<DT><CODE>$RCSBIN</CODE>
-<DD>
-This is the value CVS is using for where to find
-RCS binaries. See section <A HREF="cvs_20.html#SEC89">Global options</A>, for
a
-description of how to specify this. If not set, a
-compiled-in value is used, or your <CODE>$PATH</CODE> is searched.
-
-<A NAME="IDX417"></A>
-<DT><CODE>$HOME</CODE>
-<DD>
-<A NAME="IDX418"></A>
-<DT><CODE>$HOMEPATH</CODE>
-<DD>
-Used to locate the directory where the <TT>`.cvsrc'</TT>
-file is searched (<CODE>$HOMEPATH</CODE> is used for Windows-NT).
-see section <A HREF="cvs_20.html#SEC88">Default options and the ~/.cvsrc
file</A>
-
-<A NAME="IDX419"></A>
-<DT><CODE>$CVS_RSH</CODE>
-<DD>
-Specifies the external program which CVS connects with,
-when <CODE>:ext:</CODE> access method is specified.
-see section <A HREF="cvs_5.html#SEC25">Connecting with rsh</A>.
-
-<DT><CODE>$CVS_SERVER</CODE>
-<DD>
-Used in client-server mode when accessing a remote
-repository using RSH. It specifies the name of
-the program to start on the server side when accessing
-a remote repository using RSH. The default value
-is <CODE>cvs</CODE>. see section <A HREF="cvs_5.html#SEC25">Connecting with
rsh</A>
-
-<DT><CODE>$CVS_PASSFILE</CODE>
-<DD>
-Used in client-server mode when accessing the <CODE>cvs
-login server</CODE>. Default value is <TT>`$HOME/.cvspass'</TT>.
-see section <A HREF="cvs_5.html#SEC28">Using the client with password
authentication</A>
-
-<DT><CODE>$CVS_PASSWORD</CODE>
-<DD>
-Used in client-server mode when accessing the <CODE>cvs
-login server</CODE>.
-see section <A HREF="cvs_5.html#SEC28">Using the client with password
authentication</A>
-
-<DT><CODE>$CVS_CLIENT_PORT</CODE>
-<DD>
-Used in client-server mode when accessing the server
-via Kerberos.
-see section <A HREF="cvs_5.html#SEC30">Direct connection with kerberos</A>
-
-<A NAME="IDX420"></A>
-<DT><CODE>$CVS_RCMD_PORT</CODE>
-<DD>
-Used in client-server mode. If set, specifies the port
-number to be used when accessing the RCMD demon on
-the server side. (Currently not used for Unix clients).
-
-<A NAME="IDX421"></A>
-<DT><CODE>$CVS_CLIENT_LOG</CODE>
-<DD>
-Used for debugging only in client-server
-mode. If set, everything send to the server is logged
-into <TT>`<CODE>$CVS_CLIENT_LOG</CODE>.in'</TT> and everything
-send from the server is logged into
-<TT>`<CODE>$CVS_CLIENT_LOG</CODE>.out'</TT>.
-
-<A NAME="IDX422"></A>
-<DT><CODE>$CVS_SERVER_SLEEP</CODE>
-<DD>
-Used only for debugging the server side in
-client-server mode. If set, delays the start of the
-server child process the the specified amount of
-seconds so that you can attach to it with a debugger.
-
-<A NAME="IDX423"></A>
-<DT><CODE>$CVS_IGNORE_REMOTE_ROOT</CODE>
-<DD>
-(What is the purpose of this variable?)
-
-<A NAME="IDX424"></A>
-<DT><CODE>$COMSPEC</CODE>
-<DD>
-Used under OS/2 only. It specifies the name of the
-command interpreter and defaults to CMD.EXE.
-
-<A NAME="IDX425"></A>
-<DT><CODE>$TMPDIR</CODE>
-<DD>
-<A NAME="IDX426"></A>
-<DT><CODE>$TMP</CODE>
-<DD>
-<A NAME="IDX427"></A>
-<DT><CODE>$TEMP</CODE>
-<DD>
-<A NAME="IDX428"></A>
-Directory in which temporary files are located. Those
-parts of CVS which are implemented using RCS
-inspect the above variables in the order they appear
-above and the first value found is taken; if none of
-them are set, a host-dependent default is used,
-typically <TT>`/tmp'</TT>. The CVS server uses
-<CODE>TMPDIR</CODE>. See section <A HREF="cvs_20.html#SEC89">Global
options</A>, for a
-description of how to specify this.
-Some parts of CVS will always use <TT>`/tmp'</TT> (via
-the <CODE>tmpnam</CODE> function provided by the system).
-
-On Windows NT, <CODE>TMP</CODE> is used (via the <CODE>_tempnam</CODE>
-function provided by the system).
-
-The <CODE>patch</CODE> program which is used by the CVS
-client uses <CODE>TMPDIR</CODE>, and if it is not set, uses
-<TT>`/tmp'</TT> (at least with GNU patch 2.1).
-</DL>
-
-<P>
-CVS invokes RCS to perform certain
-operations. The following environment
-variables affect RCS. Note that if you are using
-the client/server CVS, these variables need to be
-set on the server side (which may or not may be
-possible depending on how you are connecting). There
-is probably not any need to set any of them, however.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>$LOGNAME</CODE>
-<DD>
-<A NAME="IDX429"></A>
-
-<A NAME="IDX430"></A>
-<DT><CODE>$USER</CODE>
-<DD>
-If set, they affect who RCS thinks you are. If you
-have trouble checking in files it might be because your
-login name differs from the setting of e.g.
-<CODE>$LOGNAME</CODE>.
-
-<A NAME="IDX431"></A>
-<DT><CODE>$RCSINIT</CODE>
-<DD>
-Options prepended to the argument list, separated by
-spaces. A backslash escapes spaces within an option.
-The <CODE>$RCSINIT</CODE> options are prepended to the
-argument lists of most RCS commands.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_21.html">previous</A>,
<A HREF="cvs_23.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_23.html
===================================================================
RCS file: manual/html_chapter/cvs_23.html
diff -N manual/html_chapter/cvs_23.html
--- manual/html_chapter/cvs_23.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,71 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Troubleshooting</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_22.html">previous</A>,
<A HREF="cvs_24.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC152" HREF="cvs_toc.html#TOC152">Troubleshooting</A></H1>
-
-
-
-<H2><A NAME="SEC153" HREF="cvs_toc.html#TOC153">Magic branch numbers</A></H2>
-
-<P>
-Externally, branch numbers consist of an odd number of
-dot-separated decimal integers. See section <A
HREF="cvs_3.html#SEC8">Revision numbers</A>. That is not the whole truth,
however. For
-efficiency reasons CVS sometimes inserts an extra 0
-in the second rightmost position (1.2.3 becomes
-1.2.0.3, 8.9.10.11.12 becomes 8.9.10.11.0.12 and so
-on).
-
-</P>
-<P>
-CVS does a pretty good job at hiding these so
-called magic branches, but in a few places the hiding
-is incomplete:
-
-</P>
-
-<UL>
-<LI>
-
-The magic branch number appears in the output from
-<CODE>cvs log</CODE>.
-
-<LI>
-
-You cannot specify a symbolic branch name to <CODE>cvs
-admin</CODE>.
-
-</UL>
-
-<P>
-You can use the <CODE>admin</CODE> command to reassign a
-symbolic name to a branch the way RCS expects it
-to be. If <CODE>R4patches</CODE> is assigned to the branch
-1.4.2 (magic branch number 1.4.0.2) in file
-<TT>`numbers.c'</TT> you can do this:
-
-</P>
-
-<PRE>
-$ cvs admin -NR4patches:1.4.2 numbers.c
-</PRE>
-
-<P>
-It only works if at least one revision is already
-committed on the branch. Be very careful so that you
-do not assign the tag to the wrong number. (There is
-no way to see how the tag was assigned yesterday).
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_22.html">previous</A>,
<A HREF="cvs_24.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_24.html
===================================================================
RCS file: manual/html_chapter/cvs_24.html
diff -N manual/html_chapter/cvs_24.html
--- manual/html_chapter/cvs_24.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,18 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - GNU GENERAL PUBLIC LICENSE</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_23.html">previous</A>,
<A HREF="cvs_25.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC154" HREF="cvs_toc.html#TOC154">GNU GENERAL PUBLIC
LICENSE</A></H1>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_23.html">previous</A>,
<A HREF="cvs_25.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_25.html
===================================================================
RCS file: manual/html_chapter/cvs_25.html
diff -N manual/html_chapter/cvs_25.html
--- manual/html_chapter/cvs_25.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,602 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Index</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_24.html">previous</A>,
next, last section, <A HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC155" HREF="cvs_toc.html#TOC155">Index</A></H1>
-<P>
-<A NAME="IDX432"></A>
-
-</P>
-<P>
-Jump to:
-<A HREF="#cindex_-">-</A>
--
-<A HREF="#cindex_.">.</A>
--
-<A HREF="#cindex_/">/</A>
--
-<A HREF="#cindex_:">:</A>
--
-<A HREF="#cindex_<"><</A>
--
-<A HREF="#cindex_=">=</A>
--
-<A HREF="#cindex_>">></A>
--
-<A HREF="#cindex__">_</A>
--
-<A HREF="#cindex_a">a</A>
--
-<A HREF="#cindex_b">b</A>
--
-<A HREF="#cindex_c">c</A>
--
-<A HREF="#cindex_d">d</A>
--
-<A HREF="#cindex_e">e</A>
--
-<A HREF="#cindex_f">f</A>
--
-<A HREF="#cindex_g">g</A>
--
-<A HREF="#cindex_h">h</A>
--
-<A HREF="#cindex_i">i</A>
--
-<A HREF="#cindex_j">j</A>
--
-<A HREF="#cindex_k">k</A>
--
-<A HREF="#cindex_l">l</A>
--
-<A HREF="#cindex_m">m</A>
--
-<A HREF="#cindex_n">n</A>
--
-<A HREF="#cindex_o">o</A>
--
-<A HREF="#cindex_p">p</A>
--
-<A HREF="#cindex_r">r</A>
--
-<A HREF="#cindex_s">s</A>
--
-<A HREF="#cindex_t">t</A>
--
-<A HREF="#cindex_u">u</A>
--
-<A HREF="#cindex_v">v</A>
--
-<A HREF="#cindex_w">w</A>
--
-<A HREF="#cindex_z">z</A>
-<P>
-<H2><A NAME="cindex_-">-</A></H2>
-<DIR>
-<LI><A HREF="cvs_9.html#IDX229">-j (merging branches)</A>
-<LI><A HREF="cvs_17.html#IDX286">-k (RCS kflags)</A>
-</DIR>
-<H2><A NAME="cindex_.">.</A></H2>
-<DIR>
-<LI><A HREF="cvs_20.html#IDX356">.# files</A>
-<LI><A HREF="cvs_5.html#IDX66">.bashrc, setting CVSROOT in</A>
-<LI><A HREF="cvs_5.html#IDX64">.cshrc, setting CVSROOT in</A>
-<LI><A HREF="cvs_20.html#IDX300">.cvsrc file</A>
-<LI><A HREF="cvs_5.html#IDX63">.profile, setting CVSROOT in</A>
-<LI><A HREF="cvs_5.html#IDX65">.tcshrc, setting CVSROOT in</A>
-</DIR>
-<H2><A NAME="cindex_/">/</A></H2>
-<DIR>
-<LI><A HREF="cvs_5.html#IDX60">/usr/local/cvsroot, as example repository</A>
-</DIR>
-<H2><A NAME="cindex_:">:</A></H2>
-<DIR>
-<LI><A HREF="cvs_5.html#IDX101">:ext:</A>
-<LI><A HREF="cvs_5.html#IDX114">:kserver:</A>
-<LI><A HREF="cvs_5.html#IDX62">:local:</A>
-<LI><A HREF="cvs_5.html#IDX110">:pserver:</A>
-<LI><A HREF="cvs_5.html#IDX100">:server:</A>
-</DIR>
-<H2><A NAME="cindex_<"><</A></H2>
-<DIR>
-<LI><A HREF="cvs_7.html#IDX157"><<<<<<<</A>
-</DIR>
-<H2><A NAME="cindex_=">=</A></H2>
-<DIR>
-<LI><A HREF="cvs_7.html#IDX159">=======</A>
-</DIR>
-<H2><A NAME="cindex_>">></A></H2>
-<DIR>
-<LI><A HREF="cvs_7.html#IDX158">>>>>>>></A>
-</DIR>
-<H2><A NAME="cindex__">_</A></H2>
-<DIR>
-<LI><A HREF="cvs_20.html#IDX357">__ files (VMS)</A>
-</DIR>
-<H2><A NAME="cindex_a">a</A></H2>
-<DIR>
-<LI><A HREF="cvs_4.html#IDX35">A sample session</A>
-<LI><A HREF="cvs_7.html#IDX185">abandoning work</A>
-<LI><A HREF="cvs_1.html#IDX2">About this manual</A>
-<LI><A HREF="cvs_11.html#IDX244">add (subcommand)</A>
-<LI><A HREF="cvs_8.html#IDX203">Adding a tag</A>
-<LI><A HREF="cvs_11.html#IDX243">Adding files</A>
-<LI><A HREF="cvs_20.html#IDX328">Admin (subcommand)</A>
-<LI><A HREF="cvs_5.html#IDX79">Administrative files (intro)</A>
-<LI><A HREF="cvs_21.html#IDX358">Administrative files (reference)</A>
-<LI><A HREF="cvs_5.html#IDX84">Administrative files, editing them</A>
-<LI><A HREF="cvs_21.html#IDX382">ALL in commitinfo</A>
-<LI><A HREF="cvs_16.html#IDX267">annotate (subcommand)</A>
-<LI><A HREF="cvs_7.html#IDX167">Atomic transactions, lack of</A>
-<LI><A HREF="cvs_5.html#IDX109">authenticated client, using</A>
-<LI><A HREF="cvs_5.html#IDX104">authenticating server, setting up</A>
-<LI><A HREF="cvs_17.html#IDX273">Author keyword</A>
-<LI><A HREF="cvs_21.html#IDX403">Automatically ignored files</A>
-<LI><A HREF="cvs_20.html#IDX327">Avoiding editor invocation</A>
-</DIR>
-<H2><A NAME="cindex_b">b</A></H2>
-<DIR>
-<LI><A HREF="cvs_18.html#IDX288">Binary files</A>
-<LI><A HREF="cvs_9.html#IDX231">Branch merge example</A>
-<LI><A HREF="cvs_3.html#IDX30">Branch number</A>
-<LI><A HREF="cvs_8.html#IDX213">Branch numbers</A>
-<LI><A HREF="cvs_8.html#IDX211">Branch, creating a</A>
-<LI><A HREF="cvs_13.html#IDX254">Branch, vendor-</A>
-<LI><A HREF="cvs_8.html#IDX194">Branches</A>
-<LI><A HREF="cvs_8.html#IDX207">Branches motivation</A>
-<LI><A HREF="cvs_9.html#IDX225">Branches, copying changes between</A>
-<LI><A HREF="cvs_8.html#IDX216">Branches, sticky</A>
-<LI><A HREF="cvs_7.html#IDX146">Bringing a file up to date</A>
-<LI><A HREF="cvs_1.html#IDX7">Bugs, known in this manual</A>
-<LI><A HREF="cvs_1.html#IDX10">Bugs, reporting (manual)</A>
-</DIR>
-<H2><A NAME="cindex_c">c</A></H2>
-<DIR>
-<LI><A HREF="cvs_9.html#IDX226">Changes, copying between branches</A>
-<LI><A HREF="cvs_20.html#IDX329">Changing a log message</A>
-<LI><A HREF="cvs_21.html#IDX394">checked out copy, keeping</A>
-<LI><A HREF="cvs_21.html#IDX365">Checkin program</A>
-<LI><A HREF="cvs_21.html#IDX379">Checking commits</A>
-<LI><A HREF="cvs_4.html#IDX42">Checking out source</A>
-<LI><A HREF="cvs_20.html#IDX340">Checkout (subcommand)</A>
-<LI><A HREF="cvs_21.html#IDX366">Checkout program</A>
-<LI><A HREF="cvs_7.html#IDX181">checkout, as term for getting ready to edit</A>
-<LI><A HREF="cvs_4.html#IDX45">Checkout, example</A>
-<LI><A HREF="cvs_7.html#IDX193">choosing, reserved or unreserved checkouts</A>
-<LI><A HREF="cvs_4.html#IDX50">Cleaning up</A>
-<LI><A HREF="cvs_5.html#IDX97">Client/Server Operation</A>
-<LI><A HREF="cvs_20.html#IDX341">Co (subcommand)</A>
-<LI><A HREF="cvs_20.html#IDX293">Command reference</A>
-<LI><A HREF="cvs_20.html#IDX298">Command structure</A>
-<LI><A HREF="cvs_20.html#IDX337">Comment leader</A>
-<LI><A HREF="cvs_20.html#IDX342">Commit (subcommand)</A>
-<LI><A HREF="cvs_21.html#IDX374">Commit files</A>
-<LI><A HREF="cvs_19.html#IDX291">Commit, when to</A>
-<LI><A HREF="cvs_21.html#IDX378">Commitinfo</A>
-<LI><A HREF="cvs_4.html#IDX46">Committing changes</A>
-<LI><A HREF="cvs_20.html#IDX318">Common options</A>
-<LI><A HREF="cvs_21.html#IDX377">Common syntax of info files</A>
-<LI><A HREF="cvs_22.html#IDX424">COMSPEC</A>
-<LI><A HREF="cvs_7.html#IDX156">Conflict markers</A>
-<LI><A HREF="cvs_7.html#IDX161">Conflict resolution</A>
-<LI><A HREF="cvs_7.html#IDX154">Conflicts (merge example)</A>
-<LI><A HREF="cvs_2.html#IDX18">Contributors (CVS program)</A>
-<LI><A HREF="cvs_1.html#IDX5">Contributors (manual)</A>
-<LI><A HREF="cvs_9.html#IDX224">Copying changes</A>
-<LI><A HREF="cvs_20.html#IDX331">Correcting a log message</A>
-<LI><A HREF="cvs_8.html#IDX210">Creating a branch</A>
-<LI><A HREF="cvs_6.html#IDX118">Creating a project</A>
-<LI><A HREF="cvs_5.html#IDX92">Creating a repository</A>
-<LI><A HREF="cvs_2.html#IDX17">Credits (CVS program)</A>
-<LI><A HREF="cvs_1.html#IDX6">Credits (manual)</A>
-<LI><A HREF="cvs_7.html#IDX192">CVS 1.6, and watches</A>
-<LI><A HREF="cvs_20.html#IDX297">CVS command structure</A>
-<LI><A HREF="cvs_5.html#IDX105">CVS passwd file</A>
-<LI><A HREF="cvs_2.html#IDX16">CVS, history of</A>
-<LI><A HREF="cvs_2.html#IDX14">CVS, introduction to</A>
-<LI><A HREF="cvs_22.html#IDX421">CVS_CLIENT_LOG</A>
-<LI><A HREF="cvs_5.html#IDX115">CVS_CLIENT_PORT</A>
-<LI><A HREF="cvs_22.html#IDX423">CVS_IGNORE_REMOTE_ROOT</A>
-<LI><A HREF="cvs_5.html#IDX111">CVS_PASSFILE, environment variable</A>
-<LI><A HREF="cvs_5.html#IDX112">CVS_PASSWORD, environment variable</A>
-<LI><A HREF="cvs_22.html#IDX420">CVS_RCMD_PORT</A>
-<LI><A HREF="cvs_22.html#IDX419">CVS_RSH</A>
-<LI><A HREF="cvs_5.html#IDX99">CVS_SERVER</A>
-<LI><A HREF="cvs_22.html#IDX422">CVS_SERVER_SLEEP</A>
-<LI><A HREF="cvs_22.html#IDX414">CVSEDITOR</A>
-<LI><A HREF="cvs_4.html#IDX48">CVSEDITOR, environment variable</A>
-<LI><A HREF="cvs_22.html#IDX408">CVSIGNORE</A>
-<LI><A HREF="cvs_21.html#IDX399">cvsignore (admin file), global</A>
-<LI><A HREF="cvs_22.html#IDX410">CVSREAD</A>
-<LI><A HREF="cvs_20.html#IDX316">CVSREAD, overriding</A>
-<LI><A HREF="cvs_22.html#IDX412">CVSROOT</A>
-<LI><A HREF="cvs_5.html#IDX61">cvsroot</A>
-<LI><A HREF="cvs_21.html#IDX361">CVSROOT (file)</A>
-<LI><A HREF="cvs_5.html#IDX67">CVSROOT, environment variable</A>
-<LI><A HREF="cvs_5.html#IDX81">CVSROOT, module name</A>
-<LI><A HREF="cvs_5.html#IDX90">CVSROOT, multiple repositories</A>
-<LI><A HREF="cvs_20.html#IDX309">CVSROOT, overriding</A>
-<LI><A HREF="cvs_5.html#IDX75">CVSUMASK</A>
-<LI><A HREF="cvs_22.html#IDX409">CVSWRAPPERS</A>
-<LI><A HREF="cvs_21.html#IDX371">cvswrappers (admin file)</A>
-<LI><A HREF="cvs_21.html#IDX372">CVSWRAPPERS, environment variable</A>
-</DIR>
-<H2><A NAME="cindex_d">d</A></H2>
-<DIR>
-<LI><A HREF="cvs_17.html#IDX274">Date keyword</A>
-<LI><A HREF="cvs_20.html#IDX320">Dates</A>
-<LI><A HREF="cvs_3.html#IDX28">Decimal revision number</A>
-<LI><A HREF="cvs_21.html#IDX381">DEFAULT in commitinfo</A>
-<LI><A HREF="cvs_21.html#IDX387">DEFAULT in editinfo</A>
-<LI><A HREF="cvs_6.html#IDX123">Defining a module</A>
-<LI><A HREF="cvs_5.html#IDX82">Defining modules (intro)</A>
-<LI><A HREF="cvs_21.html#IDX363">Defining modules (reference manual)</A>
-<LI><A HREF="cvs_12.html#IDX247">Deleting files</A>
-<LI><A HREF="cvs_20.html#IDX334">Deleting revisions</A>
-<LI><A HREF="cvs_8.html#IDX219">Deleting sticky tags</A>
-<LI><A HREF="cvs_10.html#IDX241">Descending directories</A>
-<LI><A HREF="cvs_4.html#IDX55">Diff</A>
-<LI><A HREF="cvs_20.html#IDX343">Diff (subcommand)</A>
-<LI><A HREF="cvs_9.html#IDX236">Differences, merging</A>
-<LI><A HREF="cvs_15.html#IDX262">Directories, moving</A>
-<LI><A HREF="cvs_10.html#IDX240">Directory, descending</A>
-<LI><A HREF="cvs_5.html#IDX89">Disjoint repositories</A>
-<LI><A HREF="cvs_21.html#IDX391">Distributing log messages</A>
-<LI><A HREF="cvs_7.html#IDX153">driver.c (merge example)</A>
-</DIR>
-<H2><A NAME="cindex_e">e</A></H2>
-<DIR>
-<LI><A HREF="cvs_7.html#IDX182">edit (subcommand)</A>
-<LI><A HREF="cvs_21.html#IDX383">editinfo (admin file)</A>
-<LI><A HREF="cvs_5.html#IDX83">Editing administrative files</A>
-<LI><A HREF="cvs_6.html#IDX124">Editing the modules file</A>
-<LI><A HREF="cvs_22.html#IDX413">EDITOR</A>
-<LI><A HREF="cvs_20.html#IDX326">Editor, avoiding invocation of</A>
-<LI><A HREF="cvs_4.html#IDX49">EDITOR, environment variable</A>
-<LI><A HREF="cvs_20.html#IDX311">EDITOR, overriding</A>
-<LI><A HREF="cvs_21.html#IDX384">Editor, specifying per module</A>
-<LI><A HREF="cvs_7.html#IDX190">editors (subcommand)</A>
-<LI><A HREF="cvs_7.html#IDX162">emerge</A>
-<LI><A HREF="cvs_22.html#IDX406">Environment variables</A>
-<LI><A HREF="cvs_1.html#IDX11">Errors, reporting (manual)</A>
-<LI><A HREF="cvs_4.html#IDX36">Example of a work-session</A>
-<LI><A HREF="cvs_7.html#IDX152">Example of merge</A>
-<LI><A HREF="cvs_9.html#IDX232">Example, branch merge</A>
-<LI><A HREF="cvs_20.html#IDX344">Export (subcommand)</A>
-<LI><A HREF="cvs_21.html#IDX364">Export program</A>
-</DIR>
-<H2><A NAME="cindex_f">f</A></H2>
-<DIR>
-<LI><A HREF="cvs_4.html#IDX43">Fetching source</A>
-<LI><A HREF="cvs_7.html#IDX129">File locking</A>
-<LI><A HREF="cvs_5.html#IDX72">File permissions</A>
-<LI><A HREF="cvs_7.html#IDX135">File status</A>
-<LI><A HREF="cvs_14.html#IDX259">Files, moving</A>
-<LI><A HREF="cvs_21.html#IDX359">Files, reference manual</A>
-<LI><A HREF="cvs_20.html#IDX332">Fixing a log message</A>
-<LI><A HREF="cvs_20.html#IDX325">Forcing a tag match</A>
-<LI><A HREF="cvs_21.html#IDX396">Form for log message</A>
-<LI><A HREF="cvs_20.html#IDX299">Format of CVS commands</A>
-</DIR>
-<H2><A NAME="cindex_g">g</A></H2>
-<DIR>
-<LI><A HREF="cvs_4.html#IDX37">Getting started</A>
-<LI><A HREF="cvs_4.html#IDX41">Getting the source</A>
-<LI><A HREF="cvs_21.html#IDX400">Global cvsignore</A>
-<LI><A HREF="cvs_20.html#IDX303">Global options</A>
-<LI><A HREF="cvs_5.html#IDX73">Group</A>
-</DIR>
-<H2><A NAME="cindex_h">h</A></H2>
-<DIR>
-<LI><A HREF="cvs_17.html#IDX275">Header keyword</A>
-<LI><A HREF="cvs_20.html#IDX345">History (subcommand)</A>
-<LI><A HREF="cvs_16.html#IDX263">History browsing</A>
-<LI><A HREF="cvs_21.html#IDX404">History file</A>
-<LI><A HREF="cvs_5.html#IDX69">History files</A>
-<LI><A HREF="cvs_2.html#IDX15">History of CVS</A>
-<LI><A HREF="cvs_22.html#IDX417">HOME</A>
-<LI><A HREF="cvs_22.html#IDX418">HOMEPATH</A>
-</DIR>
-<H2><A NAME="cindex_i">i</A></H2>
-<DIR>
-<LI><A HREF="cvs_17.html#IDX276">Id keyword</A>
-<LI><A HREF="cvs_17.html#IDX284">Ident (shell command)</A>
-<LI><A HREF="cvs_17.html#IDX271">Identifying files</A>
-<LI><A HREF="cvs_21.html#IDX402">Ignored files</A>
-<LI><A HREF="cvs_21.html#IDX401">Ignoring files</A>
-<LI><A HREF="cvs_20.html#IDX346">Import (subcommand)</A>
-<LI><A HREF="cvs_6.html#IDX119">Importing files</A>
-<LI><A HREF="cvs_6.html#IDX120">Importing files, from other version control
systesm</A>
-<LI><A HREF="cvs_13.html#IDX255">Importing modules</A>
-<LI><A HREF="cvs_25.html#IDX432">Index</A>
-<LI><A HREF="cvs_21.html#IDX375">Info files (syntax)</A>
-<LI><A HREF="cvs_7.html#IDX163">Informing others</A>
-<LI><A HREF="cvs_5.html#IDX94">init (subcommand)</A>
-<LI><A HREF="cvs_2.html#IDX13">Introduction to CVS</A>
-<LI><A HREF="cvs_20.html#IDX295">Invoking CVS</A>
-<LI><A HREF="cvs_16.html#IDX265">Isolation</A>
-</DIR>
-<H2><A NAME="cindex_j">j</A></H2>
-<DIR>
-<LI><A HREF="cvs_9.html#IDX230">Join</A>
-</DIR>
-<H2><A NAME="cindex_k">k</A></H2>
-<DIR>
-<LI><A HREF="cvs_21.html#IDX393">keeping a checked out copy</A>
-<LI><A HREF="cvs_5.html#IDX113">kerberos</A>
-<LI><A HREF="cvs_17.html#IDX270">Keyword expansion</A>
-<LI><A HREF="cvs_17.html#IDX269">Keyword substitution</A>
-<LI><A HREF="cvs_17.html#IDX287">Kflag</A>
-<LI><A HREF="cvs_5.html#IDX116">kinit</A>
-<LI><A HREF="cvs_1.html#IDX8">Known bugs in this manual</A>
-</DIR>
-<H2><A NAME="cindex_l">l</A></H2>
-<DIR>
-<LI><A HREF="cvs_5.html#IDX58">Layout of repository</A>
-<LI><A HREF="cvs_20.html#IDX304">Left-hand options</A>
-<LI><A HREF="cvs_3.html#IDX26">Linear development</A>
-<LI><A HREF="cvs_2.html#IDX21">List, mailing list</A>
-<LI><A HREF="cvs_7.html#IDX139">Locally Added</A>
-<LI><A HREF="cvs_7.html#IDX138">Locally Modified</A>
-<LI><A HREF="cvs_7.html#IDX140">Locally Removed</A>
-<LI><A HREF="cvs_17.html#IDX278">Locker keyword</A>
-<LI><A HREF="cvs_7.html#IDX130">Locking files</A>
-<LI><A HREF="cvs_7.html#IDX166">locks, cvs</A>
-<LI><A HREF="cvs_20.html#IDX347">Log (subcommand)</A>
-<LI><A HREF="cvs_21.html#IDX405">Log information, saving</A>
-<LI><A HREF="cvs_17.html#IDX279">Log keyword</A>
-<LI><A HREF="cvs_20.html#IDX338">Log keyword, selecting comment leader</A>
-<LI><A HREF="cvs_4.html#IDX47">Log message entry</A>
-<LI><A HREF="cvs_21.html#IDX397">Log message template</A>
-<LI><A HREF="cvs_20.html#IDX333">Log message, correcting</A>
-<LI><A HREF="cvs_21.html#IDX392">Log messages</A>
-<LI><A HREF="cvs_21.html#IDX386">Log messages, editing</A>
-<LI><A HREF="cvs_5.html#IDX107">Login (subcommand)</A>
-<LI><A HREF="cvs_21.html#IDX388">loginfo (admin file)</A>
-<LI><A HREF="cvs_22.html#IDX429">LOGNAME</A>
-</DIR>
-<H2><A NAME="cindex_m">m</A></H2>
-<DIR>
-<LI><A HREF="cvs_7.html#IDX165">Mail, automatic mail on commit</A>
-<LI><A HREF="cvs_2.html#IDX20">Mailing list</A>
-<LI><A HREF="cvs_21.html#IDX390">Mailing log messages</A>
-<LI><A HREF="cvs_3.html#IDX29">Main trunk (intro)</A>
-<LI><A HREF="cvs_8.html#IDX195">Main trunk and branches</A>
-<LI><A HREF="cvs_5.html#IDX87">Many repositories</A>
-<LI><A HREF="cvs_7.html#IDX155">Markers, conflict</A>
-<LI><A HREF="cvs_7.html#IDX151">Merge, an example</A>
-<LI><A HREF="cvs_9.html#IDX233">Merge, branch example</A>
-<LI><A HREF="cvs_9.html#IDX223">Merging</A>
-<LI><A HREF="cvs_9.html#IDX228">Merging a branch</A>
-<LI><A HREF="cvs_7.html#IDX148">Merging a file</A>
-<LI><A HREF="cvs_9.html#IDX234">Merging two revisions</A>
-<LI><A HREF="cvs_9.html#IDX227">Modifications, copying between branches</A>
-<LI><A HREF="cvs_21.html#IDX368">Module status</A>
-<LI><A HREF="cvs_6.html#IDX125">Module, defining</A>
-<LI><A HREF="cvs_21.html#IDX362">Modules (admin file)</A>
-<LI><A HREF="cvs_3.html#IDX23">Modules (intro)</A>
-<LI><A HREF="cvs_5.html#IDX80">Modules file</A>
-<LI><A HREF="cvs_6.html#IDX126">Modules file, changing</A>
-<LI><A HREF="cvs_8.html#IDX209">Motivation for branches</A>
-<LI><A HREF="cvs_15.html#IDX260">Moving directories</A>
-<LI><A HREF="cvs_14.html#IDX257">Moving files</A>
-<LI><A HREF="cvs_7.html#IDX127">Multiple developers</A>
-<LI><A HREF="cvs_5.html#IDX85">Multiple repositories</A>
-</DIR>
-<H2><A NAME="cindex_n">n</A></H2>
-<DIR>
-<LI><A HREF="cvs_17.html#IDX277">Name keyword</A>
-<LI><A HREF="cvs_8.html#IDX202">Name, symbolic (tag)</A>
-<LI><A HREF="cvs_7.html#IDX141">Needs Checkout</A>
-<LI><A HREF="cvs_7.html#IDX143">Needs Merge</A>
-<LI><A HREF="cvs_7.html#IDX142">Needs Patch</A>
-<LI><A HREF="cvs_2.html#IDX22">Newsgroups</A>
-<LI><A HREF="cvs_7.html#IDX179">notify (admin file)</A>
-<LI><A HREF="cvs_20.html#IDX339">Nroff (selecting comment leader)</A>
-<LI><A HREF="cvs_3.html#IDX31">Number, branch</A>
-<LI><A HREF="cvs_3.html#IDX27">Number, revision-</A>
-</DIR>
-<H2><A NAME="cindex_o">o</A></H2>
-<DIR>
-<LI><A HREF="cvs_20.html#IDX301">option defaults</A>
-<LI><A HREF="cvs_20.html#IDX302">Options, global</A>
-<LI><A HREF="cvs_20.html#IDX335">Outdating revisions</A>
-<LI><A HREF="cvs_7.html#IDX150">Overlap</A>
-<LI><A HREF="cvs_20.html#IDX317">Overriding CVSREAD</A>
-<LI><A HREF="cvs_20.html#IDX310">Overriding CVSROOT</A>
-<LI><A HREF="cvs_20.html#IDX312">Overriding EDITOR</A>
-<LI><A HREF="cvs_20.html#IDX306">Overriding RCSBIN</A>
-<LI><A HREF="cvs_20.html#IDX308">Overriding TMPDIR</A>
-</DIR>
-<H2><A NAME="cindex_p">p</A></H2>
-<DIR>
-<LI><A HREF="cvs_5.html#IDX88">Parallel repositories</A>
-<LI><A HREF="cvs_5.html#IDX106">passwd (admin file)</A>
-<LI><A HREF="cvs_5.html#IDX108">password client, using</A>
-<LI><A HREF="cvs_5.html#IDX103">password server, setting up</A>
-<LI><A HREF="cvs_22.html#IDX415">PATH</A>
-<LI><A HREF="cvs_21.html#IDX385">Per-module editor</A>
-<LI><A HREF="cvs_19.html#IDX292">Policy</A>
-<LI><A HREF="cvs_21.html#IDX380">Precommit checking</A>
-<LI><A HREF="cvs_1.html#IDX1">Preface</A>
-<LI><A HREF="cvs_5.html#IDX102">Pserver (subcommand)</A>
-</DIR>
-<H2><A NAME="cindex_r">r</A></H2>
-<DIR>
-<LI><A HREF="cvs_5.html#IDX70">RCS history files</A>
-<LI><A HREF="cvs_17.html#IDX272">RCS keywords</A>
-<LI><A HREF="cvs_8.html#IDX198">RCS revision numbers</A>
-<LI><A HREF="cvs_6.html#IDX121">RCS, importing files from</A>
-<LI><A HREF="cvs_7.html#IDX134">RCS-style locking</A>
-<LI><A HREF="cvs_22.html#IDX416">RCSBIN</A>
-<LI><A HREF="cvs_20.html#IDX305">RCSBIN, overriding</A>
-<LI><A HREF="cvs_17.html#IDX280">RCSfile keyword</A>
-<LI><A HREF="cvs_21.html#IDX395">rcsinfo (admin file)</A>
-<LI><A HREF="cvs_22.html#IDX431">RCSINIT</A>
-<LI><A HREF="cvs_20.html#IDX350">Rdiff (subcommand)</A>
-<LI><A HREF="cvs_20.html#IDX314">read-only files, and -r</A>
-<LI><A HREF="cvs_22.html#IDX411">read-only files, and CVSREAD</A>
-<LI><A HREF="cvs_7.html#IDX172">read-only files, and watches</A>
-<LI><A HREF="cvs_5.html#IDX74">read-only files, in repository</A>
-<LI><A HREF="cvs_20.html#IDX313">Read-only mode</A>
-<LI><A HREF="cvs_10.html#IDX239">Recursive (directory descending)</A>
-<LI><A HREF="cvs_21.html#IDX360">Reference manual (files)</A>
-<LI><A HREF="cvs_22.html#IDX407">Reference manual for variables</A>
-<LI><A HREF="cvs_20.html#IDX294">Reference, commands</A>
-<LI><A HREF="cvs_20.html#IDX351">Release (subcommand)</A>
-<LI><A HREF="cvs_3.html#IDX34">Releases, revisions and versions</A>
-<LI><A HREF="cvs_4.html#IDX53">Releasing your working copy</A>
-<LI><A HREF="cvs_5.html#IDX96">Remote repositories</A>
-<LI><A HREF="cvs_12.html#IDX248">Remove (subcommand)</A>
-<LI><A HREF="cvs_9.html#IDX238">Removing a change</A>
-<LI><A HREF="cvs_12.html#IDX246">Removing files</A>
-<LI><A HREF="cvs_4.html#IDX52">Removing your working copy</A>
-<LI><A HREF="cvs_15.html#IDX261">Renaming directories</A>
-<LI><A HREF="cvs_14.html#IDX258">Renaming files</A>
-<LI><A HREF="cvs_20.html#IDX330">Replacing a log message</A>
-<LI><A HREF="cvs_1.html#IDX9">Reporting bugs (manual)</A>
-<LI><A HREF="cvs_5.html#IDX86">Repositories, multiple</A>
-<LI><A HREF="cvs_5.html#IDX95">Repositories, remote</A>
-<LI><A HREF="cvs_5.html#IDX56">Repository (intro)</A>
-<LI><A HREF="cvs_5.html#IDX57">Repository, example</A>
-<LI><A HREF="cvs_5.html#IDX68">Repository, how data is stored</A>
-<LI><A HREF="cvs_5.html#IDX91">Repository, setting up</A>
-<LI><A HREF="cvs_7.html#IDX132">reserved checkouts</A>
-<LI><A HREF="cvs_8.html#IDX217">Resetting sticky tags</A>
-<LI><A HREF="cvs_7.html#IDX160">Resolving a conflict</A>
-<LI><A HREF="cvs_8.html#IDX221">Restoring old version of removed file</A>
-<LI><A HREF="cvs_8.html#IDX222">Resurrecting old version of dead file</A>
-<LI><A HREF="cvs_8.html#IDX205">Retrieving an old revision using tags</A>
-<LI><A HREF="cvs_7.html#IDX186">reverting to repository version</A>
-<LI><A HREF="cvs_17.html#IDX281">Revision keyword</A>
-<LI><A HREF="cvs_19.html#IDX289">Revision management</A>
-<LI><A HREF="cvs_3.html#IDX24">Revision numbers</A>
-<LI><A HREF="cvs_3.html#IDX25">Revision tree</A>
-<LI><A HREF="cvs_8.html#IDX196">Revision tree, making branches</A>
-<LI><A HREF="cvs_9.html#IDX235">Revisions, merging differences between</A>
-<LI><A HREF="cvs_3.html#IDX32">Revisions, versions and releases</A>
-<LI><A HREF="cvs_20.html#IDX319">Right-hand options</A>
-<LI><A HREF="cvs_5.html#IDX98">rsh</A>
-<LI><A HREF="cvs_20.html#IDX352">Rtag (subcommand)</A>
-<LI><A HREF="cvs_8.html#IDX212">rtag, creating a branch using</A>
-</DIR>
-<H2><A NAME="cindex_s">s</A></H2>
-<DIR>
-<LI><A HREF="cvs_20.html#IDX336">Saving space</A>
-<LI><A HREF="cvs_6.html#IDX122">SCCS, importing files from</A>
-<LI><A HREF="cvs_5.html#IDX71">Security</A>
-<LI><A HREF="cvs_5.html#IDX78">setgid</A>
-<LI><A HREF="cvs_5.html#IDX93">Setting up a repository</A>
-<LI><A HREF="cvs_5.html#IDX77">setuid</A>
-<LI><A HREF="cvs_1.html#IDX3">Signum Support</A>
-<LI><A HREF="cvs_17.html#IDX282">Source keyword</A>
-<LI><A HREF="cvs_2.html#IDX19">Source, getting CVS source</A>
-<LI><A HREF="cvs_4.html#IDX44">Source, getting from CVS</A>
-<LI><A HREF="cvs_20.html#IDX322">Specifying dates</A>
-<LI><A HREF="cvs_7.html#IDX164">Spreading information</A>
-<LI><A HREF="cvs_6.html#IDX117">Starting a project with CVS</A>
-<LI><A HREF="cvs_17.html#IDX283">State keyword</A>
-<LI><A HREF="cvs_20.html#IDX353">Status (subcommand)</A>
-<LI><A HREF="cvs_7.html#IDX136">Status of a file</A>
-<LI><A HREF="cvs_21.html#IDX367">Status of a module</A>
-<LI><A HREF="cvs_8.html#IDX220">sticky date</A>
-<LI><A HREF="cvs_8.html#IDX214">Sticky tags</A>
-<LI><A HREF="cvs_8.html#IDX218">Sticky tags, resetting</A>
-<LI><A HREF="cvs_21.html#IDX389">Storing log messages</A>
-<LI><A HREF="cvs_20.html#IDX296">Structure</A>
-<LI><A HREF="cvs_10.html#IDX242">Subdirectories</A>
-<LI><A HREF="cvs_1.html#IDX4">Support, getting CVS support</A>
-<LI><A HREF="cvs_8.html#IDX201">Symbolic name (tag)</A>
-<LI><A HREF="cvs_21.html#IDX376">Syntax of info files</A>
-</DIR>
-<H2><A NAME="cindex_t">t</A></H2>
-<DIR>
-<LI><A HREF="cvs_20.html#IDX354">Tag (subcommand)</A>
-<LI><A HREF="cvs_21.html#IDX369">Tag program</A>
-<LI><A HREF="cvs_8.html#IDX199">tag, command, introduction</A>
-<LI><A HREF="cvs_8.html#IDX204">tag, example</A>
-<LI><A HREF="cvs_8.html#IDX206">Tag, retrieving old revisions</A>
-<LI><A HREF="cvs_8.html#IDX200">Tag, symbolic name</A>
-<LI><A HREF="cvs_16.html#IDX266">taginfo</A>
-<LI><A HREF="cvs_8.html#IDX197">Tags</A>
-<LI><A HREF="cvs_8.html#IDX215">Tags, sticky</A>
-<LI><A HREF="cvs_4.html#IDX39">tc, Trivial Compiler (example)</A>
-<LI><A HREF="cvs_7.html#IDX128">Team of developers</A>
-<LI><A HREF="cvs_22.html#IDX427">TEMP</A>
-<LI><A HREF="cvs_21.html#IDX398">Template for log message</A>
-<LI><A HREF="cvs_22.html#IDX428">temporary files, location of</A>
-<LI><A HREF="cvs_13.html#IDX250">Third-party sources</A>
-<LI><A HREF="cvs_20.html#IDX321">Time</A>
-<LI><A HREF="cvs_20.html#IDX323">timezone, in input</A>
-<LI><A HREF="cvs_20.html#IDX348">timezone, in output</A>
-<LI><A HREF="cvs_22.html#IDX426">TMP</A>
-<LI><A HREF="cvs_22.html#IDX425">TMPDIR</A>
-<LI><A HREF="cvs_20.html#IDX307">TMPDIR, overriding</A>
-<LI><A HREF="cvs_20.html#IDX315">Trace</A>
-<LI><A HREF="cvs_16.html#IDX264">Traceability</A>
-<LI><A HREF="cvs_13.html#IDX251">Tracking sources</A>
-<LI><A HREF="cvs_7.html#IDX168">Transactions, atomic, lack of</A>
-<LI><A HREF="cvs_4.html#IDX40">Trivial Compiler (example)</A>
-<LI><A HREF="cvs_5.html#IDX59">Typical repository</A>
-</DIR>
-<H2><A NAME="cindex_u">u</A></H2>
-<DIR>
-<LI><A HREF="cvs_5.html#IDX76">umask, for repository files</A>
-<LI><A HREF="cvs_9.html#IDX237">Undoing a change</A>
-<LI><A HREF="cvs_7.html#IDX184">unedit (subcommand)</A>
-<LI><A HREF="cvs_7.html#IDX145">Unknown</A>
-<LI><A HREF="cvs_7.html#IDX133">unreserved checkouts</A>
-<LI><A HREF="cvs_7.html#IDX144">Unresolved Conflict</A>
-<LI><A HREF="cvs_7.html#IDX137">Up-to-date</A>
-<LI><A HREF="cvs_20.html#IDX355">Update (subcommand)</A>
-<LI><A HREF="cvs_21.html#IDX370">Update program</A>
-<LI><A HREF="cvs_7.html#IDX149">update, introduction</A>
-<LI><A HREF="cvs_7.html#IDX147">Updating a file</A>
-<LI><A HREF="cvs_22.html#IDX430">USER</A>
-<LI><A HREF="cvs_7.html#IDX180">users (admin file)</A>
-</DIR>
-<H2><A NAME="cindex_v">v</A></H2>
-<DIR>
-<LI><A HREF="cvs_13.html#IDX252">Vendor</A>
-<LI><A HREF="cvs_13.html#IDX253">Vendor branch</A>
-<LI><A HREF="cvs_3.html#IDX33">Versions, revisions and releases</A>
-<LI><A HREF="cvs_4.html#IDX54">Viewing differences</A>
-</DIR>
-<H2><A NAME="cindex_w">w</A></H2>
-<DIR>
-<LI><A HREF="cvs_7.html#IDX175">watch add (subcommand)</A>
-<LI><A HREF="cvs_7.html#IDX173">watch off (subcommand)</A>
-<LI><A HREF="cvs_7.html#IDX170">watch on (subcommand)</A>
-<LI><A HREF="cvs_7.html#IDX177">watch remove (subcommand)</A>
-<LI><A HREF="cvs_7.html#IDX188">watchers (subcommand)</A>
-<LI><A HREF="cvs_7.html#IDX169">Watches</A>
-<LI><A HREF="cvs_13.html#IDX256">Wdiff (import example)</A>
-<LI><A HREF="cvs_17.html#IDX285">What (shell command)</A>
-<LI><A HREF="cvs_8.html#IDX208">What branches are good for</A>
-<LI><A HREF="cvs_2.html#IDX12">What is CVS?</A>
-<LI><A HREF="cvs_19.html#IDX290">When to commit</A>
-<LI><A HREF="cvs_4.html#IDX38">Work-session, example of</A>
-<LI><A HREF="cvs_7.html#IDX131">Working copy</A>
-<LI><A HREF="cvs_4.html#IDX51">Working copy, removing</A>
-<LI><A HREF="cvs_21.html#IDX373">Wrappers</A>
-</DIR>
-<H2><A NAME="cindex_z">z</A></H2>
-<DIR>
-<LI><A HREF="cvs_20.html#IDX324">zone, time, in input</A>
-<LI><A HREF="cvs_20.html#IDX349">zone, time, in output</A>
-</DIR>
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_24.html">previous</A>,
next, last section, <A HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_3.html
===================================================================
RCS file: manual/html_chapter/cvs_3.html
diff -N manual/html_chapter/cvs_3.html
--- manual/html_chapter/cvs_3.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,151 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Basic concepts</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_2.html">previous</A>,
<A HREF="cvs_4.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC7" HREF="cvs_toc.html#TOC7">Basic concepts</A></H1>
-<P>
-<A NAME="IDX23"></A>
-
-</P>
-<P>
-CVS stores all files in a centralized
-<EM>repository</EM> (see section <A HREF="cvs_5.html#SEC15">The
Repository</A>).
-
-</P>
-<P>
-The repository contains directories and files, in an
-arbitrary tree. The <EM>modules</EM> feature can be used
-to group together a set of directories or files into a
-single entity (see section <A HREF="cvs_21.html#SEC137">The modules file</A>).
A typical usage is to
-define one module per project.
-
-</P>
-
-
-
-<H2><A NAME="SEC8" HREF="cvs_toc.html#TOC8">Revision numbers</A></H2>
-<P>
-<A NAME="IDX24"></A>
-<A NAME="IDX25"></A>
-<A NAME="IDX26"></A>
-<A NAME="IDX27"></A>
-<A NAME="IDX28"></A>
-<A NAME="IDX29"></A>
-<A NAME="IDX30"></A>
-<A NAME="IDX31"></A>
-
-</P>
-<P>
-Each version of a file has a unique <EM>revision
-number</EM>. Revision numbers look like <SAMP>`1.1'</SAMP>,
-<SAMP>`1.2'</SAMP>, <SAMP>`1.3.2.2'</SAMP> or even <SAMP>`1.3.2.2.4.5'</SAMP>.
-A revision number always has an even number of
-period-separated decimal integers. By default revision
-1.1 is the first revision of a file. Each successive
-revision is given a new number by increasing the
-rightmost number by one. The following figure displays
-a few revisions, with newer revisions to the right.
-
-</P>
-
-<PRE>
- +-----+ +-----+ +-----+ +-----+ +-----+
- ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
- +-----+ +-----+ +-----+ +-----+ +-----+
-</PRE>
-
-<P>
-CVS is not limited to linear development. The
-<EM>revision tree</EM> can be split into <EM>branches</EM>,
-where each branch is a self-maintained line of
-development. Changes made on one branch can easily be
-moved back to the main trunk.
-
-</P>
-<P>
-Each branch has a <EM>branch number</EM>, consisting of an
-odd number of period-separated decimal integers. The
-branch number is created by appending an integer to the
-revision number where the corresponding branch forked
-off. Having branch numbers allows more than one branch
-to be forked off from a certain revision.
-
-</P>
-<P>
-All revisions on a branch have revision numbers formed
-by appending an ordinal number to the branch number.
-The following figure illustrates branching with an
-example.
-
-</P>
-
-<PRE>
- +-------------+
- Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 !
- / +-------------+
- /
- /
- +---------+ +---------+ +---------+ +---------+
-Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !----! 1.2.2.4 !
- / +---------+ +---------+ +---------+ +---------+
- /
- /
-+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+ +-----+
- !
- !
- ! +---------+ +---------+ +---------+
-Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
- +---------+ +---------+ +---------+
-
-</PRE>
-
-<P>
-The exact details of how the branch number is
-constructed is not something you normally need to be
-concerned about, but here is how it works: When
-CVS creates a branch number it picks the first
-unused even integer, starting with 2. So when you want
-to create a branch from revision 6.4 it will be
-numbered 6.4.2. All branch numbers ending in a zero
-(such as 6.4.0) are used internally by CVS
-(see section <A HREF="cvs_23.html#SEC153">Magic branch numbers</A>). The
branch 1.1.1 has a
-special meaning. See section <A HREF="cvs_13.html#SEC63">Tracking third-party
sources</A>.
-
-</P>
-
-
-<H2><A NAME="SEC9" HREF="cvs_toc.html#TOC9">Versions, revisions and
releases</A></H2>
-<P>
-<A NAME="IDX32"></A>
-<A NAME="IDX33"></A>
-<A NAME="IDX34"></A>
-
-</P>
-<P>
-A file can have several versions, as described above.
-Likewise, a software product can have several versions.
-A software product is often given a version number such
-as <SAMP>`4.1.1'</SAMP>.
-
-</P>
-<P>
-Versions in the first sense are called <EM>revisions</EM>
-in this document, and versions in the second sense are
-called <EM>releases</EM>. To avoid confusion, the word
-<EM>version</EM> is almost never used in this document.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_2.html">previous</A>,
<A HREF="cvs_4.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_4.html
===================================================================
RCS file: manual/html_chapter/cvs_4.html
diff -N manual/html_chapter/cvs_4.html
--- manual/html_chapter/cvs_4.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,246 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - A sample session</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_3.html">previous</A>,
<A HREF="cvs_5.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC10" HREF="cvs_toc.html#TOC10">A sample session</A></H1>
-<P>
-<A NAME="IDX35"></A>
-<A NAME="IDX36"></A>
-<A NAME="IDX37"></A>
-<A NAME="IDX38"></A>
-<A NAME="IDX39"></A>
-<A NAME="IDX40"></A>
-
-</P>
-<P>
-This section describes a typical work-session using
-CVS. It assumes that a repository is set up
-(see section <A HREF="cvs_5.html#SEC15">The Repository</A>).
-
-</P>
-<P>
-Suppose you are working on a simple compiler. The source
-consists of a handful of C files and a <TT>`Makefile'</TT>.
-The compiler is called <SAMP>`tc'</SAMP> (Trivial Compiler),
-and the repository is set up so that there is a module
-called <SAMP>`tc'</SAMP>.
-
-</P>
-
-
-
-<H2><A NAME="SEC11" HREF="cvs_toc.html#TOC11">Getting the source</A></H2>
-<P>
-<A NAME="IDX41"></A>
-<A NAME="IDX42"></A>
-<A NAME="IDX43"></A>
-<A NAME="IDX44"></A>
-<A NAME="IDX45"></A>
-
-</P>
-<P>
-The first thing you must do is to get your own working copy of the
-source for <SAMP>`tc'</SAMP>. For this, you use the <CODE>checkout</CODE>
command:
-
-</P>
-
-<PRE>
-$ cvs checkout tc
-</PRE>
-
-<P>
-This will create a new directory called <TT>`tc'</TT> and populate it with
-the source files.
-
-</P>
-
-<PRE>
-$ cd tc
-$ ls
-CVS Makefile backend.c driver.c frontend.c parser.c
-</PRE>
-
-<P>
-The <TT>`CVS'</TT> directory is used internally by
-CVS. Normally, you should not modify or remove
-any of the files in it.
-
-</P>
-<P>
-You start your favorite editor, hack away at <TT>`backend.c'</TT>, and a couple
-of hours later you have added an optimization pass to the compiler.
-A note to RCS and SCCS users: There is no need to lock the files that
-you want to edit. See section <A HREF="cvs_7.html#SEC37">Multiple
developers</A> for an explanation.
-
-</P>
-
-
-<H2><A NAME="SEC12" HREF="cvs_toc.html#TOC12">Committing your changes</A></H2>
-<P>
-<A NAME="IDX46"></A>
-<A NAME="IDX47"></A>
-<A NAME="IDX48"></A>
-<A NAME="IDX49"></A>
-
-</P>
-<P>
-When you have checked that the compiler is still compilable you decide
-to make a new version of <TT>`backend.c'</TT>.
-
-</P>
-
-<PRE>
-$ cvs commit backend.c
-</PRE>
-
-<P>
-CVS starts an editor, to allow you to enter a log
-message. You type in "Added an optimization pass.",
-save the temporary file, and exit the editor.
-
-</P>
-<P>
-The environment variable <CODE>$CVSEDITOR</CODE> determines
-which editor is started. If <CODE>$CVSEDITOR</CODE> is not
-set, then if the environment variable <CODE>$EDITOR</CODE> is
-set, it will be used. If both <CODE>$CVSEDITOR</CODE> and
-<CODE>$EDITOR</CODE> are not set then the editor defaults to
-<CODE>vi</CODE>. If you want to avoid the overhead of
-starting an editor you can specify the log message on
-the command line using the <SAMP>`-m'</SAMP> flag instead, like
-this:
-
-</P>
-
-<PRE>
-$ cvs commit -m "Added an optimization pass" backend.c
-</PRE>
-
-
-
-<H2><A NAME="SEC13" HREF="cvs_toc.html#TOC13">Cleaning up</A></H2>
-<P>
-<A NAME="IDX50"></A>
-<A NAME="IDX51"></A>
-<A NAME="IDX52"></A>
-<A NAME="IDX53"></A>
-
-</P>
-<P>
-Before you turn to other tasks you decide to remove your working copy of
-tc. One acceptable way to do that is of course
-
-</P>
-
-<PRE>
-$ cd ..
-$ rm -r tc
-</PRE>
-
-<P>
-but a better way is to use the <CODE>release</CODE> command (see section <A
HREF="cvs_20.html#SEC122">release--Indicate that a Module is no longer in
use</A>):
-
-</P>
-
-<PRE>
-$ cd ..
-$ cvs release -d tc
-M driver.c
-? tc
-You have [1] altered files in this repository.
-Are you sure you want to release (and delete) module `tc': n
-** `release' aborted by user choice.
-</PRE>
-
-<P>
-The <CODE>release</CODE> command checks that all your modifications have been
-committed. If history logging is enabled it also makes a note in the
-history file. See section <A HREF="cvs_21.html#SEC149">The history file</A>.
-
-</P>
-<P>
-When you use the <SAMP>`-d'</SAMP> flag with <CODE>release</CODE>, it
-also removes your working copy.
-
-</P>
-<P>
-In the example above, the <CODE>release</CODE> command wrote a couple of lines
-of output. <SAMP>`? tc'</SAMP> means that the file <TT>`tc'</TT> is unknown
to CVS.
-That is nothing to worry about: <TT>`tc'</TT> is the executable compiler,
-and it should not be stored in the repository. See section <A
HREF="cvs_21.html#SEC148">Ignoring files via cvsignore</A>,
-for information about how to make that warning go away.
-See section <A HREF="cvs_20.html#SEC124">release output</A>, for a complete
explanation of
-all possible output from <CODE>release</CODE>.
-
-</P>
-<P>
-<SAMP>`M driver.c'</SAMP> is more serious. It means that the
-file <TT>`driver.c'</TT> has been modified since it was
-checked out.
-
-</P>
-<P>
-The <CODE>release</CODE> command always finishes by telling
-you how many modified files you have in your working
-copy of the sources, and then asks you for confirmation
-before deleting any files or making any note in the
-history file.
-
-</P>
-<P>
-You decide to play it safe and answer <KBD>n <KBD>RET</KBD></KBD>
-when <CODE>release</CODE> asks for confirmation.
-
-</P>
-
-
-<H2><A NAME="SEC14" HREF="cvs_toc.html#TOC14">Viewing differences</A></H2>
-<P>
-<A NAME="IDX54"></A>
-<A NAME="IDX55"></A>
-
-</P>
-<P>
-You do not remember modifying <TT>`driver.c'</TT>, so you want to see what
-has happened to that file.
-
-</P>
-
-<PRE>
-$ cd tc
-$ cvs diff driver.c
-</PRE>
-
-<P>
-This command runs <CODE>diff</CODE> to compare the version of
<TT>`driver.c'</TT>
-that you checked out with your working copy. When you see the output
-you remember that you added a command line option that enabled the
-optimization pass. You check it in, and release the module.
-
-</P>
-
-<PRE>
-$ cvs commit -m "Added an optimization pass" driver.c
-Checking in driver.c;
-/usr/local/cvsroot/tc/driver.c,v <-- driver.c
-new revision: 1.2; previous revision: 1.1
-done
-$ cd ..
-$ cvs release -d tc
-? tc
-You have [0] altered files in this repository.
-Are you sure you want to release (and delete) module `tc': y
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_3.html">previous</A>,
<A HREF="cvs_5.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_5.html
===================================================================
RCS file: manual/html_chapter/cvs_5.html
diff -N manual/html_chapter/cvs_5.html
--- manual/html_chapter/cvs_5.html 7 Feb 2007 02:36:35 -0000 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,929 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - The Repository</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_4.html">previous</A>,
<A HREF="cvs_6.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC15" HREF="cvs_toc.html#TOC15">The Repository</A></H1>
-<P>
-<A NAME="IDX56"></A>
-<A NAME="IDX57"></A>
-<A NAME="IDX58"></A>
-<A NAME="IDX59"></A>
-<A NAME="IDX60"></A>
-<A NAME="IDX61"></A>
-
-</P>
-<P>
-The CVS <EM>repository</EM> stores a complete copy of
-all the files and directories which are under version
-control.
-
-</P>
-<P>
-Normally, you never access any of the files in the
-repository directly. Instead, you use CVS
-commands to get your own copy of the files, and then
-work on that copy. When you've finished a set of
-changes, you check (or <EM>commit</EM>) them back into the
-repository. The repository then contains the changes
-which you have made, as well as recording exactly what
-you changed, when you changed it, and other such
-information.
-
-</P>
-<P>
-<A NAME="IDX62"></A>
-CVS can access a repository by a variety of
-means. It might be on the local computer, or it might
-be on a computer across the room or across the world.
-To distinguish various ways to access a repository, the
-repository name can start with an <EM>access method</EM>.
-For example, the access method <CODE>:local:</CODE> means to
-access a repository directory, so the repository
-<CODE>:local:/usr/local/cvsroot</CODE> means that the
-repository is in <TT>`/usr/local/cvsroot'</TT> on the
-computer running CVS. For information on other
-access methods, see section <A HREF="cvs_5.html#SEC24">Remote repositories</A>.
-
-</P>
-<P>
-If the access method is omitted, then if the repository
-does not contain <SAMP>`:'</SAMP>, then <CODE>:local:</CODE> is
-assumed. If it does contain <SAMP>`:'</SAMP> than either
-<CODE>:ext:</CODE> or <CODE>:server:</CODE> is assumed. For
-example, if you have a local repository in
-<TT>`/usr/local/cvsroot'</TT>, you can use
-<CODE>/usr/local/cvsroot</CODE> instead of
-<CODE>:local:/usr/local/cvsroot</CODE>. But if (under
-Windows NT, for example) your local repository is
-<TT>`c:\src\cvsroot'</TT>, then you must specify the access
-method, as in <CODE>:local:c:\src\cvsroot</CODE>.
-
-</P>
-<P>
-The repository is split in two parts. <TT>`$CVSROOT/CVSROOT'</TT> contains
-administrative files for CVS. The other directories contain the actual
-user-defined modules.
-
-</P>
-
-
-
-<H2><A NAME="SEC16" HREF="cvs_toc.html#TOC16">Telling CVS where your
repository is</A></H2>
-
-<P>
-There are a couple of different ways to tell CVS
-where to find the repository. You can name the
-repository on the command line explicitly, with the
-<CODE>-d</CODE> (for "directory") option:
-
-</P>
-
-<PRE>
-cvs -d /usr/local/cvsroot checkout yoyodyne/tc
-</PRE>
-
-<P>
-<A NAME="IDX63"></A>
-<A NAME="IDX64"></A>
-<A NAME="IDX65"></A>
-<A NAME="IDX66"></A>
-<A NAME="IDX67"></A>
- Or you can set the <CODE>$CVSROOT</CODE> environment
-variable to an absolute path to the root of the
-repository, <TT>`/usr/local/cvsroot'</TT> in this example.
-To set <CODE>$CVSROOT</CODE>, all <CODE>csh</CODE> and <CODE>tcsh</CODE>
-users should have this line in their <TT>`.cshrc'</TT> or
-<TT>`.tcshrc'</TT> files:
-
-</P>
-
-<PRE>
-setenv CVSROOT /usr/local/cvsroot
-</PRE>
-
-<P>
-<CODE>sh</CODE> and <CODE>bash</CODE> users should instead have these lines in
their
-<TT>`.profile'</TT> or <TT>`.bashrc'</TT>:
-
-</P>
-
-<PRE>
-CVSROOT=/usr/local/cvsroot
-export CVSROOT
-</PRE>
-
-<P>
- A repository specified with <CODE>-d</CODE> will
-override the <CODE>$CVSROOT</CODE> environment variable.
-Once you've checked a working copy out from the
-repository, it will remember where its repository is
-(the information is recorded in the
-<TT>`CVS/Root'</TT> file in the working copy).
-
-</P>
-<P>
-The <CODE>-d</CODE> option and the <TT>`CVS/Root'</TT> file both
-override the <CODE>$CVSROOT</CODE> environment variable. If
-<CODE>-d</CODE> option differs from <TT>`CVS/Root'</TT>, the
-former is used (and specifying <CODE>-d</CODE> will cause
-<TT>`CVS/Root'</TT> to be updated). Of course, for proper
-operation they should be two ways of referring to the
-same repository.
-
-</P>
-
-
-<H2><A NAME="SEC17" HREF="cvs_toc.html#TOC17">How data is stored in the
repository</A></H2>
-<P>
-<A NAME="IDX68"></A>
-
-</P>
-<P>
-For most purposes it isn't important <EM>how</EM>
-CVS stores information in the repository. In
-fact, the format has changed in the past, and is likely
-to change in the future. Since in almost all cases one
-accesses the repository via CVS commands; such
-changes need not be disruptive.
-
-</P>
-<P>
-However, in some cases it may be necessary to
-understand how CVS stores data in the repository,
-for example you might need to track down CVS locks
-(see section <A HREF="cvs_7.html#SEC42">Several developers simultaneously
attempting to run CVS</A>) or you might need to deal with
-the file permissions appropriate for the repository.
-
-</P>
-
-
-
-<H3><A NAME="SEC18" HREF="cvs_toc.html#TOC18">Where files are stored within
the repository</A></H3>
-
-<P>
-The overall structure of the repository is a directory
-tree corresponding to the directories in the working
-directory. For example, supposing the repository is in
-<TT>`/usr/local/cvsroot'</TT>, here is a possible directory
-tree (showing only the directories):
-
-</P>
-
-<PRE>
-<TT>/usr</TT>
- |
- +--<TT>local</TT>
- | |
- | +--<TT>cvsroot</TT>
- | | |
- | | +--<TT>CVSROOT</TT>
- | (administrative files)
- |
- +--<TT>gnu</TT>
- | |
- | +--<TT>diff</TT>
- | | (source code to GNU diff)
- | |
- | +--<TT>rcs</TT>
- | | (source code to RCS)
- | |
- | +--<TT>cvs</TT>
- | (source code to CVS)
- |
- +--<TT>yoyodyne</TT>
- |
- +--<TT>tc</TT>
- | |
- | +--<TT>man</TT>
- | |
- | +--<TT>testing</TT>
- |
- +--(other Yoyodyne software)
-</PRE>
-
-<P>
-With the directories are <EM>history files</EM> for each file
-under version control. The name of the history file is
-the name of the corresponding file with <SAMP>`,v'</SAMP>
-appended to the end. Here is what the repository for
-the <TT>`yoyodyne/tc'</TT> directory might look like:
-
-</P>
-
-<PRE>
- <CODE>$CVSROOT</CODE>
- |
- +--<TT>yoyodyne</TT>
- | |
- | +--<TT>tc</TT>
- | | |
- +--<TT>Makefile,v</TT>
- +--<TT>backend.c,v</TT>
- +--<TT>driver.c,v</TT>
- +--<TT>frontend.c,v</TT>
- +--<TT>parser.c,v</TT>
- +--<TT>man</TT>
- | |
- | +--<TT>tc.1,v</TT>
- |
- +--<TT>testing</TT>
- |
- +--<TT>testpgm.t,v</TT>
- +--<TT>test2.t,v</TT>
-</PRE>
-
-<P>
-<A NAME="IDX69"></A>
-<A NAME="IDX70"></A>
-The history files contain, among other things, enough
-information to recreate any revision of the file, a log
-of all commit messages and the user-name of the person
-who committed the revision. The history files are
-known as <EM>RCS files</EM>, because the first program to
-store files in that format was a version control system
-known as RCS. For a full
-description of the file format, see the <CODE>man</CODE> page
-<CITE>rcsfile(5)</CITE>, distributed with RCS. This
-file format has become very common--many systems other
-than CVS or RCS can at least import history
-files in this format.
-
-</P>
-
-
-<H3><A NAME="SEC19" HREF="cvs_toc.html#TOC19">File permissions</A></H3>
-<P>
-<A NAME="IDX71"></A>
-<A NAME="IDX72"></A>
-<A NAME="IDX73"></A>
-<A NAME="IDX74"></A>
-All <SAMP>`,v'</SAMP> files are created read-only, and you
-should not change the permission of those files. The
-directories inside the repository should be writable by
-the persons that have permission to modify the files in
-each directory. This normally means that you must
-create a Unix group (see group(5)) consisting of the
-persons that are to edit the files in a project, and
-set up the repository so that it is that group that
-owns the directory.
-
-</P>
-<P>
-This means that you can only control access to files on
-a per-directory basis.
-
-</P>
-<P>
-Note that users must also have write access to check
-out files, because CVS needs to create lock files
-(see section <A HREF="cvs_7.html#SEC42">Several developers simultaneously
attempting to run CVS</A>).
-
-</P>
-<P>
-Also note that users must have write access to the
-<TT>`CVSROOT/val-tags'</TT> file. CVS uses it to keep
-track of what tags are valid tag names (it is sometimes
-updated when tags are used, as well as when they are
-created, though).
-
-</P>
-<P>
-<A NAME="IDX75"></A>
-<A NAME="IDX76"></A>
-CVS tries to set up reasonable file permissions
-for new directories that are added inside the tree, but
-you must fix the permissions manually when a new
-directory should have different permissions than its
-parent directory. If you set the <CODE>CVSUMASK</CODE>
-environment variable that will control the file
-permissions which CVS uses in creating directories
-and/or files in the repository. <CODE>CVSUMASK</CODE> does
-not affect the file permissions in the working
-directory; such files have the permissions which are
-typical for newly created files, except that sometimes
-CVS creates them read-only (see the sections on
-watches, section <A HREF="cvs_7.html#SEC44">Telling CVS to watch certain
files</A>; -r, section <A HREF="cvs_20.html#SEC89">Global options</A>; or
CVSREAD, section <A HREF="cvs_22.html#SEC151">All environment variables which
affect CVS</A>).
-
-</P>
-<P>
-<A NAME="IDX77"></A>
-<A NAME="IDX78"></A>
-Since CVS was not written to be run setuid, it is
-unsafe to try to run it setuid. You cannot use the
-setuid features of RCS together with CVS.
-
-</P>
-
-
-<H2><A NAME="SEC20" HREF="cvs_toc.html#TOC20">The administrative files</A></H2>
-<P>
-<A NAME="IDX79"></A>
-<A NAME="IDX80"></A>
-<A NAME="IDX81"></A>
-<A NAME="IDX82"></A>
-
-</P>
-
-<P>
-The directory <TT>`$CVSROOT/CVSROOT'</TT> contains some <EM>administrative
-files</EM>. See section <A HREF="cvs_21.html#SEC136">Reference manual for the
Administrative files</A>, for a complete description.
-You can use CVS without any of these files, but
-some commands work better when at least the
-<TT>`modules'</TT> file is properly set up.
-
-</P>
-<P>
-The most important of these files is the <TT>`modules'</TT>
-file. It defines all modules in the repository. This
-is a sample <TT>`modules'</TT> file.
-
-</P>
-
-<PRE>
-CVSROOT CVSROOT
-modules CVSROOT modules
-cvs gnu/cvs
-rcs gnu/rcs
-diff gnu/diff
-tc yoyodyne/tc
-</PRE>
-
-<P>
-The <TT>`modules'</TT> file is line oriented. In its
-simplest form each line contains the name of the
-module, whitespace, and the directory where the module
-resides. The directory is a path relative to
-<CODE>$CVSROOT</CODE>. The last four lines in the example
-above are examples of such lines.
-
-</P>
-
-<P>
-The line that defines the module called <SAMP>`modules'</SAMP>
-uses features that are not explained here.
-See section <A HREF="cvs_21.html#SEC137">The modules file</A>, for a full
explanation of all the
-available features.
-
-</P>
-
-
-<H3><A NAME="SEC21" HREF="cvs_toc.html#TOC21">Editing administrative
files</A></H3>
-<P>
-<A NAME="IDX83"></A>
-<A NAME="IDX84"></A>
-
-</P>
-<P>
-You edit the administrative files in the same way that you would edit
-any other module. Use <SAMP>`cvs checkout CVSROOT'</SAMP> to get a working
-copy, edit it, and commit your changes in the normal way.
-
-</P>
-<P>
-It is possible to commit an erroneous administrative
-file. You can often fix the error and check in a new
-revision, but sometimes a particularly bad error in the
-administrative file makes it impossible to commit new
-revisions.
-
-</P>
-
-
-<H2><A NAME="SEC22" HREF="cvs_toc.html#TOC22">Multiple repositories</A></H2>
-<P>
-<A NAME="IDX85"></A>
-<A NAME="IDX86"></A>
-<A NAME="IDX87"></A>
-<A NAME="IDX88"></A>
-<A NAME="IDX89"></A>
-<A NAME="IDX90"></A>
-
-</P>
-<P>
-In some situations it is a good idea to have more than
-one repository, for instance if you have two
-development groups that work on separate projects
-without sharing any code. All you have to do to have
-several repositories is to specify the appropriate
-repository, using the <CODE>CVSROOT</CODE> environment
-variable, the <SAMP>`-d'</SAMP> option to CVS, or (once
-you have checked out a working directory) by simply
-allowing CVS to use the repository that was used
-to check out the working directory
-(see section <A HREF="cvs_5.html#SEC16">Telling CVS where your repository
is</A>).
-
-</P>
-<P>
-The big advantage of having multiple repositories is
-that they can reside on different servers. The big
-disadvantage is that you cannot have a single CVS
-command recurse into directories which comes from
-different repositories. Generally speaking, if you are
-thinking of setting up several repositories on the same
-machine, you might want to consider using several
-directories within the same repository.
-
-</P>
-<P>
-None of the examples in this manual show multiple
-repositories.
-
-</P>
-
-
-<H2><A NAME="SEC23" HREF="cvs_toc.html#TOC23">Creating a repository</A></H2>
-
-<P>
-<A NAME="IDX91"></A>
-<A NAME="IDX92"></A>
-<A NAME="IDX93"></A>
-
-</P>
-<P>
-To set up a CVS repository, choose a directory
-with ample disk space available for the revision
-history of the source files. It should be accessable
-(directly or via a networked file system) from all
-machines which want to use CVS in server or local
-mode; the client machines need not have any access to
-it other than via the CVS protocol. It is not
-possible to use CVS to read from a repository
-which one only has read access to; CVS needs to be
-able to create lock files (see section <A HREF="cvs_7.html#SEC42">Several
developers simultaneously attempting to run CVS</A>).
-
-</P>
-<P>
-<A NAME="IDX94"></A>
-To create a repository, run the <CODE>cvs init</CODE>
-command. It will set up an empty repository in the
-CVS root specified in the usual way
-(see section <A HREF="cvs_5.html#SEC15">The Repository</A>). For example,
-
-</P>
-
-<PRE>
-cvs -d /usr/local/cvsroot init
-</PRE>
-
-<P>
-<CODE>cvs init</CODE> is careful to never overwrite any
-existing files in the repository, so no harm is done if
-you run <CODE>cvs init</CODE> on an already set-up
-repository.
-
-</P>
-<P>
-<CODE>cvs init</CODE> will enable history logging; if you
-don't want that, remove the history file after running
-<CODE>cvs init</CODE>. See section <A HREF="cvs_21.html#SEC149">The history
file</A>.
-
-</P>
-
-
-<H2><A NAME="SEC24" HREF="cvs_toc.html#TOC24">Remote repositories</A></H2>
-<P>
-<A NAME="IDX95"></A>
-<A NAME="IDX96"></A>
-<A NAME="IDX97"></A>
-
-</P>
-<P>
- Your working copy of the sources can be on a
-different machine than the repository. Generally,
-using a remote repository is just like using a local
-one, except that the format of the repository name is:
-
-</P>
-
-<PRE>
-:<VAR>method</VAR>:<VAR>user</VAR>@<VAR>hostname</VAR>:/path/to/repository
-</PRE>
-
-<P>
-The details of exactly what needs to be set up depend
-on how you are connecting to the server.
-
-</P>
-<P>
-If <VAR>method</VAR> is not specified, and the repository
-name contains <SAMP>`:'</SAMP>, then the default is <CODE>ext</CODE>
-or <CODE>server</CODE>, depending on your platform; both are
-described in section <A HREF="cvs_5.html#SEC25">Connecting with rsh</A>.
-
-</P>
-
-
-
-<H3><A NAME="SEC25" HREF="cvs_toc.html#TOC25">Connecting with rsh</A></H3>
-
-<P>
-<A NAME="IDX98"></A>
-CVS uses the <TT>`rsh'</TT> protocol to perform these
-operations, so the remote user host needs to have a
-<TT>`.rhosts'</TT> file which grants access to the local
-user.
-
-</P>
-<P>
-For example, suppose you are the user <TT>`mozart'</TT> on
-the local machine <TT>`anklet.grunge.com'</TT>, and the
-server machine is <TT>`chainsaw.brickyard.com'</TT>. On
-chainsaw, put the following line into the file
-<TT>`.rhosts'</TT> in <TT>`bach'</TT>'s home directory:
-
-</P>
-
-<PRE>
-anklet.grunge.com mozart
-</PRE>
-
-<P>
-Then test that <CODE>rsh</CODE> is working with
-
-</P>
-
-<PRE>
-rsh -l bach chainsaw.brickyard.com 'echo $PATH'
-</PRE>
-
-<P>
-<A NAME="IDX99"></A>
-Next you have to make sure that <CODE>rsh</CODE> will be able
-to find the server. Make sure that the path which
-<CODE>rsh</CODE> printed in the above example includes the
-directory containing a program named <CODE>cvs</CODE> which
-is the server. You need to set the path in
-<TT>`.bashrc'</TT>, <TT>`.cshrc'</TT>, etc., not <TT>`.login'</TT>
-or <TT>`.profile'</TT>. Alternately, you can set the
-environment variable <CODE>CVS_SERVER</CODE> on the client
-machine to the filename of the server you want to use,
-for example <TT>`/usr/local/bin/cvs-1.6'</TT>.
-
-</P>
-<P>
-There is no need to edit <CODE>inetd.conf</CODE> or start a
-CVS server daemon.
-
-</P>
-<P>
-<A NAME="IDX100"></A>
-<A NAME="IDX101"></A>
-There are two access methods that you use in CVSROOT
-for rsh. <CODE>:server:</CODE> specifies an internal rsh
-client, which is supported only by some CVS ports.
-<CODE>:ext:</CODE> specifies an external rsh program. By
-default this is <CODE>rsh</CODE> but you may set the
-<CODE>CVS_RSH</CODE> environment variable to invoke another
-program which can access the remote server (for
-example, <CODE>remsh</CODE> on HP-UX 9 because <CODE>rsh</CODE> is
-something different). It must be a program which can
-transmit data to and from the server without modifying
-it; for example the Windows NT <CODE>rsh</CODE> is not
-suitable since it by default translates between CRLF
-and LF. The OS/2 CVS port has a hack to pass <SAMP>`-b'</SAMP>
-to <CODE>rsh</CODE> to get around this, but since this could
-potentially cause programs for programs other than the
-standard <CODE>rsh</CODE>, it may change in the future. If
-you set <CODE>CVS_RSH</CODE> to <CODE>SSH</CODE> or some other rsh
-replacement, the instructions in the rest of this
-section concerning <TT>`.rhosts'</TT> and so on are likely
-to be incorrect; consult the documentation for your rsh
-replacement.
-
-</P>
-<P>
-Continuing our example, supposing you want to access
-the module <TT>`foo'</TT> in the repository
-<TT>`/usr/local/cvsroot/'</TT>, on machine
-<TT>`chainsaw.brickyard.com'</TT>, you are ready to go:
-
-</P>
-
-<PRE>
-cvs -d :ext:address@hidden:/usr/local/cvsroot checkout foo
-</PRE>
-
-<P>
-(The <TT>`bach@'</TT> can be omitted if the username is
-the same on both the local and remote hosts.)
-
-</P>
-
-
-
-<H3><A NAME="SEC26" HREF="cvs_toc.html#TOC26">Direct connection with password
authentication</A></H3>
-
-<P>
-The CVS client can also connect to the server
-using a password protocol. This is particularly useful
-if using <CODE>rsh</CODE> is not feasible (for example,
-the server is behind a firewall), and Kerberos also is
-not available.
-
-</P>
-<P>
- To use this method, it is necessary to make
-some adjustments on both the server and client sides.
-
-</P>
-
-
-
-<H4><A NAME="SEC27" HREF="cvs_toc.html#TOC27">Setting up the server for
password authentication</A></H4>
-
-<P>
-<A NAME="IDX102"></A>
-<A NAME="IDX103"></A>
-<A NAME="IDX104"></A>
-On the server side, the file <TT>`/etc/inetd.conf'</TT>
-needs to be edited so <CODE>inetd</CODE> knows to run the
-command <CODE>cvs pserver</CODE> when it receives a
-connection on the right port. By default, the port
-number is 2401; it would be different if your client
-were compiled with <CODE>CVS_AUTH_PORT</CODE> defined to
-something else, though.
-
-</P>
-<P>
- If your <CODE>inetd</CODE> allows raw port numbers in
-<TT>`/etc/inetd.conf'</TT>, then the following (all on a
-single line in <TT>`inetd.conf'</TT>) should be sufficient:
-
-</P>
-
-<PRE>
-2401 stream tcp nowait root /usr/local/bin/cvs
-cvs -b /usr/local/bin pserver
-</PRE>
-
-<P>
-The <SAMP>`-b'</SAMP> option specifies the directory which contains
-the RCS binaries on the server. You could also use the
-<SAMP>`-T'</SAMP> option to specify a temporary directory.
-
-</P>
-<P>
- If your <CODE>inetd</CODE> wants a symbolic service
-name instead of a raw port number, then put this in
-<TT>`/etc/services'</TT>:
-
-</P>
-
-<PRE>
-cvspserver 2401/tcp
-</PRE>
-
-<P>
- and put <CODE>cvspserver</CODE> instead of
-<CODE>2401</CODE> in <TT>`inetd.conf'</TT>.
-
-</P>
-<P>
- Once the above is taken care of, restart your
-<CODE>inetd</CODE>, or do whatever is necessary to force it
-to reread its initialization files.
-
-</P>
-
-<P>
-<A NAME="IDX105"></A>
-<A NAME="IDX106"></A>
-Because the client stores and transmits passwords in
-cleartext (almost--see section <A HREF="cvs_5.html#SEC29">Security
considerations with password authentication</A> for details), a separate CVS
password
-file may be used, so people don't compromise their
-regular passwords when they access the repository.
-This file is <TT>`$CVSROOT/CVSROOT/passwd'</TT>
-(see section <A HREF="cvs_5.html#SEC20">The administrative files</A>). Its
format is
-similar to <TT>`/etc/passwd'</TT>, except that it only has
-two fields, username and password. For example:
-
-</P>
-
-<PRE>
-bach:ULtgRLXo7NRxs
-cwang:1sOp854gDF3DY
-</PRE>
-
-<P>
-The password is encrypted according to the standard
-Unix <CODE>crypt()</CODE> function, so it is possible to
-paste in passwords directly from regular Unix
-<TT>`passwd'</TT> files.
-
-</P>
-<P>
-When authenticating a password, the server first checks
-for the user in the CVS <TT>`passwd'</TT> file. If it
-finds the user, it compares against that password. If
-it does not find the user, or if the CVS
-<TT>`passwd'</TT> file does not exist, then the server
-tries to match the password using the system's
-user-lookup routine. When using the CVS
-<TT>`passwd'</TT> file, the server runs under as the
-username specified in the the third argument in the
-entry, or as the first argument if there is no third
-argument (in this way CVS allows imaginary
-usernames provided the CVS <TT>`passwd'</TT> file
-indicates corresponding valid system usernames). In
-any case, CVS will have no privileges which the
-(valid) user would not have.
-
-</P>
-<P>
-Right now, the only way to put a password in the
-CVS <TT>`passwd'</TT> file is to paste it there from
-somewhere else. Someday, there may be a <CODE>cvs
-passwd</CODE> command.
-
-</P>
-
-
-<H4><A NAME="SEC28" HREF="cvs_toc.html#TOC28">Using the client with password
authentication</A></H4>
-<P>
-<A NAME="IDX107"></A>
-<A NAME="IDX108"></A>
-<A NAME="IDX109"></A>
-<A NAME="IDX110"></A>
-Before connecting to the server, the client must <EM>log
-in</EM> with the command <CODE>cvs login</CODE>. Logging in
-verifies a password with the server, and also records
-the password for later transactions with the server.
-The <CODE>cvs login</CODE> command needs to know the
-username, server hostname, and full repository path,
-and it gets this information from the repository
-argument or the <CODE>CVSROOT</CODE> environment variable.
-
-</P>
-<P>
-<CODE>cvs login</CODE> is interactive -- it prompts for a
-password:
-
-</P>
-
-<PRE>
-cvs -d :pserver:address@hidden:/usr/local/cvsroot login
-CVS password:
-</PRE>
-
-<P>
-The password is checked with the server; if it is
-correct, the <CODE>login</CODE> succeeds, else it fails,
-complaining that the password was incorrect.
-
-</P>
-<P>
-Once you have logged in, you can force CVS to
-connect directly to the server and authenticate with
-the stored password:
-
-</P>
-
-<PRE>
-cvs -d :pserver:address@hidden:/usr/local/cvsroot checkout foo
-</PRE>
-
-<P>
-The <SAMP>`:pserver:'</SAMP> is necessary because without it,
-CVS will assume it should use <CODE>rsh</CODE> to
-connect with the server (see section <A HREF="cvs_5.html#SEC25">Connecting
with rsh</A>).
-(Once you have a working copy checked out and are
-running CVS commands from within it, there is no
-longer any need to specify the repository explicitly,
-because CVS records it in the working copy's
-<TT>`CVS'</TT> subdirectory.)
-
-</P>
-<P>
-<A NAME="IDX111"></A>
-Passwords are stored by default in the file
-<TT>`$HOME/.cvspass'</TT>. Its format is human-readable,
-but don't edit it unless you know what you are doing.
-The passwords are not stored in cleartext, but are
-trivially encoded to protect them from "innocent"
-compromise (i.e., inadvertently being seen by a system
-administrator who happens to look at that file).
-
-</P>
-<P>
-The <CODE>CVS_PASSFILE</CODE> environment variable overrides
-this default. If you use this variable, make sure you
-set it <EM>before</EM> <CODE>cvs login</CODE> is run. If you
-were to set it after running <CODE>cvs login</CODE>, then
-later CVS commands would be unable to look up the
-password for transmission to the server.
-
-</P>
-<P>
-<A NAME="IDX112"></A>
-The <CODE>CVS_PASSWORD</CODE> environment variable overrides
-<EM>all</EM> stored passwords. If it is set, CVS
-will use it for all password-authenticated
-connections.
-
-</P>
-
-
-<H4><A NAME="SEC29" HREF="cvs_toc.html#TOC29">Security considerations with
password authentication</A></H4>
-
-<P>
-The passwords are stored on the client side in a
-trivial encoding of the cleartext, and transmitted in
-the same encoding. The encoding is done only to
-prevent inadvertent password compromises (i.e., a
-system administrator accidentally looking at the file),
-and will not prevent even a naive attacker from gaining
-the password.
-
-</P>
-<P>
-The separate CVS password file (see section <A HREF="cvs_5.html#SEC27">Setting
up the server for password authentication</A>) allows people
-to use a different password for repository access than
-for login access. On the other hand, once a user has
-access to the repository, she can execute programs on
-the server system through a variety of means. Thus, repository
-access implies fairly broad system access as well. It
-might be possible to modify CVS to prevent that,
-but no one has done so as of this writing.
-Furthermore, there may be other ways in which having
-access to CVS allows people to gain more general
-access to the system; noone has done a careful audit.
-
-</P>
-<P>
-In summary, anyone who gets the password gets
-repository access, and some measure of general system
-access as well. The password is available to anyone
-who can sniff network packets or read a protected
-(i.e., user read-only) file. If you want real
-security, get Kerberos.
-
-</P>
-
-
-<H3><A NAME="SEC30" HREF="cvs_toc.html#TOC30">Direct connection with
kerberos</A></H3>
-
-<P>
-<A NAME="IDX113"></A>
-<A NAME="IDX114"></A>
-The main disadvantage of using rsh is that all the data
-needs to pass through additional programs, so it may be
-slower. So if you have kerberos installed you can
-connect via a direct TCP connection,
-authenticating with kerberos.
-
-</P>
-<P>
-To do this, CVS needs to be compiled with kerberos
-support; when configuring CVS it tries to detect
-whether kerberos is present or you can use the
-<TT>`--with-krb4'</TT> flag to configure.
-
-</P>
-<P>
-The data transmitted is <EM>not</EM> encrypted by
-default. Encryption support must be compiled into both
-the client and server; use the
-<TT>`--enable-encryption'</TT> configure option to turn it
-on. You must then use the <CODE>-x</CODE> global option to
-request encryption.
-
-</P>
-<P>
-<A NAME="IDX115"></A>
-You need to edit <CODE>inetd.conf</CODE> on the server
-machine to run <CODE>cvs kserver</CODE>. The client uses
-port 1999 by default; if you want to use another port
-specify it in the <CODE>CVS_CLIENT_PORT</CODE> environment
-variable on the client.
-
-</P>
-<P>
-<A NAME="IDX116"></A>
-When you want to use CVS, get a ticket in the
-usual way (generally <CODE>kinit</CODE>); it must be a ticket
-which allows you to log into the server machine. Then
-you are ready to go:
-
-</P>
-
-<PRE>
-cvs -d :kserver:chainsaw.brickyard.com:/user/local/cvsroot checkout foo
-</PRE>
-
-<P>
-Previous versions of CVS would fall back to a
-connection via rsh; this version will not do so.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_4.html">previous</A>,
<A HREF="cvs_6.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_6.html
===================================================================
RCS file: manual/html_chapter/cvs_6.html
diff -N manual/html_chapter/cvs_6.html
--- manual/html_chapter/cvs_6.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,285 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Starting a project with CVS</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_5.html">previous</A>,
<A HREF="cvs_7.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC31" HREF="cvs_toc.html#TOC31">Starting a project with
CVS</A></H1>
-<P>
-<A NAME="IDX117"></A>
-<A NAME="IDX118"></A>
-
-</P>
-<P>
-Because renaming files and moving them between
-directories is somewhat inconvenient, the first thing
-you do when you start a new project should be to think
-through your file organization. It is not impossible
-to rename or move files, but it does increase the
-potential for confusion and CVS does have some
-quirks particularly in the area of renaming
-directories. See section <A HREF="cvs_14.html#SEC67">Moving and renaming
files</A>.
-
-</P>
-<P>
-What to do next depends on the situation at hand.
-
-</P>
-
-
-
-<H2><A NAME="SEC32" HREF="cvs_toc.html#TOC32">Setting up the files</A></H2>
-
-<P>
-The first step is to create the files inside the repository. This can
-be done in a couple of different ways.
-
-</P>
-
-
-
-<H3><A NAME="SEC33" HREF="cvs_toc.html#TOC33">Creating a directory tree from a
number of files</A></H3>
-<P>
-<A NAME="IDX119"></A>
-
-</P>
-<P>
-When you begin using CVS, you will probably already have several
-projects that can be
-put under CVS control. In these cases the easiest way is to use the
-<CODE>import</CODE> command. An example is probably the easiest way to
-explain how to use it. If the files you want to install in
-CVS reside in <TT>`<VAR>wdir</VAR>'</TT>, and you want them to appear in the
-repository as <TT>`$CVSROOT/yoyodyne/<VAR>rdir</VAR>'</TT>, you can do this:
-
-</P>
-
-<PRE>
-$ cd <VAR>wdir</VAR>
-$ cvs import -m "Imported sources" yoyodyne/<VAR>rdir</VAR> yoyo start
-</PRE>
-
-<P>
-Unless you supply a log message with the <SAMP>`-m'</SAMP>
-flag, CVS starts an editor and prompts for a
-message. The string <SAMP>`yoyo'</SAMP> is a <EM>vendor tag</EM>,
-and <SAMP>`start'</SAMP> is a <EM>release tag</EM>. They may fill
-no purpose in this context, but since CVS requires
-them they must be present. See section <A HREF="cvs_13.html#SEC63">Tracking
third-party sources</A>, for
-more information about them.
-
-</P>
-<P>
-You can now verify that it worked, and remove your
-original source directory.
-
-</P>
-
-<PRE>
-$ cd ..
-$ mv <VAR>dir</VAR> <VAR>dir</VAR>.orig
-$ cvs checkout yoyodyne/<VAR>dir</VAR> # Explanation below
-$ ls -R yoyodyne
-$ rm -r <VAR>dir</VAR>.orig
-</PRE>
-
-<P>
-Erasing the original sources is a good idea, to make sure that you do
-not accidentally edit them in <VAR>dir</VAR>, bypassing CVS.
-Of course, it would be wise to make sure that you have
-a backup of the sources before you remove them.
-
-</P>
-<P>
-The <CODE>checkout</CODE> command can either take a module
-name as argument (as it has done in all previous
-examples) or a path name relative to <CODE>$CVSROOT</CODE>,
-as it did in the example above.
-
-</P>
-<P>
-It is a good idea to check that the permissions
-CVS sets on the directories inside <SAMP>`$CVSROOT'</SAMP>
-are reasonable, and that they belong to the proper
-groups. See section <A HREF="cvs_5.html#SEC19">File permissions</A>.
-
-</P>
-<P>
-If some of the files you want to import are binary, you
-may want to use the wrappers features to specify which
-files are binary and which are not. See section <A
HREF="cvs_21.html#SEC138">The cvswrappers file</A>.
-
-</P>
-
-
-<H3><A NAME="SEC34" HREF="cvs_toc.html#TOC34">Creating Files From Other
Version Control Systems</A></H3>
-<P>
-<A NAME="IDX120"></A>
-
-</P>
-<P>
-If you have a project which you are maintaining with
-another version control system, such as RCS, you
-may wish to put the files from that project into
-CVS, and preserve the revision history of the
-files.
-
-</P>
-<DL COMPACT>
-
-<DT>From RCS
-<DD>
-<A NAME="IDX121"></A>
-
-If you have been using RCS, find the RCS
-files--usually a file named <TT>`foo.c'</TT> will have its
-RCS file in <TT>`RCS/foo.c,v'</TT> (but it could be
-other places; consult the RCS documentation for
-details). Then create the appropriate directories in
-CVS if they do not already exist. Then copy the
-files into the appropriate directories in the CVS
-repository (the name in the repository must be the name
-of the source file with <SAMP>`,v'</SAMP> added; the files go
-directly in the appopriate directory of the repository,
-not in an <TT>`RCS'</TT> subdirectory). This is one of the
-few times when it is a good idea to access the CVS
-repository directly, rather than using CVS
-commands. Then you are ready to check out a new
-working directory.
-
-The RCS file should not be locked when you move it
-into CVS; if it is, CVS will have trouble
-letting you operate on it.
-
-<DT>From another version control system
-<DD>
-Many version control systems have the ability to export
-RCS files in the standard format. If yours does,
-export the RCS files and then follow the above
-instructions.
-
-<A NAME="IDX122"></A>
-<DT>From SCCS
-<DD>
-There is a script in the <TT>`contrib'</TT> directory of
-the CVS source distribution called <TT>`sccs2rcs'</TT>
-which converts SCCS files to RCS files.
-Note: you must run it on a machine which has both
-SCCS and RCS installed, and like everything
-else in contrib it is unsupported (your mileage may
-vary).
-</DL>
-
-
-
-<H3><A NAME="SEC35" HREF="cvs_toc.html#TOC35">Creating a directory tree from
scratch</A></H3>
-
-<P>
-For a new project, the easiest thing to do is probably
-to create an empty directory structure, like this:
-
-</P>
-
-<PRE>
-$ mkdir tc
-$ mkdir tc/man
-$ mkdir tc/testing
-</PRE>
-
-<P>
-After that, you use the <CODE>import</CODE> command to create
-the corresponding (empty) directory structure inside
-the repository:
-
-</P>
-
-<PRE>
-$ cd tc
-$ cvs import -m "Created directory structure" yoyodyne/<VAR>dir</VAR> yoyo
start
-</PRE>
-
-<P>
-Then, use <CODE>add</CODE> to add files (and new directories)
-as they appear.
-
-</P>
-<P>
-Check that the permissions CVS sets on the
-directories inside <SAMP>`$CVSROOT'</SAMP> are reasonable.
-
-</P>
-
-
-<H2><A NAME="SEC36" HREF="cvs_toc.html#TOC36">Defining the module</A></H2>
-<P>
-<A NAME="IDX123"></A>
-<A NAME="IDX124"></A>
-<A NAME="IDX125"></A>
-<A NAME="IDX126"></A>
-
-</P>
-<P>
-The next step is to define the module in the
-<TT>`modules'</TT> file. This is not strictly necessary,
-but modules can be convenient in grouping together
-related files and directories.
-
-</P>
-<P>
-In simple cases these steps are sufficient to define a module.
-
-</P>
-
-<OL>
-<LI>
-
-Get a working copy of the modules file.
-
-
-<PRE>
-$ cvs checkout CVSROOT/modules
-$ cd CVSROOT
-</PRE>
-
-<LI>
-
-Edit the file and insert a line that defines the module. See section <A
HREF="cvs_5.html#SEC20">The administrative files</A>, for an introduction. See
section <A HREF="cvs_21.html#SEC137">The modules file</A>, for a full
-description of the modules file. You can use the
-following line to define the module <SAMP>`tc'</SAMP>:
-
-
-<PRE>
-tc yoyodyne/tc
-</PRE>
-
-<LI>
-
-Commit your changes to the modules file.
-
-
-<PRE>
-$ cvs commit -m "Added the tc module." modules
-</PRE>
-
-<LI>
-
-Release the modules module.
-
-
-<PRE>
-$ cd ..
-$ cvs release -d CVSROOT
-</PRE>
-
-</OL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_5.html">previous</A>,
<A HREF="cvs_7.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_7.html
===================================================================
RCS file: manual/html_chapter/cvs_7.html
diff -N manual/html_chapter/cvs_7.html
--- manual/html_chapter/cvs_7.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,974 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Multiple developers</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_6.html">previous</A>,
<A HREF="cvs_8.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC37" HREF="cvs_toc.html#TOC37">Multiple developers</A></H1>
-<P>
-<A NAME="IDX127"></A>
-<A NAME="IDX128"></A>
-<A NAME="IDX129"></A>
-<A NAME="IDX130"></A>
-<A NAME="IDX131"></A>
-<A NAME="IDX132"></A>
-<A NAME="IDX133"></A>
-<A NAME="IDX134"></A>
-
-</P>
-<P>
-When more than one person works on a software project
-things often get complicated. Often, two people try to
-edit the same file simultaneously. One solution, known
-as <EM>file locking</EM> or <EM>reserved checkouts</EM>, is
-to allow only one person to edit each file at a time.
-This is the only solution with some version control
-systems, including RCS and SCCS. CVS
-doesn't have a very nice implementation of reserved
-checkouts (yet) but there are ways to get it working
-(for example, see the <CODE>cvs admin -l</CODE> command in
-section <A HREF="cvs_20.html#SEC92">admin options</A>). It also may be
possible to use
-the watches features described below, together with
-suitable procedures (not enforced by software), to
-avoid having two people edit at the same time.
-
-</P>
-<P>
-The default model with CVS is known as
-<EM>unreserved checkouts</EM>. In this model, developers
-can edit their own <EM>working copy</EM> of a file
-simultaneously. The first person that commits his
-changes has no automatic way of knowing that another
-has started to edit it. Others will get an error
-message when they try to commit the file. They must
-then use CVS commands to bring their working copy
-up to date with the repository revision. This process
-is almost automatic.
-
-</P>
-<P>
-CVS also supports mechanisms which facilitate
-various kinds of communcation, without actually
-enforcing rules like reserved checkouts do.
-
-</P>
-<P>
-The rest of this chapter describes how these various
-models work, and some of the issues involved in
-choosing between them.
-
-</P>
-
-
-
-<H2><A NAME="SEC38" HREF="cvs_toc.html#TOC38">File status</A></H2>
-<P>
-<A NAME="IDX135"></A>
-<A NAME="IDX136"></A>
-
-</P>
-<P>
-Based on what operations you have performed on a
-checked out file, and what operations others have
-performed to that file in the repository, one can
-classify a file in a number of states. The states, as
-reported by the <CODE>status</CODE> command, are:
-
-</P>
-<DL COMPACT>
-
-<DT>Up-to-date
-<DD>
-<A NAME="IDX137"></A>
-
-The file is identical with the latest revision in the
-repository for the branch in use.
-
-<DT>Locally Modified
-<DD>
-<A NAME="IDX138"></A>
-You have edited the file, and not yet committed your changes.
-
-<DT>Locally Added
-<DD>
-<A NAME="IDX139"></A>
-You have added the file with <CODE>add</CODE>, and not yet
-committed your changes.
-
-<DT>Locally Removed
-<DD>
-<A NAME="IDX140"></A>
-You have removed the file with <CODE>remove</CODE>, and not yet
-committed your changes.
-
-<DT>Needs Checkout
-<DD>
-<A NAME="IDX141"></A>
-Someone else has committed a newer revision to the
-repository. The name is slightly misleading; you will
-ordinarily use <CODE>update</CODE> rather than
-<CODE>checkout</CODE> to get that newer revision.
-
-<DT>Needs Patch
-<DD>
-<A NAME="IDX142"></A>
-Like Needs Checkout, but the CVS server will send
-a patch rather than the entire file. Sending a patch or
-sending an entire file accomplishes the same thing.
-
-<DT>Needs Merge
-<DD>
-<A NAME="IDX143"></A>
-Someone else has committed a newer revision to the repository, and you
-have also made modifications to the file.
-
-<DT>Unresolved Conflict
-<DD>
-<A NAME="IDX144"></A>
-This is like Locally Modified, except that a previous
-<CODE>update</CODE> command gave a conflict. You need to
-resolve the conflict as described in section <A
HREF="cvs_7.html#SEC40">Conflicts example</A>.
-
-<DT>Unknown
-<DD>
-<A NAME="IDX145"></A>
-CVS doesn't know anything about this file. For
-example, you have created a new file and have not run
-<CODE>add</CODE>.
-
-</DL>
-
-<P>
-To help clarify the file status, <CODE>status</CODE> also
-reports the <CODE>Working revision</CODE> which is the
-revision that the file in the working directory derives
-from, and the <CODE>Repository revision</CODE> which is the
-latest revision in the repository for the branch in
-use.
-
-</P>
-<P>
-For information on the options to <CODE>status</CODE>, see
-section <A HREF="cvs_20.html#SEC128">status--Display status information on
checked out files</A>. For information on its <CODE>Sticky tag</CODE>
-and <CODE>Sticky date</CODE> output, see section <A
HREF="cvs_8.html#SEC54">Sticky tags</A>.
-For information on its <CODE>Sticky options</CODE> output,
-see the <SAMP>`-k'</SAMP> option in section <A
HREF="cvs_20.html#SEC133">update options</A>.
-
-</P>
-
-
-<H2><A NAME="SEC39" HREF="cvs_toc.html#TOC39">Bringing a file up to
date</A></H2>
-<P>
-<A NAME="IDX146"></A>
-<A NAME="IDX147"></A>
-<A NAME="IDX148"></A>
-<A NAME="IDX149"></A>
-
-</P>
-<P>
-When you want to update or merge a file, use the <CODE>update</CODE>
-command. For files that are not up to date this is roughly equivalent
-to a <CODE>checkout</CODE> command: the newest revision of the file is
-extracted from the repository and put in your working copy of the
-module.
-
-</P>
-<P>
-Your modifications to a file are never lost when you
-use <CODE>update</CODE>. If no newer revision exists,
-running <CODE>update</CODE> has no effect. If you have
-edited the file, and a newer revision is available,
-CVS will merge all changes into your working copy.
-
-</P>
-<P>
-For instance, imagine that you checked out revision 1.4 and started
-editing it. In the meantime someone else committed revision 1.5, and
-shortly after that revision 1.6. If you run <CODE>update</CODE> on the file
-now, CVS will incorporate all changes between revision 1.4 and 1.6 into
-your file.
-
-</P>
-<P>
-<A NAME="IDX150"></A>
-If any of the changes between 1.4 and 1.6 were made too
-close to any of the changes you have made, an
-<EM>overlap</EM> occurs. In such cases a warning is
-printed, and the resulting file includes both
-versions of the lines that overlap, delimited by
-special markers.
-See section <A HREF="cvs_20.html#SEC132">update--Bring work tree in sync with
repository</A>, for a complete description of the
-<CODE>update</CODE> command.
-
-</P>
-
-
-<H2><A NAME="SEC40" HREF="cvs_toc.html#TOC40">Conflicts example</A></H2>
-<P>
-<A NAME="IDX151"></A>
-<A NAME="IDX152"></A>
-<A NAME="IDX153"></A>
-
-</P>
-<P>
-Suppose revision 1.4 of <TT>`driver.c'</TT> contains this:
-
-</P>
-
-<PRE>
-#include <stdio.h>
-
-void main()
-{
- parse();
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? 0 : 1);
-}
-</PRE>
-
-<P>
-Revision 1.6 of <TT>`driver.c'</TT> contains this:
-
-</P>
-
-<PRE>
-#include <stdio.h>
-
-int main(int argc,
- char **argv)
-{
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(!!nerr);
-}
-</PRE>
-
-<P>
-Your working copy of <TT>`driver.c'</TT>, based on revision
-1.4, contains this before you run <SAMP>`cvs update'</SAMP>:
-
-</P>
-
-<PRE>
-#include <stdlib.h>
-#include <stdio.h>
-
-void main()
-{
- init_scanner();
- parse();
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
-}
-</PRE>
-
-<P>
-You run <SAMP>`cvs update'</SAMP>:
-
-</P>
-
-<PRE>
-$ cvs update driver.c
-RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
-retrieving revision 1.4
-retrieving revision 1.6
-Merging differences between 1.4 and 1.6 into driver.c
-rcsmerge warning: overlaps during merge
-cvs update: conflicts found in driver.c
-C driver.c
-</PRE>
-
-<P>
-<A NAME="IDX154"></A>
-CVS tells you that there were some conflicts.
-Your original working file is saved unmodified in
-<TT>`.#driver.c.1.4'</TT>. The new version of
-<TT>`driver.c'</TT> contains this:
-
-</P>
-
-<PRE>
-#include <stdlib.h>
-#include <stdio.h>
-
-int main(int argc,
- char **argv)
-{
- init_scanner();
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
-<<<<<<< driver.c
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
-=======
- exit(!!nerr);
->>>>>>> 1.6
-}
-</PRE>
-
-<P>
-<A NAME="IDX155"></A>
-<A NAME="IDX156"></A>
-<A NAME="IDX157"></A>
-<A NAME="IDX158"></A>
-<A NAME="IDX159"></A>
-
-</P>
-<P>
-Note how all non-overlapping modifications are incorporated in your working
-copy, and that the overlapping section is clearly marked with
-<SAMP>`<<<<<<<'</SAMP>, <SAMP>`======='</SAMP> and
<SAMP>`>>>>>>>'</SAMP>.
-
-</P>
-<P>
-<A NAME="IDX160"></A>
-<A NAME="IDX161"></A>
-You resolve the conflict by editing the file, removing the markers and
-the erroneous line. Suppose you end up with this file:
-
-<PRE>
-#include <stdlib.h>
-#include <stdio.h>
-
-int main(int argc,
- char **argv)
-{
- init_scanner();
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
-}
-</PRE>
-
-<P>
-You can now go ahead and commit this as revision 1.7.
-
-</P>
-
-<PRE>
-$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
-Checking in driver.c;
-/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
-new revision: 1.7; previous revision: 1.6
-done
-</PRE>
-
-<P>
-For your protection, CVS will refuse to check in a
-file if a conflict occurred and you have not resolved
-the conflict. Currently to resolve a conflict, you
-must change the timestamp on the file, and must also
-insure that the file contains no conflict markers. If
-your file legitimately contains conflict markers (that
-is, occurrences of <SAMP>`>>>>>>> '</SAMP> at the
start of a
-line that don't mark a conflict), then CVS has
-trouble handling this and you need to start hacking on
-the <CODE>CVS/Entries</CODE> file or other such workarounds.
-
-</P>
-<P>
-<A NAME="IDX162"></A>
-If you use release 1.04 or later of pcl-cvs (a GNU
-Emacs front-end for CVS) you can use an Emacs
-package called emerge to help you resolve conflicts.
-See the documentation for pcl-cvs.
-
-</P>
-
-
-<H2><A NAME="SEC41" HREF="cvs_toc.html#TOC41">Informing others about
commits</A></H2>
-<P>
-<A NAME="IDX163"></A>
-<A NAME="IDX164"></A>
-<A NAME="IDX165"></A>
-
-</P>
-<P>
-It is often useful to inform others when you commit a
-new revision of a file. The <SAMP>`-i'</SAMP> option of the
-<TT>`modules'</TT> file, or the <TT>`loginfo'</TT> file, can be
-used to automate this process. See section <A HREF="cvs_21.html#SEC137">The
modules file</A>.
-See section <A HREF="cvs_21.html#SEC144">Loginfo</A>. You can use these
features of CVS
-to, for instance, instruct CVS to mail a
-message to all developers, or post a message to a local
-newsgroup.
-
-</P>
-
-
-<H2><A NAME="SEC42" HREF="cvs_toc.html#TOC42">Several developers
simultaneously attempting to run CVS</A></H2>
-
-<P>
-<A NAME="IDX166"></A>
-If several developers try to run CVS at the same
-time, one may get the following message:
-
-</P>
-
-<PRE>
-[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
-</PRE>
-
-<P>
-CVS will try again every 30 seconds, and either
-continue with the operation or print the message again,
-if it still needs to wait. If a lock seems to stick
-around for an undue amount of time, find the person
-holding the lock and ask them about the cvs command
-they are running. If they aren't running a cvs
-command, look for and remove files starting with
-<TT>`#cvs.tfl'</TT>, <TT>`#cvs.rfl'</TT>, or <TT>`#cvs.wfl'</TT>
-from the repository.
-
-</P>
-<P>
-Note that these locks are to protect CVS's
-internal data structures and have no relationship to
-the word <EM>lock</EM> in the sense used by
-RCS---which refers to reserved checkouts
-(see section <A HREF="cvs_7.html#SEC37">Multiple developers</A>).
-
-</P>
-<P>
-Any number of people can be reading from a given
-repository at a time; only when someone is writing do
-the locks prevent other people from reading or writing.
-
-</P>
-<P>
-<A NAME="IDX167"></A>
-<A NAME="IDX168"></A>
-One might hope for the following property
-
-</P>
-
-<PRE>
-If someone commits some changes in one cvs command,
-then an update by someone else will either get all the
-changes, or none of them.
-</PRE>
-
-<P>
-but CVS does <EM>not</EM> have this property. For
-example, given the files
-
-</P>
-
-<PRE>
-a/one.c
-a/two.c
-b/three.c
-b/four.c
-</PRE>
-
-<P>
-if someone runs
-
-</P>
-
-<PRE>
-cvs ci a/two.c b/three.c
-</PRE>
-
-<P>
-and someone else runs <CODE>cvs update</CODE> at the same
-time, the person running <CODE>update</CODE> might get only
-the change to <TT>`b/three.c'</TT> and not the change to
-<TT>`a/two.c'</TT>.
-
-</P>
-
-
-<H2><A NAME="SEC43" HREF="cvs_toc.html#TOC43">Mechanisms to track who is
editing files</A></H2>
-<P>
-<A NAME="IDX169"></A>
-
-</P>
-<P>
-For many groups, use of CVS in its default mode is
-perfectly satisfactory. Users may sometimes go to
-check in a modification only to find that another
-modification has intervened, but they deal with it and
-proceed with their check in. Other groups prefer to be
-able to know who is editing what files, so that if two
-people try to edit the same file they can choose to
-talk about who is doing what when rather than be
-surprised at check in time. The features in this
-section allow such coordination, while retaining the
-ability of two developers to edit the same file at the
-same time.
-
-</P>
-<P>
-For maximum benefit developers should use <CODE>cvs
-edit</CODE> (not <CODE>chmod</CODE>) to make files read-write to
-edit them, and <CODE>cvs release</CODE> (not <CODE>rm</CODE>) to
-discard a working directory which is no longer in use,
-but CVS is not able to enforce this behavior.
-
-</P>
-
-
-
-<H3><A NAME="SEC44" HREF="cvs_toc.html#TOC44">Telling CVS to watch certain
files</A></H3>
-
-<P>
-To enable the watch features, you first specify that
-certain files are to be watched.
-
-</P>
-<P>
-<A NAME="IDX170"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watch on</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX171"></A>
-
-</P>
-<P>
-<A NAME="IDX172"></A>
-Specify that developers should run <CODE>cvs edit</CODE>
-before editing <VAR>files</VAR>. CVS will create working
-copies of <VAR>files</VAR> read-only, to remind developers
-to run the <CODE>cvs edit</CODE> command before working on
-them.
-
-</P>
-<P>
-If <VAR>files</VAR> includes the name of a directory, CVS
-arranges to watch all files added to the corresponding
-repository directory, and sets a default for files
-added in the future; this allows the user to set
-notification policies on a per-directory basis. The
-contents of the directory are processed recursively,
-unless the <CODE>-l</CODE> option is given.
-
-</P>
-<P>
-If <VAR>files</VAR> is omitted, it defaults to the current directory.
-
-</P>
-<P>
-<A NAME="IDX173"></A>
-</DL>
-
-</P>
-<P>
-<DL>
-<DT><U>Command:</U> <B>cvs watch off</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX174"></A>
-
-</P>
-<P>
-Do not provide notification about work on <VAR>files</VAR>. CVS will create
-working copies of <VAR>files</VAR> read-write.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> arguments are processed as for
<CODE>cvs
-watch on</CODE>.
-
-</P>
-</DL>
-
-
-
-<H3><A NAME="SEC45" HREF="cvs_toc.html#TOC45">Telling CVS to notify
you</A></H3>
-
-<P>
-You can tell CVS that you want to receive
-notifications about various actions taken on a file.
-You can do this without using <CODE>cvs watch on</CODE> for
-the file, but generally you will want to use <CODE>cvs
-watch on</CODE>, so that developers use the <CODE>cvs edit</CODE>
-command.
-
-</P>
-<P>
-<A NAME="IDX175"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watch add</B> <I>[<CODE>-a</CODE> action]
[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX176"></A>
-
-</P>
-<P>
-Add the current user to the list of people to receive notification of
-work done on <VAR>files</VAR>.
-
-</P>
-<P>
-The <CODE>-a</CODE> option specifies what kinds of events CVS should notify
-the user about. <VAR>action</VAR> is one of the following:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>edit</CODE>
-<DD>
-Another user has applied the <CODE>cvs edit</CODE> command (described
-below) to a file.
-
-<DT><CODE>unedit</CODE>
-<DD>
-Another user has applied the <CODE>cvs unedit</CODE> command (described
-below) or the <CODE>cvs release</CODE> command to a file, or has deleted
-the file and allowed <CODE>cvs update</CODE> to recreate it.
-
-<DT><CODE>commit</CODE>
-<DD>
-Another user has committed changes to a file.
-
-<DT><CODE>all</CODE>
-<DD>
-All of the above.
-
-<DT><CODE>none</CODE>
-<DD>
-None of the above. (This is useful with <CODE>cvs edit</CODE>,
-described below.)
-
-</DL>
-
-<P>
-The <CODE>-a</CODE> option may appear more than once, or not at all. If
-omitted, the action defaults to <CODE>all</CODE>.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> option are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-</DL>
-
-<P>
-<A NAME="IDX177"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watch remove</B> <I>[<CODE>-a</CODE> action]
[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX178"></A>
-
-</P>
-<P>
-Remove a notification request established using <CODE>cvs watch add</CODE>;
-the arguments are the same. If the <CODE>-a</CODE> option is present, only
-watches for the specified actions are removed.
-
-</P>
-</DL>
-
-<P>
-<A NAME="IDX179"></A>
-When the conditions exist for notification, CVS
-calls the <TT>`notify'</TT> administrative file. Edit
-<TT>`notify'</TT> as one edits the other administrative
-files (see section <A HREF="cvs_5.html#SEC20">The administrative files</A>).
This
-file follows the usual conventions for administrative
-files (see section <A HREF="cvs_21.html#SEC140">The common syntax</A>), where
each line is a regular
-expression followed by a command to execute. The
-command should contain a single ocurrence of <SAMP>`%s'</SAMP>
-which will be replaced by the user to notify; the rest
-of the information regarding the notification will be
-supplied to the command on standard input. The
-standard thing to put in the <CODE>notify</CODE> file is the
-single line:
-
-</P>
-
-<PRE>
-ALL mail %s -s \"CVS notification\"
-</PRE>
-
-<P>
-This causes users to be notified by electronic mail.
-
-</P>
-<P>
-<A NAME="IDX180"></A>
-Note that if you set this up in the straightforward
-way, users receive notifications on the server machine.
-One could of course write a <TT>`notify'</TT> script which
-directed notifications elsewhere, but to make this
-easy, CVS allows you to associate a notification
-address for each user. To do so create a file
-<TT>`users'</TT> in <TT>`CVSROOT'</TT> with a line for each
-user in the format <VAR>user</VAR>:<VAR>value</VAR>. Then
-instead of passing the name of the user to be notified
-to <TT>`notify'</TT>, CVS will pass the <VAR>value</VAR>
-(normally an email address on some other machine).
-
-</P>
-
-
-<H3><A NAME="SEC46" HREF="cvs_toc.html#TOC46">How to edit a file which is
being watched</A></H3>
-
-<P>
-<A NAME="IDX181"></A>
-Since a file which is being watched is checked out
-read-only, you cannot simply edit it. To make it
-read-write, and inform others that you are planning to
-edit it, use the <CODE>cvs edit</CODE> command. Some systems
-call this a <EM>checkout</EM>, but CVS uses that term
-for obtaining a copy of the sources (see section <A
HREF="cvs_4.html#SEC11">Getting the source</A>), an operation which those
systems call a
-<EM>get</EM> or a <EM>fetch</EM>.
-
-</P>
-<P>
-<A NAME="IDX182"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs edit</B> <I>[options] files ...</I>
-<DD><A NAME="IDX183"></A>
-
-</P>
-<P>
-Prepare to edit the working files <VAR>files</VAR>. CVS makes the
-<VAR>files</VAR> read-write, and notifies users who have requested
-<CODE>edit</CODE> notification for any of <VAR>files</VAR>.
-
-</P>
-<P>
-The <CODE>cvs edit</CODE> command accepts the same <VAR>options</VAR> as the
-<CODE>cvs watch add</CODE> command, and establishes a temporary watch for the
-user on <VAR>files</VAR>; CVS will remove the watch when <VAR>files</VAR> are
-<CODE>unedit</CODE>ed or <CODE>commit</CODE>ted. If the user does not wish to
-receive notifications, she should specify <CODE>-a none</CODE>.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> option are processed as for the
<CODE>cvs
-watch</CODE> commands.
-
-</P>
-</DL>
-
-<P>
-Normally when you are done with a set of changes, you
-use the <CODE>cvs commit</CODE> command, which checks in your
-changes and returns the watched files to their usual
-read-only state. But if you instead decide to abandon
-your changes, or not to make any changes, you can use
-the <CODE>cvs unedit</CODE> command.
-
-</P>
-<P>
-<A NAME="IDX184"></A>
-<A NAME="IDX185"></A>
-<A NAME="IDX186"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs unedit</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX187"></A>
-
-</P>
-<P>
-Abandon work on the working files <VAR>files</VAR>, and revert them to the
-repository versions on which they are based. CVS makes those
-<VAR>files</VAR> read-only for which users have requested notification using
-<CODE>cvs watch on</CODE>. CVS notifies users who have requested
<CODE>unedit</CODE>
-notification for any of <VAR>files</VAR>.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> option are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-<P>
-If watches are not in use, the <CODE>unedit</CODE> command
-probably does not work, and the way to revert to the
-repository version is to remove the file and then use
-<CODE>cvs update</CODE> to get a new copy. The meaning is
-not precisely the same; removing and updating may also
-bring in some changes which have been made in the
-repository since the last time you updated.
-</DL>
-
-</P>
-<P>
-When using client/server CVS, you can use the
-<CODE>cvs edit</CODE> and <CODE>cvs unedit</CODE> commands even if
-CVS is unable to succesfully communicate with the
-server; the notifications will be sent upon the next
-successful CVS command.
-
-</P>
-
-
-<H3><A NAME="SEC47" HREF="cvs_toc.html#TOC47">Information about who is
watching and editing</A></H3>
-
-<P>
-<A NAME="IDX188"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watchers</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX189"></A>
-
-</P>
-<P>
-List the users currently watching changes to <VAR>files</VAR>. The report
-includes the files being watched, and the mail address of each watcher.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> arguments are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-</DL>
-
-<P>
-<A NAME="IDX190"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs editors</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX191"></A>
-
-</P>
-<P>
-List the users currently working on <VAR>files</VAR>. The report
-includes the mail address of each user, the time when the user began
-working with the file, and the host and path of the working directory
-containing the file.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> arguments are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-</DL>
-
-
-
-<H3><A NAME="SEC48" HREF="cvs_toc.html#TOC48">Using watches with old versions
of CVS</A></H3>
-
-<P>
-<A NAME="IDX192"></A>
-If you use the watch features on a repository, it
-creates <TT>`CVS'</TT> directories in the repository and
-stores the information about watches in that directory.
-If you attempt to use CVS 1.6 or earlier with the
-repository, you get an error message such as
-
-</P>
-
-<PRE>
-cvs update: cannot open CVS/Entries for reading: No such file or directory
-</PRE>
-
-<P>
-and your operation will likely be aborted. To use the
-watch features, you must upgrade all copies of CVS
-which use that repository in local or server mode. If
-you cannot upgrade, use the <CODE>watch off</CODE> and
-<CODE>watch remove</CODE> commands to remove all watches, and
-that will restore the repository to a state which
-CVS 1.6 can cope with.
-
-</P>
-
-
-<H2><A NAME="SEC49" HREF="cvs_toc.html#TOC49">Choosing between reserved or
unreserved checkouts</A></H2>
-<P>
-<A NAME="IDX193"></A>
-
-</P>
-<P>
-Reserved and unreserved checkouts each have pros and
-cons. Let it be said that a lot of this is a matter of
-opinion or what works given different groups' working
-styles, but here is an attempt to briefly describe the
-issues. There are many ways to organize a team of
-developers. CVS does not try to enforce a certain
-organization. It is a tool that can be used in several
-ways.
-
-</P>
-<P>
-Reserved checkouts can be very counter-productive. If
-two persons want to edit different parts of a file,
-there may be no reason to prevent either of them from
-doing so. Also, it is common for someone to take out a
-lock on a file, because they are planning to edit it,
-but then forget to release the lock.
-
-</P>
-<P>
-People, especially people who are familiar with
-reserved checkouts, often wonder how often conflicts
-occur if unreserved checkouts are used, and how
-difficult they are to resolve. The experience with
-many groups is that they occur rarely and usually are
-relatively straightforward to resolve.
-
-</P>
-<P>
-The rarity of serious conflicts may be surprising, until one realizes
-that they occur only when two developers disagree on the proper design
-for a given section of code; such a disagreement suggests that the
-team has not been communicating properly in the first place. In order
-to collaborate under <EM>any</EM> source management regimen, developers
-must agree on the general design of the system; given this agreement,
-overlapping changes are usually straightforward to merge.
-
-</P>
-<P>
-In some cases unreserved checkouts are clearly
-inappropriate. If no merge tool exists for the kind of
-file you are managing (for example word processor files
-or files edited by Computer Aided Design programs), and
-it is not desirable to change to a program which uses a
-mergeable data format, then resolving conflicts is
-going to be unpleasant enough that you generally will
-be better off to simply avoid the conflicts instead, by
-using reserved checkouts.
-
-</P>
-<P>
-The watches features described above in section <A
HREF="cvs_7.html#SEC43">Mechanisms to track who is editing files</A>
-can be considered to be an intermediate model between
-reserved checkouts and unreserved checkouts. When you
-go to edit a file, it is possible to find out who else
-is editing it. And rather than having the system
-simply forbid both people editing the file, it can tell
-you what the situation is and let you figure out
-whether it is a problem in that particular case or not.
-Therefore, for some groups it can be considered the
-best of both the reserved checkout and unreserved
-checkout worlds.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_6.html">previous</A>,
<A HREF="cvs_8.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_8.html
===================================================================
RCS file: manual/html_chapter/cvs_8.html
diff -N manual/html_chapter/cvs_8.html
--- manual/html_chapter/cvs_8.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,428 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Branches</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_7.html">previous</A>,
<A HREF="cvs_9.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC50" HREF="cvs_toc.html#TOC50">Branches</A></H1>
-<P>
-<A NAME="IDX194"></A>
-<A NAME="IDX195"></A>
-<A NAME="IDX196"></A>
-
-</P>
-<P>
-So far, all revisions shown in this manual have been on
-the <EM>main trunk</EM>
-of the revision tree, i.e., all revision numbers
-have been of the form <VAR>x</VAR>.<VAR>y</VAR>. One useful
-feature, especially when maintaining several releases
-of a software product at once, is the ability to make
-branches on the revision tree. <EM>Tags</EM>, symbolic
-names for revisions, will also be
-introduced in this chapter.
-
-</P>
-
-
-
-<H2><A NAME="SEC51" HREF="cvs_toc.html#TOC51">Tags--Symbolic revisions</A></H2>
-<P>
-<A NAME="IDX197"></A>
-
-</P>
-<P>
-The revision numbers live a life of their own. They
-need not have anything at all to do with the release
-numbers of your software product. Depending
-on how you use CVS the revision numbers might change several times
-between two releases. As an example, some of the
-source files that make up RCS 5.6 have the following
-revision numbers:
-<A NAME="IDX198"></A>
-
-</P>
-
-<PRE>
-ci.c 5.21
-co.c 5.9
-ident.c 5.3
-rcs.c 5.12
-rcsbase.h 5.11
-rcsdiff.c 5.10
-rcsedit.c 5.11
-rcsfcmp.c 5.9
-rcsgen.c 5.10
-rcslex.c 5.11
-rcsmap.c 5.2
-rcsutil.c 5.10
-</PRE>
-
-<P>
-<A NAME="IDX199"></A>
-<A NAME="IDX200"></A>
-<A NAME="IDX201"></A>
-<A NAME="IDX202"></A>
-You can use the <CODE>tag</CODE> command to give a symbolic name to a
-certain revision of a file. You can use the <SAMP>`-v'</SAMP> flag to the
-<CODE>status</CODE> command to see all tags that a file has, and
-which revision numbers they represent. Tag names can
-contain uppercase and lowercase letters, digits,
-<SAMP>`-'</SAMP>, and <SAMP>`_'</SAMP>. The two tag names <CODE>BASE</CODE>
-and <CODE>HEAD</CODE> are reserved for use by CVS. It
-is expected that future names which are special to
-CVS will contain characters such as <SAMP>`%'</SAMP> or
-<SAMP>`='</SAMP>, rather than being named analogously to
-<CODE>BASE</CODE> and <CODE>HEAD</CODE>, to avoid conflicts with
-actual tag names.
-
-</P>
-<P>
-<A NAME="IDX203"></A>
-<A NAME="IDX204"></A>
-The following example shows how you can add a tag to a
-file. The commands must be issued inside your working
-copy of the module. That is, you should issue the
-command in the directory where <TT>`backend.c'</TT>
-resides.
-
-</P>
-
-<PRE>
-$ cvs tag release-0-4 backend.c
-T backend.c
-$ cvs status -v backend.c
-===================================================================
-File: backend.c Status: Up-to-date
-
- Version: 1.4 Tue Dec 1 14:39:01 1992
- RCS Version: 1.4 /usr/local/cvsroot/yoyodyne/tc/backend.c,v
- Sticky Tag: (none)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-0-4 (revision: 1.4)
-
-</PRE>
-
-<P>
-There is seldom reason to tag a file in isolation. A more common use is
-to tag all the files that constitute a module with the same tag at
-strategic points in the development life-cycle, such as when a release
-is made.
-
-</P>
-
-<PRE>
-$ cvs tag release-1-0 .
-cvs tag: Tagging .
-T Makefile
-T backend.c
-T driver.c
-T frontend.c
-T parser.c
-</PRE>
-
-<P>
-(When you give CVS a directory as argument, it generally applies the
-operation to all the files in that directory, and (recursively), to any
-subdirectories that it may contain. See section <A
HREF="cvs_10.html#SEC60">Recursive behavior</A>.)
-
-</P>
-<P>
-<A NAME="IDX205"></A>
-<A NAME="IDX206"></A>
-The <CODE>checkout</CODE> command has a flag, <SAMP>`-r'</SAMP>, that lets you
check out
-a certain revision of a module. This flag makes it easy to
-retrieve the sources that make up release 1.0 of the module <SAMP>`tc'</SAMP>
at
-any time in the future:
-
-</P>
-
-<PRE>
-$ cvs checkout -r release-1-0 tc
-</PRE>
-
-<P>
-This is useful, for instance, if someone claims that there is a bug in
-that release, but you cannot find the bug in the current working copy.
-
-</P>
-<P>
-You can also check out a module as it was at any given date.
-See section <A HREF="cvs_20.html#SEC97">checkout options</A>.
-
-</P>
-<P>
-When you tag more than one file with the same tag you
-can think about the tag as "a curve drawn through a
-matrix of filename vs. revision number." Say we have 5
-files with the following revisions:
-
-</P>
-
-<PRE>
- file1 file2 file3 file4 file5
-
- 1.1 1.1 1.1 1.1 /--1.1* <-*- TAG
- 1.2*- 1.2 1.2 -1.2*-
- 1.3 \- 1.3*- 1.3 / 1.3
- 1.4 \ 1.4 / 1.4
- \-1.5*- 1.5
- 1.6
-</PRE>
-
-<P>
-At some time in the past, the <CODE>*</CODE> versions were tagged.
-You can think of the tag as a handle attached to the curve
-drawn through the tagged revisions. When you pull on
-the handle, you get all the tagged revisions. Another
-way to look at it is that you "sight" through a set of
-revisions that is "flat" along the tagged revisions,
-like this:
-
-</P>
-
-<PRE>
- file1 file2 file3 file4 file5
-
- 1.1
- 1.2
- 1.1 1.3 _
- 1.1 1.2 1.4 1.1 /
- 1.2*----1.3*----1.5*----1.2*----1.1 (--- <--- Look here
- 1.3 1.6 1.3 \_
- 1.4 1.4
- 1.5
-</PRE>
-
-
-
-<H2><A NAME="SEC52" HREF="cvs_toc.html#TOC52">What branches are good
for</A></H2>
-<P>
-<A NAME="IDX207"></A>
-<A NAME="IDX208"></A>
-<A NAME="IDX209"></A>
-
-</P>
-<P>
-Suppose that release 1.0 of tc has been made. You are continuing to
-develop tc, planning to create release 1.1 in a couple of months. After a
-while your customers start to complain about a fatal bug. You check
-out release 1.0 (see section <A HREF="cvs_8.html#SEC51">Tags--Symbolic
revisions</A>) and find the bug
-(which turns out to have a trivial fix). However, the current revision
-of the sources are in a state of flux and are not expected to be stable
-for at least another month. There is no way to make a
-bugfix release based on the newest sources.
-
-</P>
-<P>
-The thing to do in a situation like this is to create a <EM>branch</EM> on
-the revision trees for all the files that make up
-release 1.0 of tc. You can then make
-modifications to the branch without disturbing the main trunk. When the
-modifications are finished you can select to either incorporate them on
-the main trunk, or leave them on the branch.
-
-</P>
-
-
-<H2><A NAME="SEC53" HREF="cvs_toc.html#TOC53">Creating a branch</A></H2>
-<P>
-<A NAME="IDX210"></A>
-<A NAME="IDX211"></A>
-<A NAME="IDX212"></A>
-
-</P>
-<P>
-The <CODE>rtag</CODE> command can be used to create a branch.
-The <CODE>rtag</CODE> command is much like <CODE>tag</CODE>, but it
-does not require that you have a working copy of the
-module. See section <A HREF="cvs_20.html#SEC126">rtag--Add a symbolic tag to
a module</A>. (You can also use the <CODE>tag</CODE>
-command; see section <A HREF="cvs_20.html#SEC130">tag--Add a symbolic tag to
checked out versions of files</A>).
-
-</P>
-
-<PRE>
-$ cvs rtag -b -r release-1-0 release-1-0-patches tc
-</PRE>
-
-<P>
-The <SAMP>`-b'</SAMP> flag makes <CODE>rtag</CODE> create a branch
-(rather than just a symbolic revision name). <SAMP>`-r
-release-1-0'</SAMP> says that this branch should be rooted at the node (in
-the revision tree) that corresponds to the tag
-<SAMP>`release-1-0'</SAMP>. Note that the numeric revision number that matches
-<SAMP>`release-1-0'</SAMP> will probably be different from file to file. The
-name of the new branch is <SAMP>`release-1-0-patches'</SAMP>, and the
-module affected is <SAMP>`tc'</SAMP>.
-
-</P>
-<P>
-To fix the problem in release 1.0, you need a working
-copy of the branch you just created.
-
-</P>
-
-<PRE>
-$ cvs checkout -r release-1-0-patches tc
-$ cvs status -v driver.c backend.c
-===================================================================
-File: driver.c Status: Up-to-date
-
- Version: 1.7 Sat Dec 5 18:25:54 1992
- RCS Version: 1.7 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
- Sticky Tag: release-1-0-patches (branch: 1.7.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.7.2)
- release-1-0 (revision: 1.7)
-
-===================================================================
-File: backend.c Status: Up-to-date
-
- Version: 1.4 Tue Dec 1 14:39:01 1992
- RCS Version: 1.4 /usr/local/cvsroot/yoyodyne/tc/backend.c,v
- Sticky Tag: release-1-0-patches (branch: 1.4.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.4.2)
- release-1-0 (revision: 1.4)
- release-0-4 (revision: 1.4)
-
-</PRE>
-
-<P>
-<A NAME="IDX213"></A>
-As the output from the <CODE>status</CODE> command shows the branch
-number is created by adding a digit at the tail of the revision number
-it is based on. (If <SAMP>`release-1-0'</SAMP> corresponds to revision 1.4,
the
-branch's revision number will be 1.4.2. For obscure reasons CVS always
-gives branches even numbers, starting at 2.
-See section <A HREF="cvs_3.html#SEC8">Revision numbers</A>).
-
-</P>
-
-
-<H2><A NAME="SEC54" HREF="cvs_toc.html#TOC54">Sticky tags</A></H2>
-<P>
-<A NAME="IDX214"></A>
-<A NAME="IDX215"></A>
-<A NAME="IDX216"></A>
-
-</P>
-<P>
-The <SAMP>`-r release-1-0-patches'</SAMP> flag that was given
-to <CODE>checkout</CODE> in the previous example
-is <EM>sticky</EM>, that is, it will apply to subsequent commands
-in this directory. If you commit any modifications, they are
-committed on the branch. You can later merge the modifications into
-the main trunk. See section <A HREF="cvs_9.html#SEC55">Merging</A>.
-
-</P>
-<P>
-You can use the <CODE>status</CODE> command to see what
-sticky tags or dates are set:
-
-</P>
-
-<PRE>
-$ vi driver.c # Fix the bugs
-$ cvs commit -m "Fixed initialization bug" driver.c
-Checking in driver.c;
-/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
-new revision: 1.7.2.1; previous revision: 1.7
-done
-$ cvs status -v driver.c
-===================================================================
-File: driver.c Status: Up-to-date
-
- Version: 1.7.2.1 Sat Dec 5 19:35:03 1992
- RCS Version: 1.7.2.1 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
- Sticky Tag: release-1-0-patches (branch: 1.7.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.7.2)
- release-1-0 (revision: 1.7)
-
-</PRE>
-
-<P>
-<A NAME="IDX217"></A>
-<A NAME="IDX218"></A>
-<A NAME="IDX219"></A>
-The sticky tags will remain on your working files until
-you delete them with <SAMP>`cvs update -A'</SAMP>. The
-<SAMP>`-A'</SAMP> option retrieves the version of the file from
-the head of the trunk, and forgets any sticky tags,
-dates, or options.
-
-</P>
-<P>
-<A NAME="IDX220"></A>
-Sticky tags are not just for branches. For example,
-suppose that you want to avoid updating your working
-directory, to isolate yourself from possibly
-destabilizing changes other people are making. You
-can, of course, just refrain from running <CODE>cvs
-update</CODE>. But if you want to avoid updating only a
-portion of a larger tree, then sticky tags can help.
-If you check out a certain revision (such as 1.4) it
-will become sticky. Subsequent <CODE>cvs update</CODE> will
-not retrieve the latest revision until you reset the
-tag with <CODE>cvs update -A</CODE>. Likewise, use of the
-<SAMP>`-D'</SAMP> option to <CODE>update</CODE> or <CODE>checkout</CODE>
-sets a <EM>sticky date</EM>, which, similarly, causes that
-date to be used for future retrievals.
-
-</P>
-<P>
-<A NAME="IDX221"></A>
-<A NAME="IDX222"></A>
-Many times you will want to retrieve an old version of
-a file without setting a sticky tag. The way to do
-that is with the <SAMP>`-p'</SAMP> option to <CODE>checkout</CODE> or
-<CODE>update</CODE>, which sends the contents of the file to
-standard output. For example, suppose you have a file
-named <TT>`file1'</TT> which existed as revision 1.1, and
-you then removed it (thus adding a dead revision 1.2).
-Now suppose you want to add it again, with the same
-contents it had previously. Here is how to do it:
-
-</P>
-
-<PRE>
-$ cvs update -p -r 1.1 file1 >file1
-===================================================================
-Checking out file1
-RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
-VERS: 1.1
-***************
-$ cvs add file1
-cvs add: re-adding file file1 (in place of dead revision 1.2)
-cvs add: use 'cvs commit' to add this file permanently
-$ cvs commit -m test
-Checking in file1;
-/tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1
-new revision: 1.3; previous revision: 1.2
-done
-$
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_7.html">previous</A>,
<A HREF="cvs_9.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_9.html
===================================================================
RCS file: manual/html_chapter/cvs_9.html
diff -N manual/html_chapter/cvs_9.html
--- manual/html_chapter/cvs_9.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,259 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Merging</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_8.html">previous</A>,
<A HREF="cvs_10.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC55" HREF="cvs_toc.html#TOC55">Merging</A></H1>
-<P>
-<A NAME="IDX223"></A>
-<A NAME="IDX224"></A>
-<A NAME="IDX225"></A>
-<A NAME="IDX226"></A>
-<A NAME="IDX227"></A>
-
-</P>
-<P>
-You can include the changes made between any two
-revisions into your working copy, by <EM>merging</EM>.
-You can then commit that revision, and thus effectively
-copy the changes onto another branch.
-
-</P>
-
-
-
-<H2><A NAME="SEC56" HREF="cvs_toc.html#TOC56">Merging an entire branch</A></H2>
-<P>
-<A NAME="IDX228"></A>
-<A NAME="IDX229"></A>
-
-</P>
-<P>
-You can merge changes made on a branch into your working copy by giving
-the <SAMP>`-j <VAR>branch</VAR>'</SAMP> flag to the <CODE>update</CODE>
command. With one
-<SAMP>`-j <VAR>branch</VAR>'</SAMP> option it merges the changes made between
the
-point where the branch forked and newest revision on that branch (into
-your working copy).
-
-</P>
-<P>
-<A NAME="IDX230"></A>
-The <SAMP>`-j'</SAMP> stands for "join".
-
-</P>
-<P>
-<A NAME="IDX231"></A>
-<A NAME="IDX232"></A>
-<A NAME="IDX233"></A>
-Consider this revision tree:
-
-</P>
-
-<PRE>
-+-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+
- !
- !
- ! +---------+ +---------+
-Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
- +---------+ +---------+
-</PRE>
-
-<P>
-The branch 1.2.2 has been given the tag (symbolic name) <SAMP>`R1fix'</SAMP>.
The
-following example assumes that the module <SAMP>`mod'</SAMP> contains only one
-file, <TT>`m.c'</TT>.
-
-</P>
-
-<PRE>
-$ cvs checkout mod # Retrieve the latest revision, 1.4
-
-$ cvs update -j R1fix m.c # Merge all changes made on the branch,
- # i.e. the changes between revision 1.2
- # and 1.2.2.2, into your working copy
- # of the file.
-
-$ cvs commit -m "Included R1fix" # Create revision 1.5.
-</PRE>
-
-<P>
-A conflict can result from a merge operation. If that
-happens, you should resolve it before committing the
-new revision. See section <A HREF="cvs_7.html#SEC40">Conflicts example</A>.
-
-</P>
-<P>
-The <CODE>checkout</CODE> command also supports the <SAMP>`-j
<VAR>branch</VAR>'</SAMP> flag. The
-same effect as above could be achieved with this:
-
-</P>
-
-<PRE>
-$ cvs checkout -j R1fix mod
-$ cvs commit -m "Included R1fix"
-</PRE>
-
-
-
-<H2><A NAME="SEC57" HREF="cvs_toc.html#TOC57">Merging from a branch several
times</A></H2>
-
-<P>
-Continuing our example, the revision tree now looks
-like this:
-
-</P>
-
-<PRE>
-+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+ +-----+
- ! *
- ! *
- ! +---------+ +---------+
-Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
- +---------+ +---------+
-</PRE>
-
-<P>
-where the starred line represents the merge from the
-<SAMP>`R1fix'</SAMP> branch to the main trunk, as just
-discussed.
-
-</P>
-<P>
-Now suppose that development continues on the
-<SAMP>`R1fix'</SAMP> branch:
-
-</P>
-
-<PRE>
-+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+ +-----+
- ! *
- ! *
- ! +---------+ +---------+ +---------+
-Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
- +---------+ +---------+ +---------+
-</PRE>
-
-<P>
-and then you want to merge those new changes onto the
-main trunk. If you just use the <CODE>cvs update -j
-R1fix m.c</CODE> command again, CVS will attempt to
-merge again the changes which you have already merged,
-which can have undesirable side effects.
-
-</P>
-<P>
-So instead you need to specify that you only want to
-merge the changes on the branch which have not yet been
-merged into the trunk. To do that you specify two
-<SAMP>`-j'</SAMP> options, and CVS merges the changes from
-the first revision to the second revision. For
-example, in this case the simplest way would be
-
-</P>
-
-<PRE>
-cvs update -j 1.2.2.2 -j R1fix m.c # Merge changes from 1.2.2.2 to the
- # head of the R1fix branch
-</PRE>
-
-<P>
-The problem with this is that you need to specify the
-1.2.2.2 revision manually. A slightly better approach
-might be to use the date the last merge was done:
-
-</P>
-
-<PRE>
-cvs update -j R1fix:yesterday -j R1fix m.c
-</PRE>
-
-<P>
-Better yet, tag the R1fix branch after every merge into
-the trunk, and then use that tag for subsequent merges:
-
-</P>
-
-<PRE>
-cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
-</PRE>
-
-
-
-<H2><A NAME="SEC58" HREF="cvs_toc.html#TOC58">Merging differences between any
two revisions</A></H2>
-<P>
-<A NAME="IDX234"></A>
-<A NAME="IDX235"></A>
-<A NAME="IDX236"></A>
-
-</P>
-<P>
-With two <SAMP>`-j <VAR>revision</VAR>'</SAMP> flags, the <CODE>update</CODE>
-(and <CODE>checkout</CODE>) command can merge the differences
-between any two revisions into your working file.
-
-</P>
-<P>
-<A NAME="IDX237"></A>
-<A NAME="IDX238"></A>
-
-<PRE>
-$ cvs update -j 1.5 -j 1.3 backend.c
-</PRE>
-
-<P>
-will <EM>remove</EM> all changes made between revision
-1.3 and 1.5. Note the order of the revisions!
-
-</P>
-<P>
-If you try to use this option when operating on
-multiple files, remember that the numeric revisions will
-probably be very different between the various files
-that make up a module. You almost always use symbolic
-tags rather than revision numbers when operating on
-multiple files.
-
-</P>
-
-
-<H2><A NAME="SEC59" HREF="cvs_toc.html#TOC59">Merging can add or remove
files</A></H2>
-
-<P>
-If the changes which you are merging involve removing
-or adding some files, <CODE>update -j</CODE> will reflect
-such additions or removals.
-
-</P>
-<P>
-For example:
-
-<PRE>
-cvs update -A
-touch a b c
-cvs add a b c ; cvs ci -m "added" a b c
-cvs tag -b branchtag
-cvs update -r branchtag
-touch d ; cvs add d
-rm a ; cvs rm a
-cvs ci -m "added d, removed a"
-cvs update -A
-cvs update -jbranchtag
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_8.html">previous</A>,
<A HREF="cvs_10.html">next</A>, <A HREF="cvs_25.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_chapter/cvs_toc.html
===================================================================
RCS file: manual/html_chapter/cvs_toc.html
diff -N manual/html_chapter/cvs_toc.html
--- manual/html_chapter/cvs_toc.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,258 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Table of Contents</TITLE>
-</HEAD>
-<BODY>
-<H1>CVS--Concurrent Versions System</H1>
-<P>
-<P><HR><P>
-<UL>
-<LI><A NAME="TOC1" HREF="cvs_1.html#SEC1">About this manual</A>
-<UL>
-<LI><A NAME="TOC2" HREF="cvs_1.html#SEC2">Checklist for the impatient
reader</A>
-<LI><A NAME="TOC3" HREF="cvs_1.html#SEC3">Credits</A>
-<LI><A NAME="TOC4" HREF="cvs_1.html#SEC4">BUGS</A>
-</UL>
-<LI><A NAME="TOC5" HREF="cvs_2.html#SEC5">What is CVS?</A>
-<UL>
-<LI><A NAME="TOC6" HREF="cvs_2.html#SEC6">CVS is not...</A>
-</UL>
-<LI><A NAME="TOC7" HREF="cvs_3.html#SEC7">Basic concepts</A>
-<UL>
-<LI><A NAME="TOC8" HREF="cvs_3.html#SEC8">Revision numbers</A>
-<LI><A NAME="TOC9" HREF="cvs_3.html#SEC9">Versions, revisions and releases</A>
-</UL>
-<LI><A NAME="TOC10" HREF="cvs_4.html#SEC10">A sample session</A>
-<UL>
-<LI><A NAME="TOC11" HREF="cvs_4.html#SEC11">Getting the source</A>
-<LI><A NAME="TOC12" HREF="cvs_4.html#SEC12">Committing your changes</A>
-<LI><A NAME="TOC13" HREF="cvs_4.html#SEC13">Cleaning up</A>
-<LI><A NAME="TOC14" HREF="cvs_4.html#SEC14">Viewing differences</A>
-</UL>
-<LI><A NAME="TOC15" HREF="cvs_5.html#SEC15">The Repository</A>
-<UL>
-<LI><A NAME="TOC16" HREF="cvs_5.html#SEC16">Telling CVS where your repository
is</A>
-<LI><A NAME="TOC17" HREF="cvs_5.html#SEC17">How data is stored in the
repository</A>
-<UL>
-<LI><A NAME="TOC18" HREF="cvs_5.html#SEC18">Where files are stored within the
repository</A>
-<LI><A NAME="TOC19" HREF="cvs_5.html#SEC19">File permissions</A>
-</UL>
-<LI><A NAME="TOC20" HREF="cvs_5.html#SEC20">The administrative files</A>
-<UL>
-<LI><A NAME="TOC21" HREF="cvs_5.html#SEC21">Editing administrative files</A>
-</UL>
-<LI><A NAME="TOC22" HREF="cvs_5.html#SEC22">Multiple repositories</A>
-<LI><A NAME="TOC23" HREF="cvs_5.html#SEC23">Creating a repository</A>
-<LI><A NAME="TOC24" HREF="cvs_5.html#SEC24">Remote repositories</A>
-<UL>
-<LI><A NAME="TOC25" HREF="cvs_5.html#SEC25">Connecting with rsh</A>
-<LI><A NAME="TOC26" HREF="cvs_5.html#SEC26">Direct connection with password
authentication</A>
-<UL>
-<LI><A NAME="TOC27" HREF="cvs_5.html#SEC27">Setting up the server for password
authentication</A>
-<LI><A NAME="TOC28" HREF="cvs_5.html#SEC28">Using the client with password
authentication</A>
-<LI><A NAME="TOC29" HREF="cvs_5.html#SEC29">Security considerations with
password authentication</A>
-</UL>
-<LI><A NAME="TOC30" HREF="cvs_5.html#SEC30">Direct connection with kerberos</A>
-</UL>
-</UL>
-<LI><A NAME="TOC31" HREF="cvs_6.html#SEC31">Starting a project with CVS</A>
-<UL>
-<LI><A NAME="TOC32" HREF="cvs_6.html#SEC32">Setting up the files</A>
-<UL>
-<LI><A NAME="TOC33" HREF="cvs_6.html#SEC33">Creating a directory tree from a
number of files</A>
-<LI><A NAME="TOC34" HREF="cvs_6.html#SEC34">Creating Files From Other Version
Control Systems</A>
-<LI><A NAME="TOC35" HREF="cvs_6.html#SEC35">Creating a directory tree from
scratch</A>
-</UL>
-<LI><A NAME="TOC36" HREF="cvs_6.html#SEC36">Defining the module</A>
-</UL>
-<LI><A NAME="TOC37" HREF="cvs_7.html#SEC37">Multiple developers</A>
-<UL>
-<LI><A NAME="TOC38" HREF="cvs_7.html#SEC38">File status</A>
-<LI><A NAME="TOC39" HREF="cvs_7.html#SEC39">Bringing a file up to date</A>
-<LI><A NAME="TOC40" HREF="cvs_7.html#SEC40">Conflicts example</A>
-<LI><A NAME="TOC41" HREF="cvs_7.html#SEC41">Informing others about commits</A>
-<LI><A NAME="TOC42" HREF="cvs_7.html#SEC42">Several developers simultaneously
attempting to run CVS</A>
-<LI><A NAME="TOC43" HREF="cvs_7.html#SEC43">Mechanisms to track who is editing
files</A>
-<UL>
-<LI><A NAME="TOC44" HREF="cvs_7.html#SEC44">Telling CVS to watch certain
files</A>
-<LI><A NAME="TOC45" HREF="cvs_7.html#SEC45">Telling CVS to notify you</A>
-<LI><A NAME="TOC46" HREF="cvs_7.html#SEC46">How to edit a file which is being
watched</A>
-<LI><A NAME="TOC47" HREF="cvs_7.html#SEC47">Information about who is watching
and editing</A>
-<LI><A NAME="TOC48" HREF="cvs_7.html#SEC48">Using watches with old versions of
CVS</A>
-</UL>
-<LI><A NAME="TOC49" HREF="cvs_7.html#SEC49">Choosing between reserved or
unreserved checkouts</A>
-</UL>
-<LI><A NAME="TOC50" HREF="cvs_8.html#SEC50">Branches</A>
-<UL>
-<LI><A NAME="TOC51" HREF="cvs_8.html#SEC51">Tags--Symbolic revisions</A>
-<LI><A NAME="TOC52" HREF="cvs_8.html#SEC52">What branches are good for</A>
-<LI><A NAME="TOC53" HREF="cvs_8.html#SEC53">Creating a branch</A>
-<LI><A NAME="TOC54" HREF="cvs_8.html#SEC54">Sticky tags</A>
-</UL>
-<LI><A NAME="TOC55" HREF="cvs_9.html#SEC55">Merging</A>
-<UL>
-<LI><A NAME="TOC56" HREF="cvs_9.html#SEC56">Merging an entire branch</A>
-<LI><A NAME="TOC57" HREF="cvs_9.html#SEC57">Merging from a branch several
times</A>
-<LI><A NAME="TOC58" HREF="cvs_9.html#SEC58">Merging differences between any
two revisions</A>
-<LI><A NAME="TOC59" HREF="cvs_9.html#SEC59">Merging can add or remove files</A>
-</UL>
-<LI><A NAME="TOC60" HREF="cvs_10.html#SEC60">Recursive behavior</A>
-<LI><A NAME="TOC61" HREF="cvs_11.html#SEC61">Adding files to a directory</A>
-<LI><A NAME="TOC62" HREF="cvs_12.html#SEC62">Removing files from a module</A>
-<LI><A NAME="TOC63" HREF="cvs_13.html#SEC63">Tracking third-party sources</A>
-<UL>
-<LI><A NAME="TOC64" HREF="cvs_13.html#SEC64">Importing a module for the first
time</A>
-<LI><A NAME="TOC65" HREF="cvs_13.html#SEC65">Updating a module with the import
command</A>
-<LI><A NAME="TOC66" HREF="cvs_13.html#SEC66">How to handle binary files with
cvs import</A>
-</UL>
-<LI><A NAME="TOC67" HREF="cvs_14.html#SEC67">Moving and renaming files</A>
-<UL>
-<LI><A NAME="TOC68" HREF="cvs_14.html#SEC68">The Normal way to Rename</A>
-<LI><A NAME="TOC69" HREF="cvs_14.html#SEC69">Moving the history file</A>
-<LI><A NAME="TOC70" HREF="cvs_14.html#SEC70">Copying the history file</A>
-</UL>
-<LI><A NAME="TOC71" HREF="cvs_15.html#SEC71">Moving and renaming
directories</A>
-<LI><A NAME="TOC72" HREF="cvs_16.html#SEC72">History browsing</A>
-<UL>
-<LI><A NAME="TOC73" HREF="cvs_16.html#SEC73">Log messages</A>
-<LI><A NAME="TOC74" HREF="cvs_16.html#SEC74">The history database</A>
-<LI><A NAME="TOC75" HREF="cvs_16.html#SEC75">User-defined logging</A>
-<LI><A NAME="TOC76" HREF="cvs_16.html#SEC76">Annotate command</A>
-</UL>
-<LI><A NAME="TOC77" HREF="cvs_17.html#SEC77">Keyword substitution</A>
-<UL>
-<LI><A NAME="TOC78" HREF="cvs_17.html#SEC78">RCS Keywords</A>
-<LI><A NAME="TOC79" HREF="cvs_17.html#SEC79">Using keywords</A>
-<LI><A NAME="TOC80" HREF="cvs_17.html#SEC80">Avoiding substitution</A>
-<LI><A NAME="TOC81" HREF="cvs_17.html#SEC81">Substitution modes</A>
-<LI><A NAME="TOC82" HREF="cvs_17.html#SEC82">Problems with the address@hidden
keyword.</A>
-</UL>
-<LI><A NAME="TOC83" HREF="cvs_18.html#SEC83">Handling binary files</A>
-<LI><A NAME="TOC84" HREF="cvs_19.html#SEC84">Revision management</A>
-<UL>
-<LI><A NAME="TOC85" HREF="cvs_19.html#SEC85">When to commit?</A>
-</UL>
-<LI><A NAME="TOC86" HREF="cvs_20.html#SEC86">Reference manual for CVS
commands</A>
-<UL>
-<LI><A NAME="TOC87" HREF="cvs_20.html#SEC87">Overall structure of CVS
commands</A>
-<LI><A NAME="TOC88" HREF="cvs_20.html#SEC88">Default options and the ~/.cvsrc
file</A>
-<LI><A NAME="TOC89" HREF="cvs_20.html#SEC89">Global options</A>
-<LI><A NAME="TOC90" HREF="cvs_20.html#SEC90">Common command options</A>
-<LI><A NAME="TOC91" HREF="cvs_20.html#SEC91">admin--Administration front end
for rcs</A>
-<UL>
-<LI><A NAME="TOC92" HREF="cvs_20.html#SEC92">admin options</A>
-<LI><A NAME="TOC93" HREF="cvs_20.html#SEC93">admin examples</A>
-<UL>
-<LI><A NAME="TOC94" HREF="cvs_20.html#SEC94">Outdating is dangerous</A>
-<LI><A NAME="TOC95" HREF="cvs_20.html#SEC95">Comment leaders</A>
-</UL>
-</UL>
-<LI><A NAME="TOC96" HREF="cvs_20.html#SEC96">checkout--Check out sources for
editing</A>
-<UL>
-<LI><A NAME="TOC97" HREF="cvs_20.html#SEC97">checkout options</A>
-<LI><A NAME="TOC98" HREF="cvs_20.html#SEC98">checkout examples</A>
-</UL>
-<LI><A NAME="TOC99" HREF="cvs_20.html#SEC99">commit--Check files into the
repository</A>
-<UL>
-<LI><A NAME="TOC100" HREF="cvs_20.html#SEC100">commit options</A>
-<LI><A NAME="TOC101" HREF="cvs_20.html#SEC101">commit examples</A>
-<UL>
-<LI><A NAME="TOC102" HREF="cvs_20.html#SEC102">New major release number</A>
-<LI><A NAME="TOC103" HREF="cvs_20.html#SEC103">Committing to a branch</A>
-<LI><A NAME="TOC104" HREF="cvs_20.html#SEC104">Creating the branch after
editing</A>
-</UL>
-</UL>
-<LI><A NAME="TOC105" HREF="cvs_20.html#SEC105">diff--Run diffs between
revisions</A>
-<UL>
-<LI><A NAME="TOC106" HREF="cvs_20.html#SEC106">diff options</A>
-<LI><A NAME="TOC107" HREF="cvs_20.html#SEC107">diff examples</A>
-</UL>
-<LI><A NAME="TOC108" HREF="cvs_20.html#SEC108">export--Export sources from
CVS, similar to checkout</A>
-<UL>
-<LI><A NAME="TOC109" HREF="cvs_20.html#SEC109">export options</A>
-</UL>
-<LI><A NAME="TOC110" HREF="cvs_20.html#SEC110">history--Show status of files
and users</A>
-<UL>
-<LI><A NAME="TOC111" HREF="cvs_20.html#SEC111">history options</A>
-</UL>
-<LI><A NAME="TOC112" HREF="cvs_20.html#SEC112">import--Import sources into
CVS, using vendor branches</A>
-<UL>
-<LI><A NAME="TOC113" HREF="cvs_20.html#SEC113">import options</A>
-<LI><A NAME="TOC114" HREF="cvs_20.html#SEC114">import output</A>
-<LI><A NAME="TOC115" HREF="cvs_20.html#SEC115">import examples</A>
-</UL>
-<LI><A NAME="TOC116" HREF="cvs_20.html#SEC116">log--Print out log information
for files</A>
-<UL>
-<LI><A NAME="TOC117" HREF="cvs_20.html#SEC117">log options</A>
-<LI><A NAME="TOC118" HREF="cvs_20.html#SEC118">log examples</A>
-</UL>
-<LI><A NAME="TOC119" HREF="cvs_20.html#SEC119">rdiff---'patch' format diffs
between releases</A>
-<UL>
-<LI><A NAME="TOC120" HREF="cvs_20.html#SEC120">rdiff options</A>
-<LI><A NAME="TOC121" HREF="cvs_20.html#SEC121">rdiff examples</A>
-</UL>
-<LI><A NAME="TOC122" HREF="cvs_20.html#SEC122">release--Indicate that a Module
is no longer in use</A>
-<UL>
-<LI><A NAME="TOC123" HREF="cvs_20.html#SEC123">release options</A>
-<LI><A NAME="TOC124" HREF="cvs_20.html#SEC124">release output</A>
-<LI><A NAME="TOC125" HREF="cvs_20.html#SEC125">release examples</A>
-</UL>
-<LI><A NAME="TOC126" HREF="cvs_20.html#SEC126">rtag--Add a symbolic tag to a
module</A>
-<UL>
-<LI><A NAME="TOC127" HREF="cvs_20.html#SEC127">rtag options</A>
-</UL>
-<LI><A NAME="TOC128" HREF="cvs_20.html#SEC128">status--Display status
information on checked out files</A>
-<UL>
-<LI><A NAME="TOC129" HREF="cvs_20.html#SEC129">status options</A>
-</UL>
-<LI><A NAME="TOC130" HREF="cvs_20.html#SEC130">tag--Add a symbolic tag to
checked out versions of files</A>
-<UL>
-<LI><A NAME="TOC131" HREF="cvs_20.html#SEC131">tag options</A>
-</UL>
-<LI><A NAME="TOC132" HREF="cvs_20.html#SEC132">update--Bring work tree in sync
with repository</A>
-<UL>
-<LI><A NAME="TOC133" HREF="cvs_20.html#SEC133">update options</A>
-<LI><A NAME="TOC134" HREF="cvs_20.html#SEC134">update output</A>
-<LI><A NAME="TOC135" HREF="cvs_20.html#SEC135">update examples</A>
-</UL>
-</UL>
-<LI><A NAME="TOC136" HREF="cvs_21.html#SEC136">Reference manual for the
Administrative files</A>
-<UL>
-<LI><A NAME="TOC137" HREF="cvs_21.html#SEC137">The modules file</A>
-<LI><A NAME="TOC138" HREF="cvs_21.html#SEC138">The cvswrappers file</A>
-<LI><A NAME="TOC139" HREF="cvs_21.html#SEC139">The commit support files</A>
-<UL>
-<LI><A NAME="TOC140" HREF="cvs_21.html#SEC140">The common syntax</A>
-</UL>
-<LI><A NAME="TOC141" HREF="cvs_21.html#SEC141">Commitinfo</A>
-<LI><A NAME="TOC142" HREF="cvs_21.html#SEC142">Editinfo</A>
-<UL>
-<LI><A NAME="TOC143" HREF="cvs_21.html#SEC143">Editinfo example</A>
-</UL>
-<LI><A NAME="TOC144" HREF="cvs_21.html#SEC144">Loginfo</A>
-<UL>
-<LI><A NAME="TOC145" HREF="cvs_21.html#SEC145">Loginfo example</A>
-<LI><A NAME="TOC146" HREF="cvs_21.html#SEC146">Keeping a checked out copy</A>
-</UL>
-<LI><A NAME="TOC147" HREF="cvs_21.html#SEC147">Rcsinfo</A>
-<LI><A NAME="TOC148" HREF="cvs_21.html#SEC148">Ignoring files via cvsignore</A>
-<LI><A NAME="TOC149" HREF="cvs_21.html#SEC149">The history file</A>
-<LI><A NAME="TOC150" HREF="cvs_21.html#SEC150">Expansions in administrative
files</A>
-</UL>
-<LI><A NAME="TOC151" HREF="cvs_22.html#SEC151">All environment variables which
affect CVS</A>
-<LI><A NAME="TOC152" HREF="cvs_23.html#SEC152">Troubleshooting</A>
-<UL>
-<LI><A NAME="TOC153" HREF="cvs_23.html#SEC153">Magic branch numbers</A>
-</UL>
-<LI><A NAME="TOC154" HREF="cvs_24.html#SEC154">GNU GENERAL PUBLIC LICENSE</A>
-<LI><A NAME="TOC155" HREF="cvs_25.html#SEC155">Index</A>
-</UL>
-<P><HR><P>
-This document was generated on 7 November 1998 using the
-<A HREF="http://wwwinfo.cern.ch/dis/texi2html/";>texi2html</A>
-translator version 1.52.</P>
-</BODY>
-</HTML>
Index: manual/html_mono/cvs.html
===================================================================
RCS file: manual/html_mono/cvs.html
diff -N manual/html_mono/cvs.html
--- manual/html_mono/cvs.html 8 Jun 2009 20:46:55 -0000 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,10307 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System</TITLE>
-</HEAD>
-<BODY>
-<H1>CVS--Concurrent Versions System</H1>
-<P>
-<P><HR><P>
-<H1>Table of Contents</H1>
-<UL>
-<LI><A NAME="TOC1" HREF="cvs.html#SEC1">About this manual</A>
-<UL>
-<LI><A NAME="TOC2" HREF="cvs.html#SEC2">Checklist for the impatient reader</A>
-<LI><A NAME="TOC3" HREF="cvs.html#SEC3">Credits</A>
-<LI><A NAME="TOC4" HREF="cvs.html#SEC4">BUGS</A>
-</UL>
-<LI><A NAME="TOC5" HREF="cvs.html#SEC5">What is CVS?</A>
-<UL>
-<LI><A NAME="TOC6" HREF="cvs.html#SEC6">CVS is not...</A>
-</UL>
-<LI><A NAME="TOC7" HREF="cvs.html#SEC7">Basic concepts</A>
-<UL>
-<LI><A NAME="TOC8" HREF="cvs.html#SEC8">Revision numbers</A>
-<LI><A NAME="TOC9" HREF="cvs.html#SEC9">Versions, revisions and releases</A>
-</UL>
-<LI><A NAME="TOC10" HREF="cvs.html#SEC10">A sample session</A>
-<UL>
-<LI><A NAME="TOC11" HREF="cvs.html#SEC11">Getting the source</A>
-<LI><A NAME="TOC12" HREF="cvs.html#SEC12">Committing your changes</A>
-<LI><A NAME="TOC13" HREF="cvs.html#SEC13">Cleaning up</A>
-<LI><A NAME="TOC14" HREF="cvs.html#SEC14">Viewing differences</A>
-</UL>
-<LI><A NAME="TOC15" HREF="cvs.html#SEC15">The Repository</A>
-<UL>
-<LI><A NAME="TOC16" HREF="cvs.html#SEC16">Telling CVS where your repository
is</A>
-<LI><A NAME="TOC17" HREF="cvs.html#SEC17">How data is stored in the
repository</A>
-<UL>
-<LI><A NAME="TOC18" HREF="cvs.html#SEC18">Where files are stored within the
repository</A>
-<LI><A NAME="TOC19" HREF="cvs.html#SEC19">File permissions</A>
-</UL>
-<LI><A NAME="TOC20" HREF="cvs.html#SEC20">The administrative files</A>
-<UL>
-<LI><A NAME="TOC21" HREF="cvs.html#SEC21">Editing administrative files</A>
-</UL>
-<LI><A NAME="TOC22" HREF="cvs.html#SEC22">Multiple repositories</A>
-<LI><A NAME="TOC23" HREF="cvs.html#SEC23">Creating a repository</A>
-<LI><A NAME="TOC24" HREF="cvs.html#SEC24">Remote repositories</A>
-<UL>
-<LI><A NAME="TOC25" HREF="cvs.html#SEC25">Connecting with rsh</A>
-<LI><A NAME="TOC26" HREF="cvs.html#SEC26">Direct connection with password
authentication</A>
-<UL>
-<LI><A NAME="TOC27" HREF="cvs.html#SEC27">Setting up the server for password
authentication</A>
-<LI><A NAME="TOC28" HREF="cvs.html#SEC28">Using the client with password
authentication</A>
-<LI><A NAME="TOC29" HREF="cvs.html#SEC29">Security considerations with
password authentication</A>
-</UL>
-<LI><A NAME="TOC30" HREF="cvs.html#SEC30">Direct connection with kerberos</A>
-</UL>
-</UL>
-<LI><A NAME="TOC31" HREF="cvs.html#SEC31">Starting a project with CVS</A>
-<UL>
-<LI><A NAME="TOC32" HREF="cvs.html#SEC32">Setting up the files</A>
-<UL>
-<LI><A NAME="TOC33" HREF="cvs.html#SEC33">Creating a directory tree from a
number of files</A>
-<LI><A NAME="TOC34" HREF="cvs.html#SEC34">Creating Files From Other Version
Control Systems</A>
-<LI><A NAME="TOC35" HREF="cvs.html#SEC35">Creating a directory tree from
scratch</A>
-</UL>
-<LI><A NAME="TOC36" HREF="cvs.html#SEC36">Defining the module</A>
-</UL>
-<LI><A NAME="TOC37" HREF="cvs.html#SEC37">Multiple developers</A>
-<UL>
-<LI><A NAME="TOC38" HREF="cvs.html#SEC38">File status</A>
-<LI><A NAME="TOC39" HREF="cvs.html#SEC39">Bringing a file up to date</A>
-<LI><A NAME="TOC40" HREF="cvs.html#SEC40">Conflicts example</A>
-<LI><A NAME="TOC41" HREF="cvs.html#SEC41">Informing others about commits</A>
-<LI><A NAME="TOC42" HREF="cvs.html#SEC42">Several developers simultaneously
attempting to run CVS</A>
-<LI><A NAME="TOC43" HREF="cvs.html#SEC43">Mechanisms to track who is editing
files</A>
-<UL>
-<LI><A NAME="TOC44" HREF="cvs.html#SEC44">Telling CVS to watch certain
files</A>
-<LI><A NAME="TOC45" HREF="cvs.html#SEC45">Telling CVS to notify you</A>
-<LI><A NAME="TOC46" HREF="cvs.html#SEC46">How to edit a file which is being
watched</A>
-<LI><A NAME="TOC47" HREF="cvs.html#SEC47">Information about who is watching
and editing</A>
-<LI><A NAME="TOC48" HREF="cvs.html#SEC48">Using watches with old versions of
CVS</A>
-</UL>
-<LI><A NAME="TOC49" HREF="cvs.html#SEC49">Choosing between reserved or
unreserved checkouts</A>
-</UL>
-<LI><A NAME="TOC50" HREF="cvs.html#SEC50">Branches</A>
-<UL>
-<LI><A NAME="TOC51" HREF="cvs.html#SEC51">Tags--Symbolic revisions</A>
-<LI><A NAME="TOC52" HREF="cvs.html#SEC52">What branches are good for</A>
-<LI><A NAME="TOC53" HREF="cvs.html#SEC53">Creating a branch</A>
-<LI><A NAME="TOC54" HREF="cvs.html#SEC54">Sticky tags</A>
-</UL>
-<LI><A NAME="TOC55" HREF="cvs.html#SEC55">Merging</A>
-<UL>
-<LI><A NAME="TOC56" HREF="cvs.html#SEC56">Merging an entire branch</A>
-<LI><A NAME="TOC57" HREF="cvs.html#SEC57">Merging from a branch several
times</A>
-<LI><A NAME="TOC58" HREF="cvs.html#SEC58">Merging differences between any two
revisions</A>
-<LI><A NAME="TOC59" HREF="cvs.html#SEC59">Merging can add or remove files</A>
-</UL>
-<LI><A NAME="TOC60" HREF="cvs.html#SEC60">Recursive behavior</A>
-<LI><A NAME="TOC61" HREF="cvs.html#SEC61">Adding files to a directory</A>
-<LI><A NAME="TOC62" HREF="cvs.html#SEC62">Removing files from a module</A>
-<LI><A NAME="TOC63" HREF="cvs.html#SEC63">Tracking third-party sources</A>
-<UL>
-<LI><A NAME="TOC64" HREF="cvs.html#SEC64">Importing a module for the first
time</A>
-<LI><A NAME="TOC65" HREF="cvs.html#SEC65">Updating a module with the import
command</A>
-<LI><A NAME="TOC66" HREF="cvs.html#SEC66">How to handle binary files with cvs
import</A>
-</UL>
-<LI><A NAME="TOC67" HREF="cvs.html#SEC67">Moving and renaming files</A>
-<UL>
-<LI><A NAME="TOC68" HREF="cvs.html#SEC68">The Normal way to Rename</A>
-<LI><A NAME="TOC69" HREF="cvs.html#SEC69">Moving the history file</A>
-<LI><A NAME="TOC70" HREF="cvs.html#SEC70">Copying the history file</A>
-</UL>
-<LI><A NAME="TOC71" HREF="cvs.html#SEC71">Moving and renaming directories</A>
-<LI><A NAME="TOC72" HREF="cvs.html#SEC72">History browsing</A>
-<UL>
-<LI><A NAME="TOC73" HREF="cvs.html#SEC73">Log messages</A>
-<LI><A NAME="TOC74" HREF="cvs.html#SEC74">The history database</A>
-<LI><A NAME="TOC75" HREF="cvs.html#SEC75">User-defined logging</A>
-<LI><A NAME="TOC76" HREF="cvs.html#SEC76">Annotate command</A>
-</UL>
-<LI><A NAME="TOC77" HREF="cvs.html#SEC77">Keyword substitution</A>
-<UL>
-<LI><A NAME="TOC78" HREF="cvs.html#SEC78">RCS Keywords</A>
-<LI><A NAME="TOC79" HREF="cvs.html#SEC79">Using keywords</A>
-<LI><A NAME="TOC80" HREF="cvs.html#SEC80">Avoiding substitution</A>
-<LI><A NAME="TOC81" HREF="cvs.html#SEC81">Substitution modes</A>
-<LI><A NAME="TOC82" HREF="cvs.html#SEC82">Problems with the address@hidden
keyword.</A>
-</UL>
-<LI><A NAME="TOC83" HREF="cvs.html#SEC83">Handling binary files</A>
-<LI><A NAME="TOC84" HREF="cvs.html#SEC84">Revision management</A>
-<UL>
-<LI><A NAME="TOC85" HREF="cvs.html#SEC85">When to commit?</A>
-</UL>
-<LI><A NAME="TOC86" HREF="cvs.html#SEC86">Reference manual for CVS commands</A>
-<UL>
-<LI><A NAME="TOC87" HREF="cvs.html#SEC87">Overall structure of CVS commands</A>
-<LI><A NAME="TOC88" HREF="cvs.html#SEC88">Default options and the ~/.cvsrc
file</A>
-<LI><A NAME="TOC89" HREF="cvs.html#SEC89">Global options</A>
-<LI><A NAME="TOC90" HREF="cvs.html#SEC90">Common command options</A>
-<LI><A NAME="TOC91" HREF="cvs.html#SEC91">admin--Administration front end for
rcs</A>
-<UL>
-<LI><A NAME="TOC92" HREF="cvs.html#SEC92">admin options</A>
-<LI><A NAME="TOC93" HREF="cvs.html#SEC93">admin examples</A>
-<UL>
-<LI><A NAME="TOC94" HREF="cvs.html#SEC94">Outdating is dangerous</A>
-<LI><A NAME="TOC95" HREF="cvs.html#SEC95">Comment leaders</A>
-</UL>
-</UL>
-<LI><A NAME="TOC96" HREF="cvs.html#SEC96">checkout--Check out sources for
editing</A>
-<UL>
-<LI><A NAME="TOC97" HREF="cvs.html#SEC97">checkout options</A>
-<LI><A NAME="TOC98" HREF="cvs.html#SEC98">checkout examples</A>
-</UL>
-<LI><A NAME="TOC99" HREF="cvs.html#SEC99">commit--Check files into the
repository</A>
-<UL>
-<LI><A NAME="TOC100" HREF="cvs.html#SEC100">commit options</A>
-<LI><A NAME="TOC101" HREF="cvs.html#SEC101">commit examples</A>
-<UL>
-<LI><A NAME="TOC102" HREF="cvs.html#SEC102">New major release number</A>
-<LI><A NAME="TOC103" HREF="cvs.html#SEC103">Committing to a branch</A>
-<LI><A NAME="TOC104" HREF="cvs.html#SEC104">Creating the branch after
editing</A>
-</UL>
-</UL>
-<LI><A NAME="TOC105" HREF="cvs.html#SEC105">diff--Run diffs between
revisions</A>
-<UL>
-<LI><A NAME="TOC106" HREF="cvs.html#SEC106">diff options</A>
-<LI><A NAME="TOC107" HREF="cvs.html#SEC107">diff examples</A>
-</UL>
-<LI><A NAME="TOC108" HREF="cvs.html#SEC108">export--Export sources from CVS,
similar to checkout</A>
-<UL>
-<LI><A NAME="TOC109" HREF="cvs.html#SEC109">export options</A>
-</UL>
-<LI><A NAME="TOC110" HREF="cvs.html#SEC110">history--Show status of files and
users</A>
-<UL>
-<LI><A NAME="TOC111" HREF="cvs.html#SEC111">history options</A>
-</UL>
-<LI><A NAME="TOC112" HREF="cvs.html#SEC112">import--Import sources into CVS,
using vendor branches</A>
-<UL>
-<LI><A NAME="TOC113" HREF="cvs.html#SEC113">import options</A>
-<LI><A NAME="TOC114" HREF="cvs.html#SEC114">import output</A>
-<LI><A NAME="TOC115" HREF="cvs.html#SEC115">import examples</A>
-</UL>
-<LI><A NAME="TOC116" HREF="cvs.html#SEC116">log--Print out log information for
files</A>
-<UL>
-<LI><A NAME="TOC117" HREF="cvs.html#SEC117">log options</A>
-<LI><A NAME="TOC118" HREF="cvs.html#SEC118">log examples</A>
-</UL>
-<LI><A NAME="TOC119" HREF="cvs.html#SEC119">rdiff---'patch' format diffs
between releases</A>
-<UL>
-<LI><A NAME="TOC120" HREF="cvs.html#SEC120">rdiff options</A>
-<LI><A NAME="TOC121" HREF="cvs.html#SEC121">rdiff examples</A>
-</UL>
-<LI><A NAME="TOC122" HREF="cvs.html#SEC122">release--Indicate that a Module is
no longer in use</A>
-<UL>
-<LI><A NAME="TOC123" HREF="cvs.html#SEC123">release options</A>
-<LI><A NAME="TOC124" HREF="cvs.html#SEC124">release output</A>
-<LI><A NAME="TOC125" HREF="cvs.html#SEC125">release examples</A>
-</UL>
-<LI><A NAME="TOC126" HREF="cvs.html#SEC126">rtag--Add a symbolic tag to a
module</A>
-<UL>
-<LI><A NAME="TOC127" HREF="cvs.html#SEC127">rtag options</A>
-</UL>
-<LI><A NAME="TOC128" HREF="cvs.html#SEC128">status--Display status information
on checked out files</A>
-<UL>
-<LI><A NAME="TOC129" HREF="cvs.html#SEC129">status options</A>
-</UL>
-<LI><A NAME="TOC130" HREF="cvs.html#SEC130">tag--Add a symbolic tag to checked
out versions of files</A>
-<UL>
-<LI><A NAME="TOC131" HREF="cvs.html#SEC131">tag options</A>
-</UL>
-<LI><A NAME="TOC132" HREF="cvs.html#SEC132">update--Bring work tree in sync
with repository</A>
-<UL>
-<LI><A NAME="TOC133" HREF="cvs.html#SEC133">update options</A>
-<LI><A NAME="TOC134" HREF="cvs.html#SEC134">update output</A>
-<LI><A NAME="TOC135" HREF="cvs.html#SEC135">update examples</A>
-</UL>
-</UL>
-<LI><A NAME="TOC136" HREF="cvs.html#SEC136">Reference manual for the
Administrative files</A>
-<UL>
-<LI><A NAME="TOC137" HREF="cvs.html#SEC137">The modules file</A>
-<LI><A NAME="TOC138" HREF="cvs.html#SEC138">The cvswrappers file</A>
-<LI><A NAME="TOC139" HREF="cvs.html#SEC139">The commit support files</A>
-<UL>
-<LI><A NAME="TOC140" HREF="cvs.html#SEC140">The common syntax</A>
-</UL>
-<LI><A NAME="TOC141" HREF="cvs.html#SEC141">Commitinfo</A>
-<LI><A NAME="TOC142" HREF="cvs.html#SEC142">Editinfo</A>
-<UL>
-<LI><A NAME="TOC143" HREF="cvs.html#SEC143">Editinfo example</A>
-</UL>
-<LI><A NAME="TOC144" HREF="cvs.html#SEC144">Loginfo</A>
-<UL>
-<LI><A NAME="TOC145" HREF="cvs.html#SEC145">Loginfo example</A>
-<LI><A NAME="TOC146" HREF="cvs.html#SEC146">Keeping a checked out copy</A>
-</UL>
-<LI><A NAME="TOC147" HREF="cvs.html#SEC147">Rcsinfo</A>
-<LI><A NAME="TOC148" HREF="cvs.html#SEC148">Ignoring files via cvsignore</A>
-<LI><A NAME="TOC149" HREF="cvs.html#SEC149">The history file</A>
-<LI><A NAME="TOC150" HREF="cvs.html#SEC150">Expansions in administrative
files</A>
-</UL>
-<LI><A NAME="TOC151" HREF="cvs.html#SEC151">All environment variables which
affect CVS</A>
-<LI><A NAME="TOC152" HREF="cvs.html#SEC152">Troubleshooting</A>
-<UL>
-<LI><A NAME="TOC153" HREF="cvs.html#SEC153">Magic branch numbers</A>
-</UL>
-<LI><A NAME="TOC154" HREF="cvs.html#SEC154">GNU GENERAL PUBLIC LICENSE</A>
-<LI><A NAME="TOC155" HREF="cvs.html#SEC155">Index</A>
-</UL>
-<P><HR><P>
-
-<P>
-Version Management
-<P>
-with
-<P>
-CVS
-<P>
-for CVS 1.9
-<P>
-Per Cederqvist et al
-
-</P>
-<P>
-Copyright (C) 1992, 1993 Signum Support AB
-
-</P>
-<P>
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
-
-</P>
-<P>
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided also that the
-section entitled "GNU General Public License" is included exactly as
-in the original, and provided that the entire resulting derived work is
-distributed under the terms of a permission notice identical to this one.
-
-</P>
-<P>
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions,
-except that the section entitled "GNU General Public License" and
-this permission notice may be included in translations approved by the
-Free Software Foundation instead of in the original English.
-
-</P>
-
-
-
-<H1><A NAME="SEC1" HREF="cvs.html#TOC1">About this manual</A></H1>
-<P>
-<A NAME="IDX1"></A>
-<A NAME="IDX2"></A>
-
-</P>
-<P>
-Up to this point, one of the weakest parts of CVS
-has been the documentation. CVS is a complex
-program. Previous versions of the manual were written
-in the manual page format, which is not really well
-suited for such a complex program.
-
-</P>
-<P>
-When writing this manual, I had several goals in mind:
-
-</P>
-
-<UL>
-<LI>
-
-No knowledge of RCS should be necessary.
-
-<LI>
-
-No previous knowledge of revision control software
-should be necessary. All terms, such as <EM>revision
-numbers</EM>, <EM>revision trees</EM> and <EM>merging</EM> are
-explained as they are introduced.
-
-<LI>
-
-The manual should concentrate on the things CVS users
-want to do, instead of what the CVS commands can do.
-The first part of this manual leads you through things
-you might want to do while doing development, and
-introduces the relevant CVS commands as they are
-needed.
-
-<LI>
-
-Information should be easy to find. In the reference
-manual in the appendices almost all information about
-every CVS command is gathered together. There is also
-an extensive index, and a lot of cross references.
-</UL>
-
-<P>
-<A NAME="IDX3"></A>
-<A NAME="IDX4"></A>
-This manual was contributed by Signum Support AB in
-Sweden. Signum is yet another in the growing list of
-companies that support free software. You are free to
-copy both this manual and the CVS program.
-See section <A HREF="cvs.html#SEC154">GNU GENERAL PUBLIC LICENSE</A>, for the
details. Signum Support offers
-support contracts and binary distribution for many
-programs, such as CVS, GNU Emacs, the
-GNU C compiler and others. Write to us for
-more information.
-
-</P>
-
-<PRE>
-Signum Support AB
-Box 2044
-S-580 02 Linkoping
-Sweden
-
-Email: address@hidden
-Phone: +46 (0)13 - 21 46 00
-Fax: +46 (0)13 - 21 47 00
-</PRE>
-
-<P>
-Another company selling support for CVS is Cyclic
-Software, web: <CODE>http://www.cyclic.com/</CODE>, email:
-<CODE>address@hidden</CODE>.
-
-</P>
-
-
-
-<H2><A NAME="SEC2" HREF="cvs.html#TOC2">Checklist for the impatient
reader</A></H2>
-
-<P>
-CVS is a complex system. You will need to read
-the manual to be able to use all of its capabilities.
-There are dangers that can easily be avoided if you
-know about them, and this manual tries to warn you
-about them. This checklist is intended to help you
-avoid the dangers without reading the entire manual.
-If you intend to read the entire manual you can skip
-this table.
-
-</P>
-<DL COMPACT>
-
-<DT>Binary files
-<DD>
-CVS can handle binary files, but
-you must have RCS release 5.5 or later and
-a release of GNU diff that supports the <SAMP>`-a'</SAMP>
-flag (release 1.15 and later are OK). You must also
-configure both RCS and CVS to handle binary
-files when you install them.
-
-Keword substitution can be a source of trouble with
-binary files. See section <A HREF="cvs.html#SEC77">Keyword substitution</A>,
for
-solutions.
-
-<DT>The <CODE>admin</CODE> command
-<DD>
-Careless use of the <CODE>admin</CODE> command can cause
-CVS to cease working. See section <A
HREF="cvs.html#SEC91">admin--Administration front end for rcs</A>, before trying
-to use it.
-</DL>
-
-
-
-<H2><A NAME="SEC3" HREF="cvs.html#TOC3">Credits</A></H2>
-
-<P>
-<A NAME="IDX5"></A>
-<A NAME="IDX6"></A>
-Roland Pesch, Cygnus Support <<TT>address@hidden</TT>>
-wrote the manual pages which were distributed with
-CVS 1.3. Appendix A and B contain much text that
-was extracted from them. He also read an early draft
-of this manual and contributed many ideas and
-corrections.
-
-</P>
-<P>
-The mailing-list <CODE>info-cvs</CODE> is sometimes
-informative. I have included information from postings
-made by the following persons:
-David G. Grubbs <<TT>address@hidden</TT>>.
-
-</P>
-<P>
-Some text has been extracted from the man pages for
-RCS.
-
-</P>
-<P>
-The CVS FAQ by David G. Grubbs has provided
-useful material. The FAQ is no longer maintained,
-however, and this manual about the closest thing there
-is to a successor (with respect to documenting how to
-use CVS, at least).
-
-</P>
-<P>
-In addition, the following persons have helped by
-telling me about mistakes I've made:
-Roxanne Brunskill <<TT>address@hidden</TT>>,
-Kathy Dyer <<TT>address@hidden</TT>>,
-Karl Pingle <<TT>address@hidden</TT>>,
-Thomas A Peterson <<TT>address@hidden</TT>>,
-Inge Wallin <<TT>address@hidden</TT>>,
-Dirk Koschuetzki <<TT>address@hidden</TT>>
-and Michael Brown <<TT>address@hidden</TT>>.
-
-</P>
-
-
-<H2><A NAME="SEC4" HREF="cvs.html#TOC4">BUGS</A></H2>
-
-<P>
-<A NAME="IDX7"></A>
-<A NAME="IDX8"></A>
-This manual is known to have room for improvement.
-Here is a list of known deficiencies:
-
-</P>
-
-<UL>
-<LI>
-
-In the examples, the output from CVS is sometimes
-displayed, sometimes not.
-
-<LI>
-
-The input that you are supposed to type in the examples
-should have a different font than the output from the
-computer.
-
-<LI>
-
-This manual should be clearer about what file
-permissions you should set up in the repository, and
-about setuid/setgid.
-
-<LI>
-
-Some of the chapters are not yet complete. They are
-noted by comments in the <TT>`cvs.texinfo'</TT> file.
-
-<LI>
-
-<A NAME="IDX9"></A>
-<A NAME="IDX10"></A>
-<A NAME="IDX11"></A>
-This list is not complete. If you notice any error,
-omission, or something that is unclear, please send
-mail to <TT>address@hidden</TT>.
-</UL>
-
-<P>
-I hope that you will find this manual useful, despite
-the above-mentioned shortcomings.
-
-</P>
-
-<PRE>
-
-Linkoping, October 1993
-Per Cederqvist
-</PRE>
-
-
-
-<H1><A NAME="SEC5" HREF="cvs.html#TOC5">What is CVS?</A></H1>
-<P>
-<A NAME="IDX12"></A>
-<A NAME="IDX13"></A>
-<A NAME="IDX14"></A>
-
-</P>
-<P>
-CVS is a version control system. Using it, you can
-record the history of your source files.
-
-</P>
-
-<P>
-For example, bugs sometimes creep in when
-software is modified, and you might not detect the bug
-until a long time after you make the modification.
-With CVS, you can easily retrieve old versions to see
-exactly which change caused the bug. This can
-sometimes be a big help.
-
-</P>
-<P>
-You could of course save every version of every file
-you have ever created. This would
-however waste an enormous amount of disk space. CVS
-stores all the versions of a file in a single file in a
-clever way that only stores the differences between
-versions.
-
-</P>
-<P>
-CVS also helps you if you are part of a group of people working
-on the same project. It is all too easy to overwrite
-each others' changes unless you are extremely careful.
-Some editors, like GNU Emacs, try to make sure that
-the same file is never modified by two people at the
-same time. Unfortunately, if someone is using another
-editor, that safeguard will not work. CVS solves this problem
-by insulating the different developers from each other. Every
-developer works in his own directory, and CVS merges
-the work when each developer is done.
-
-</P>
-<P>
-<A NAME="IDX15"></A>
-<A NAME="IDX16"></A>
-<A NAME="IDX17"></A>
-<A NAME="IDX18"></A>
-CVS started out as a bunch of shell scripts written by
-Dick Grune, posted to <CODE>comp.sources.unix</CODE> in the volume 6
-release of December, 1986. While no actual code from
-these shell scripts is present in the current version
-of CVS much of the CVS conflict resolution algorithms
-come from them.
-
-</P>
-<P>
-In April, 1989, Brian Berliner designed and coded CVS.
-Jeff Polk later helped Brian with the design of the CVS
-module and vendor branch support.
-
-</P>
-<P>
-<A NAME="IDX19"></A>
-You can get CVS via anonymous ftp from a number of
-sites, for instance <TT>prep.ai.mit.edu</TT> in
-<TT>`pub/gnu'</TT>.
-
-</P>
-<P>
-<A NAME="IDX20"></A>
-<A NAME="IDX21"></A>
-<A NAME="IDX22"></A>
-There is a mailing list, known as <CODE>info-cvs</CODE>,
-devoted to CVS. To subscribe or
-unsubscribe
-send a message to
-<CODE>address@hidden</CODE>. Please be
-specific about your email address. As of May 1996,
-subscription requests are handled by a busy human
-being, so you cannot expect to be added or removed
-immediately. The usenet group
-<CODE>comp.software.config-mgmt</CODE> is also a suitable
-place for CVS discussions (along with other
-configuration management systems).
-
-</P>
-
-
-
-<H2><A NAME="SEC6" HREF="cvs.html#TOC6">CVS is not...</A></H2>
-
-<P>
-CVS can do a lot of things for you, but it does
-not try to be everything for everyone.
-
-</P>
-<DL COMPACT>
-
-<DT>CVS is not a build system.
-<DD>
-Though the structure of your repository and modules
-file interact with your build system
-(e.g. <TT>`Makefile'</TT>s), they are essentially
-independent.
-
-CVS does not dictate how you build anything. It
-merely stores files for retrieval in a tree structure
-you devise.
-
-CVS does not dictate how to use disk space in the
-checked out working directories. If you write your
-<TT>`Makefile'</TT>s or scripts in every directory so they
-have to know the relative positions of everything else,
-you wind up requiring the entire repository to be
-checked out.
-
-If you modularize your work, and construct a build
-system that will share files (via links, mounts,
-<CODE>VPATH</CODE> in <TT>`Makefile'</TT>s, etc.), you can
-arrange your disk usage however you like.
-
-But you have to remember that <EM>any</EM> such system is
-a lot of work to construct and maintain. CVS does
-not address the issues involved.
-
-Of course, you should place the tools created to
-support such a build system (scripts, <TT>`Makefile'</TT>s,
-etc) under CVS.
-
-Figuring out what files need to be rebuilt when
-something changes is, again, something to be handled
-outside the scope of CVS. One traditional
-approach is to use <CODE>make</CODE> for building, and use
-some automated tool for generating the depencies which
-<CODE>make</CODE> uses.
-
-<DT>CVS is not a substitute for management.
-<DD>
-Your managers and project leaders are expected to talk
-to you frequently enough to make certain you are aware
-of schedules, merge points, branch names and release
-dates. If they don't, CVS can't help.
-
-CVS is an instrument for making sources dance to
-your tune. But you are the piper and the composer. No
-instrument plays itself or writes its own music.
-
-<DT>CVS is not a substitute for developer communication.
-<DD>
-When faced with conflicts within a single file, most
-developers manage to resolve them without too much
-effort. But a more general definition of "conflict"
-includes problems too difficult to solve without
-communication between developers.
-
-CVS cannot determine when simultaneous changes
-within a single file, or across a whole collection of
-files, will logically conflict with one another. Its
-concept of a <EM>conflict</EM> is purely textual, arising
-when two changes to the same base file are near enough
-to spook the merge (i.e. <CODE>diff3</CODE>) command.
-
-CVS does not claim to help at all in figuring out
-non-textual or distributed conflicts in program logic.
-
-For example: Say you change the arguments to function
-<CODE>X</CODE> defined in file <TT>`A'</TT>. At the same time,
-someone edits file <TT>`B'</TT>, adding new calls to
-function <CODE>X</CODE> using the old arguments. You are
-outside the realm of CVS's competence.
-
-Acquire the habit of reading specs and talking to your
-peers.
-
-<DT>CVS does not have change control
-<DD>
-Change control refers to a number of things. First of
-all it can mean <EM>bug-tracking</EM>, that is being able
-to keep a database of reported bugs and the status of
-each one (is it fixed? in what release? has the bug
-submitter agreed that it is fixed?). For interfacing
-CVS to an external bug-tracking system, see the
-<TT>`rcsinfo'</TT> and <TT>`editinfo'</TT> files
-(see section <A HREF="cvs.html#SEC136">Reference manual for the Administrative
files</A>).
-
-Another aspect of change control is keeping track of
-the fact that changes to several files were in fact
-changed together as one logical change. If you check
-in several files in a single <CODE>cvs commit</CODE>
-operation, CVS then forgets that those files were
-checked in together, and the fact that they have the
-same log message is the only thing tying them
-together. Keeping a GNU style <TT>`ChangeLog'</TT>
-can help somewhat.
-
-Another aspect of change control, in some systems, is
-the ability to keep track of the status of each
-change. Some changes have been written by a developer,
-others have been reviewed by a second developer, and so
-on. Generally, the way to do this with CVS is to
-generate a diff (using <CODE>cvs diff</CODE> or <CODE>diff</CODE>)
-and email it to someone who can then apply it using the
-<CODE>patch</CODE> utility. This is very flexible, but
-depends on mechanisms outside CVS to make sure
-nothing falls through the cracks.
-
-<DT>CVS is not an automated testing program
-<DD>
-It should be possible to enforce mandatory use of a
-testsuite using the <CODE>commitinfo</CODE> file. I haven't
-heard a lot about projects trying to do that or whether
-there are subtle gotchas, however.
-
-<DT>CVS does not have a builtin process model
-<DD>
-Some systems provide ways to ensure that changes or
-releases go through various steps, with various
-approvals as needed. Generally, one can accomplish
-this with CVS but it might be a little more work.
-In some cases you'll want to use the <TT>`commitinfo'</TT>,
-<TT>`loginfo'</TT>, <TT>`rcsinfo'</TT>, or <TT>`editinfo'</TT>
-files, to require that certain steps be performed
-before cvs will allow a checkin. Also consider whether
-features such as branches and tags can be used to
-perform tasks such as doing work in a development tree
-and then merging certain changes over to a stable tree
-only once they have been proven.
-</DL>
-
-
-
-<H1><A NAME="SEC7" HREF="cvs.html#TOC7">Basic concepts</A></H1>
-<P>
-<A NAME="IDX23"></A>
-
-</P>
-<P>
-CVS stores all files in a centralized
-<EM>repository</EM> (see section <A HREF="cvs.html#SEC15">The Repository</A>).
-
-</P>
-<P>
-The repository contains directories and files, in an
-arbitrary tree. The <EM>modules</EM> feature can be used
-to group together a set of directories or files into a
-single entity (see section <A HREF="cvs.html#SEC137">The modules file</A>). A
typical usage is to
-define one module per project.
-
-</P>
-
-
-
-<H2><A NAME="SEC8" HREF="cvs.html#TOC8">Revision numbers</A></H2>
-<P>
-<A NAME="IDX24"></A>
-<A NAME="IDX25"></A>
-<A NAME="IDX26"></A>
-<A NAME="IDX27"></A>
-<A NAME="IDX28"></A>
-<A NAME="IDX29"></A>
-<A NAME="IDX30"></A>
-<A NAME="IDX31"></A>
-
-</P>
-<P>
-Each version of a file has a unique <EM>revision
-number</EM>. Revision numbers look like <SAMP>`1.1'</SAMP>,
-<SAMP>`1.2'</SAMP>, <SAMP>`1.3.2.2'</SAMP> or even <SAMP>`1.3.2.2.4.5'</SAMP>.
-A revision number always has an even number of
-period-separated decimal integers. By default revision
-1.1 is the first revision of a file. Each successive
-revision is given a new number by increasing the
-rightmost number by one. The following figure displays
-a few revisions, with newer revisions to the right.
-
-</P>
-
-<PRE>
- +-----+ +-----+ +-----+ +-----+ +-----+
- ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
- +-----+ +-----+ +-----+ +-----+ +-----+
-</PRE>
-
-<P>
-CVS is not limited to linear development. The
-<EM>revision tree</EM> can be split into <EM>branches</EM>,
-where each branch is a self-maintained line of
-development. Changes made on one branch can easily be
-moved back to the main trunk.
-
-</P>
-<P>
-Each branch has a <EM>branch number</EM>, consisting of an
-odd number of period-separated decimal integers. The
-branch number is created by appending an integer to the
-revision number where the corresponding branch forked
-off. Having branch numbers allows more than one branch
-to be forked off from a certain revision.
-
-</P>
-<P>
-All revisions on a branch have revision numbers formed
-by appending an ordinal number to the branch number.
-The following figure illustrates branching with an
-example.
-
-</P>
-
-<PRE>
- +-------------+
- Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 !
- / +-------------+
- /
- /
- +---------+ +---------+ +---------+ +---------+
-Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !----! 1.2.2.4 !
- / +---------+ +---------+ +---------+ +---------+
- /
- /
-+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+ +-----+
- !
- !
- ! +---------+ +---------+ +---------+
-Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
- +---------+ +---------+ +---------+
-
-</PRE>
-
-<P>
-The exact details of how the branch number is
-constructed is not something you normally need to be
-concerned about, but here is how it works: When
-CVS creates a branch number it picks the first
-unused even integer, starting with 2. So when you want
-to create a branch from revision 6.4 it will be
-numbered 6.4.2. All branch numbers ending in a zero
-(such as 6.4.0) are used internally by CVS
-(see section <A HREF="cvs.html#SEC153">Magic branch numbers</A>). The branch
1.1.1 has a
-special meaning. See section <A HREF="cvs.html#SEC63">Tracking third-party
sources</A>.
-
-</P>
-
-
-<H2><A NAME="SEC9" HREF="cvs.html#TOC9">Versions, revisions and
releases</A></H2>
-<P>
-<A NAME="IDX32"></A>
-<A NAME="IDX33"></A>
-<A NAME="IDX34"></A>
-
-</P>
-<P>
-A file can have several versions, as described above.
-Likewise, a software product can have several versions.
-A software product is often given a version number such
-as <SAMP>`4.1.1'</SAMP>.
-
-</P>
-<P>
-Versions in the first sense are called <EM>revisions</EM>
-in this document, and versions in the second sense are
-called <EM>releases</EM>. To avoid confusion, the word
-<EM>version</EM> is almost never used in this document.
-
-</P>
-
-
-<H1><A NAME="SEC10" HREF="cvs.html#TOC10">A sample session</A></H1>
-<P>
-<A NAME="IDX35"></A>
-<A NAME="IDX36"></A>
-<A NAME="IDX37"></A>
-<A NAME="IDX38"></A>
-<A NAME="IDX39"></A>
-<A NAME="IDX40"></A>
-
-</P>
-<P>
-This section describes a typical work-session using
-CVS. It assumes that a repository is set up
-(see section <A HREF="cvs.html#SEC15">The Repository</A>).
-
-</P>
-<P>
-Suppose you are working on a simple compiler. The source
-consists of a handful of C files and a <TT>`Makefile'</TT>.
-The compiler is called <SAMP>`tc'</SAMP> (Trivial Compiler),
-and the repository is set up so that there is a module
-called <SAMP>`tc'</SAMP>.
-
-</P>
-
-
-
-<H2><A NAME="SEC11" HREF="cvs.html#TOC11">Getting the source</A></H2>
-<P>
-<A NAME="IDX41"></A>
-<A NAME="IDX42"></A>
-<A NAME="IDX43"></A>
-<A NAME="IDX44"></A>
-<A NAME="IDX45"></A>
-
-</P>
-<P>
-The first thing you must do is to get your own working copy of the
-source for <SAMP>`tc'</SAMP>. For this, you use the <CODE>checkout</CODE>
command:
-
-</P>
-
-<PRE>
-$ cvs checkout tc
-</PRE>
-
-<P>
-This will create a new directory called <TT>`tc'</TT> and populate it with
-the source files.
-
-</P>
-
-<PRE>
-$ cd tc
-$ ls
-CVS Makefile backend.c driver.c frontend.c parser.c
-</PRE>
-
-<P>
-The <TT>`CVS'</TT> directory is used internally by
-CVS. Normally, you should not modify or remove
-any of the files in it.
-
-</P>
-<P>
-You start your favorite editor, hack away at <TT>`backend.c'</TT>, and a couple
-of hours later you have added an optimization pass to the compiler.
-A note to RCS and SCCS users: There is no need to lock the files that
-you want to edit. See section <A HREF="cvs.html#SEC37">Multiple
developers</A> for an explanation.
-
-</P>
-
-
-<H2><A NAME="SEC12" HREF="cvs.html#TOC12">Committing your changes</A></H2>
-<P>
-<A NAME="IDX46"></A>
-<A NAME="IDX47"></A>
-<A NAME="IDX48"></A>
-<A NAME="IDX49"></A>
-
-</P>
-<P>
-When you have checked that the compiler is still compilable you decide
-to make a new version of <TT>`backend.c'</TT>.
-
-</P>
-
-<PRE>
-$ cvs commit backend.c
-</PRE>
-
-<P>
-CVS starts an editor, to allow you to enter a log
-message. You type in "Added an optimization pass.",
-save the temporary file, and exit the editor.
-
-</P>
-<P>
-The environment variable <CODE>$CVSEDITOR</CODE> determines
-which editor is started. If <CODE>$CVSEDITOR</CODE> is not
-set, then if the environment variable <CODE>$EDITOR</CODE> is
-set, it will be used. If both <CODE>$CVSEDITOR</CODE> and
-<CODE>$EDITOR</CODE> are not set then the editor defaults to
-<CODE>vi</CODE>. If you want to avoid the overhead of
-starting an editor you can specify the log message on
-the command line using the <SAMP>`-m'</SAMP> flag instead, like
-this:
-
-</P>
-
-<PRE>
-$ cvs commit -m "Added an optimization pass" backend.c
-</PRE>
-
-
-
-<H2><A NAME="SEC13" HREF="cvs.html#TOC13">Cleaning up</A></H2>
-<P>
-<A NAME="IDX50"></A>
-<A NAME="IDX51"></A>
-<A NAME="IDX52"></A>
-<A NAME="IDX53"></A>
-
-</P>
-<P>
-Before you turn to other tasks you decide to remove your working copy of
-tc. One acceptable way to do that is of course
-
-</P>
-
-<PRE>
-$ cd ..
-$ rm -r tc
-</PRE>
-
-<P>
-but a better way is to use the <CODE>release</CODE> command (see section <A
HREF="cvs.html#SEC122">release--Indicate that a Module is no longer in use</A>):
-
-</P>
-
-<PRE>
-$ cd ..
-$ cvs release -d tc
-M driver.c
-? tc
-You have [1] altered files in this repository.
-Are you sure you want to release (and delete) module `tc': n
-** `release' aborted by user choice.
-</PRE>
-
-<P>
-The <CODE>release</CODE> command checks that all your modifications have been
-committed. If history logging is enabled it also makes a note in the
-history file. See section <A HREF="cvs.html#SEC149">The history file</A>.
-
-</P>
-<P>
-When you use the <SAMP>`-d'</SAMP> flag with <CODE>release</CODE>, it
-also removes your working copy.
-
-</P>
-<P>
-In the example above, the <CODE>release</CODE> command wrote a couple of lines
-of output. <SAMP>`? tc'</SAMP> means that the file <TT>`tc'</TT> is unknown
to CVS.
-That is nothing to worry about: <TT>`tc'</TT> is the executable compiler,
-and it should not be stored in the repository. See section <A
HREF="cvs.html#SEC148">Ignoring files via cvsignore</A>,
-for information about how to make that warning go away.
-See section <A HREF="cvs.html#SEC124">release output</A>, for a complete
explanation of
-all possible output from <CODE>release</CODE>.
-
-</P>
-<P>
-<SAMP>`M driver.c'</SAMP> is more serious. It means that the
-file <TT>`driver.c'</TT> has been modified since it was
-checked out.
-
-</P>
-<P>
-The <CODE>release</CODE> command always finishes by telling
-you how many modified files you have in your working
-copy of the sources, and then asks you for confirmation
-before deleting any files or making any note in the
-history file.
-
-</P>
-<P>
-You decide to play it safe and answer <KBD>n <KBD>RET</KBD></KBD>
-when <CODE>release</CODE> asks for confirmation.
-
-</P>
-
-
-<H2><A NAME="SEC14" HREF="cvs.html#TOC14">Viewing differences</A></H2>
-<P>
-<A NAME="IDX54"></A>
-<A NAME="IDX55"></A>
-
-</P>
-<P>
-You do not remember modifying <TT>`driver.c'</TT>, so you want to see what
-has happened to that file.
-
-</P>
-
-<PRE>
-$ cd tc
-$ cvs diff driver.c
-</PRE>
-
-<P>
-This command runs <CODE>diff</CODE> to compare the version of
<TT>`driver.c'</TT>
-that you checked out with your working copy. When you see the output
-you remember that you added a command line option that enabled the
-optimization pass. You check it in, and release the module.
-
-</P>
-
-<PRE>
-$ cvs commit -m "Added an optimization pass" driver.c
-Checking in driver.c;
-/usr/local/cvsroot/tc/driver.c,v <-- driver.c
-new revision: 1.2; previous revision: 1.1
-done
-$ cd ..
-$ cvs release -d tc
-? tc
-You have [0] altered files in this repository.
-Are you sure you want to release (and delete) module `tc': y
-</PRE>
-
-
-
-<H1><A NAME="SEC15" HREF="cvs.html#TOC15">The Repository</A></H1>
-<P>
-<A NAME="IDX56"></A>
-<A NAME="IDX57"></A>
-<A NAME="IDX58"></A>
-<A NAME="IDX59"></A>
-<A NAME="IDX60"></A>
-<A NAME="IDX61"></A>
-
-</P>
-<P>
-The CVS <EM>repository</EM> stores a complete copy of
-all the files and directories which are under version
-control.
-
-</P>
-<P>
-Normally, you never access any of the files in the
-repository directly. Instead, you use CVS
-commands to get your own copy of the files, and then
-work on that copy. When you've finished a set of
-changes, you check (or <EM>commit</EM>) them back into the
-repository. The repository then contains the changes
-which you have made, as well as recording exactly what
-you changed, when you changed it, and other such
-information.
-
-</P>
-<P>
-<A NAME="IDX62"></A>
-CVS can access a repository by a variety of
-means. It might be on the local computer, or it might
-be on a computer across the room or across the world.
-To distinguish various ways to access a repository, the
-repository name can start with an <EM>access method</EM>.
-For example, the access method <CODE>:local:</CODE> means to
-access a repository directory, so the repository
-<CODE>:local:/usr/local/cvsroot</CODE> means that the
-repository is in <TT>`/usr/local/cvsroot'</TT> on the
-computer running CVS. For information on other
-access methods, see section <A HREF="cvs.html#SEC24">Remote repositories</A>.
-
-</P>
-<P>
-If the access method is omitted, then if the repository
-does not contain <SAMP>`:'</SAMP>, then <CODE>:local:</CODE> is
-assumed. If it does contain <SAMP>`:'</SAMP> than either
-<CODE>:ext:</CODE> or <CODE>:server:</CODE> is assumed. For
-example, if you have a local repository in
-<TT>`/usr/local/cvsroot'</TT>, you can use
-<CODE>/usr/local/cvsroot</CODE> instead of
-<CODE>:local:/usr/local/cvsroot</CODE>. But if (under
-Windows NT, for example) your local repository is
-<TT>`c:\src\cvsroot'</TT>, then you must specify the access
-method, as in <CODE>:local:c:\src\cvsroot</CODE>.
-
-</P>
-<P>
-The repository is split in two parts. <TT>`$CVSROOT/CVSROOT'</TT> contains
-administrative files for CVS. The other directories contain the actual
-user-defined modules.
-
-</P>
-
-
-
-<H2><A NAME="SEC16" HREF="cvs.html#TOC16">Telling CVS where your repository
is</A></H2>
-
-<P>
-There are a couple of different ways to tell CVS
-where to find the repository. You can name the
-repository on the command line explicitly, with the
-<CODE>-d</CODE> (for "directory") option:
-
-</P>
-
-<PRE>
-cvs -d /usr/local/cvsroot checkout yoyodyne/tc
-</PRE>
-
-<P>
-<A NAME="IDX63"></A>
-<A NAME="IDX64"></A>
-<A NAME="IDX65"></A>
-<A NAME="IDX66"></A>
-<A NAME="IDX67"></A>
- Or you can set the <CODE>$CVSROOT</CODE> environment
-variable to an absolute path to the root of the
-repository, <TT>`/usr/local/cvsroot'</TT> in this example.
-To set <CODE>$CVSROOT</CODE>, all <CODE>csh</CODE> and <CODE>tcsh</CODE>
-users should have this line in their <TT>`.cshrc'</TT> or
-<TT>`.tcshrc'</TT> files:
-
-</P>
-
-<PRE>
-setenv CVSROOT /usr/local/cvsroot
-</PRE>
-
-<P>
-<CODE>sh</CODE> and <CODE>bash</CODE> users should instead have these lines in
their
-<TT>`.profile'</TT> or <TT>`.bashrc'</TT>:
-
-</P>
-
-<PRE>
-CVSROOT=/usr/local/cvsroot
-export CVSROOT
-</PRE>
-
-<P>
- A repository specified with <CODE>-d</CODE> will
-override the <CODE>$CVSROOT</CODE> environment variable.
-Once you've checked a working copy out from the
-repository, it will remember where its repository is
-(the information is recorded in the
-<TT>`CVS/Root'</TT> file in the working copy).
-
-</P>
-<P>
-The <CODE>-d</CODE> option and the <TT>`CVS/Root'</TT> file both
-override the <CODE>$CVSROOT</CODE> environment variable. If
-<CODE>-d</CODE> option differs from <TT>`CVS/Root'</TT>, the
-former is used (and specifying <CODE>-d</CODE> will cause
-<TT>`CVS/Root'</TT> to be updated). Of course, for proper
-operation they should be two ways of referring to the
-same repository.
-
-</P>
-
-
-<H2><A NAME="SEC17" HREF="cvs.html#TOC17">How data is stored in the
repository</A></H2>
-<P>
-<A NAME="IDX68"></A>
-
-</P>
-<P>
-For most purposes it isn't important <EM>how</EM>
-CVS stores information in the repository. In
-fact, the format has changed in the past, and is likely
-to change in the future. Since in almost all cases one
-accesses the repository via CVS commands; such
-changes need not be disruptive.
-
-</P>
-<P>
-However, in some cases it may be necessary to
-understand how CVS stores data in the repository,
-for example you might need to track down CVS locks
-(see section <A HREF="cvs.html#SEC42">Several developers simultaneously
attempting to run CVS</A>) or you might need to deal with
-the file permissions appropriate for the repository.
-
-</P>
-
-
-
-<H3><A NAME="SEC18" HREF="cvs.html#TOC18">Where files are stored within the
repository</A></H3>
-
-<P>
-The overall structure of the repository is a directory
-tree corresponding to the directories in the working
-directory. For example, supposing the repository is in
-<TT>`/usr/local/cvsroot'</TT>, here is a possible directory
-tree (showing only the directories):
-
-</P>
-
-<PRE>
-<TT>/usr</TT>
- |
- +--<TT>local</TT>
- | |
- | +--<TT>cvsroot</TT>
- | | |
- | | +--<TT>CVSROOT</TT>
- | (administrative files)
- |
- +--<TT>gnu</TT>
- | |
- | +--<TT>diff</TT>
- | | (source code to GNU diff)
- | |
- | +--<TT>rcs</TT>
- | | (source code to RCS)
- | |
- | +--<TT>cvs</TT>
- | (source code to CVS)
- |
- +--<TT>yoyodyne</TT>
- |
- +--<TT>tc</TT>
- | |
- | +--<TT>man</TT>
- | |
- | +--<TT>testing</TT>
- |
- +--(other Yoyodyne software)
-</PRE>
-
-<P>
-With the directories are <EM>history files</EM> for each file
-under version control. The name of the history file is
-the name of the corresponding file with <SAMP>`,v'</SAMP>
-appended to the end. Here is what the repository for
-the <TT>`yoyodyne/tc'</TT> directory might look like:
-
-</P>
-
-<PRE>
- <CODE>$CVSROOT</CODE>
- |
- +--<TT>yoyodyne</TT>
- | |
- | +--<TT>tc</TT>
- | | |
- +--<TT>Makefile,v</TT>
- +--<TT>backend.c,v</TT>
- +--<TT>driver.c,v</TT>
- +--<TT>frontend.c,v</TT>
- +--<TT>parser.c,v</TT>
- +--<TT>man</TT>
- | |
- | +--<TT>tc.1,v</TT>
- |
- +--<TT>testing</TT>
- |
- +--<TT>testpgm.t,v</TT>
- +--<TT>test2.t,v</TT>
-</PRE>
-
-<P>
-<A NAME="IDX69"></A>
-<A NAME="IDX70"></A>
-The history files contain, among other things, enough
-information to recreate any revision of the file, a log
-of all commit messages and the user-name of the person
-who committed the revision. The history files are
-known as <EM>RCS files</EM>, because the first program to
-store files in that format was a version control system
-known as RCS. For a full
-description of the file format, see the <CODE>man</CODE> page
-<CITE>rcsfile(5)</CITE>, distributed with RCS. This
-file format has become very common--many systems other
-than CVS or RCS can at least import history
-files in this format.
-
-</P>
-
-
-<H3><A NAME="SEC19" HREF="cvs.html#TOC19">File permissions</A></H3>
-<P>
-<A NAME="IDX71"></A>
-<A NAME="IDX72"></A>
-<A NAME="IDX73"></A>
-<A NAME="IDX74"></A>
-All <SAMP>`,v'</SAMP> files are created read-only, and you
-should not change the permission of those files. The
-directories inside the repository should be writable by
-the persons that have permission to modify the files in
-each directory. This normally means that you must
-create a Unix group (see group(5)) consisting of the
-persons that are to edit the files in a project, and
-set up the repository so that it is that group that
-owns the directory.
-
-</P>
-<P>
-This means that you can only control access to files on
-a per-directory basis.
-
-</P>
-<P>
-Note that users must also have write access to check
-out files, because CVS needs to create lock files
-(see section <A HREF="cvs.html#SEC42">Several developers simultaneously
attempting to run CVS</A>).
-
-</P>
-<P>
-Also note that users must have write access to the
-<TT>`CVSROOT/val-tags'</TT> file. CVS uses it to keep
-track of what tags are valid tag names (it is sometimes
-updated when tags are used, as well as when they are
-created, though).
-
-</P>
-<P>
-<A NAME="IDX75"></A>
-<A NAME="IDX76"></A>
-CVS tries to set up reasonable file permissions
-for new directories that are added inside the tree, but
-you must fix the permissions manually when a new
-directory should have different permissions than its
-parent directory. If you set the <CODE>CVSUMASK</CODE>
-environment variable that will control the file
-permissions which CVS uses in creating directories
-and/or files in the repository. <CODE>CVSUMASK</CODE> does
-not affect the file permissions in the working
-directory; such files have the permissions which are
-typical for newly created files, except that sometimes
-CVS creates them read-only (see the sections on
-watches, section <A HREF="cvs.html#SEC44">Telling CVS to watch certain
files</A>; -r, section <A HREF="cvs.html#SEC89">Global options</A>; or CVSREAD,
section <A HREF="cvs.html#SEC151">All environment variables which affect
CVS</A>).
-
-</P>
-<P>
-<A NAME="IDX77"></A>
-<A NAME="IDX78"></A>
-Since CVS was not written to be run setuid, it is
-unsafe to try to run it setuid. You cannot use the
-setuid features of RCS together with CVS.
-
-</P>
-
-
-<H2><A NAME="SEC20" HREF="cvs.html#TOC20">The administrative files</A></H2>
-<P>
-<A NAME="IDX79"></A>
-<A NAME="IDX80"></A>
-<A NAME="IDX81"></A>
-<A NAME="IDX82"></A>
-
-</P>
-
-<P>
-The directory <TT>`$CVSROOT/CVSROOT'</TT> contains some <EM>administrative
-files</EM>. See section <A HREF="cvs.html#SEC136">Reference manual for the
Administrative files</A>, for a complete description.
-You can use CVS without any of these files, but
-some commands work better when at least the
-<TT>`modules'</TT> file is properly set up.
-
-</P>
-<P>
-The most important of these files is the <TT>`modules'</TT>
-file. It defines all modules in the repository. This
-is a sample <TT>`modules'</TT> file.
-
-</P>
-
-<PRE>
-CVSROOT CVSROOT
-modules CVSROOT modules
-cvs gnu/cvs
-rcs gnu/rcs
-diff gnu/diff
-tc yoyodyne/tc
-</PRE>
-
-<P>
-The <TT>`modules'</TT> file is line oriented. In its
-simplest form each line contains the name of the
-module, whitespace, and the directory where the module
-resides. The directory is a path relative to
-<CODE>$CVSROOT</CODE>. The last four lines in the example
-above are examples of such lines.
-
-</P>
-
-<P>
-The line that defines the module called <SAMP>`modules'</SAMP>
-uses features that are not explained here.
-See section <A HREF="cvs.html#SEC137">The modules file</A>, for a full
explanation of all the
-available features.
-
-</P>
-
-
-<H3><A NAME="SEC21" HREF="cvs.html#TOC21">Editing administrative files</A></H3>
-<P>
-<A NAME="IDX83"></A>
-<A NAME="IDX84"></A>
-
-</P>
-<P>
-You edit the administrative files in the same way that you would edit
-any other module. Use <SAMP>`cvs checkout CVSROOT'</SAMP> to get a working
-copy, edit it, and commit your changes in the normal way.
-
-</P>
-<P>
-It is possible to commit an erroneous administrative
-file. You can often fix the error and check in a new
-revision, but sometimes a particularly bad error in the
-administrative file makes it impossible to commit new
-revisions.
-
-</P>
-
-
-<H2><A NAME="SEC22" HREF="cvs.html#TOC22">Multiple repositories</A></H2>
-<P>
-<A NAME="IDX85"></A>
-<A NAME="IDX86"></A>
-<A NAME="IDX87"></A>
-<A NAME="IDX88"></A>
-<A NAME="IDX89"></A>
-<A NAME="IDX90"></A>
-
-</P>
-<P>
-In some situations it is a good idea to have more than
-one repository, for instance if you have two
-development groups that work on separate projects
-without sharing any code. All you have to do to have
-several repositories is to specify the appropriate
-repository, using the <CODE>CVSROOT</CODE> environment
-variable, the <SAMP>`-d'</SAMP> option to CVS, or (once
-you have checked out a working directory) by simply
-allowing CVS to use the repository that was used
-to check out the working directory
-(see section <A HREF="cvs.html#SEC16">Telling CVS where your repository
is</A>).
-
-</P>
-<P>
-The big advantage of having multiple repositories is
-that they can reside on different servers. The big
-disadvantage is that you cannot have a single CVS
-command recurse into directories which comes from
-different repositories. Generally speaking, if you are
-thinking of setting up several repositories on the same
-machine, you might want to consider using several
-directories within the same repository.
-
-</P>
-<P>
-None of the examples in this manual show multiple
-repositories.
-
-</P>
-
-
-<H2><A NAME="SEC23" HREF="cvs.html#TOC23">Creating a repository</A></H2>
-
-<P>
-<A NAME="IDX91"></A>
-<A NAME="IDX92"></A>
-<A NAME="IDX93"></A>
-
-</P>
-<P>
-To set up a CVS repository, choose a directory
-with ample disk space available for the revision
-history of the source files. It should be accessable
-(directly or via a networked file system) from all
-machines which want to use CVS in server or local
-mode; the client machines need not have any access to
-it other than via the CVS protocol. It is not
-possible to use CVS to read from a repository
-which one only has read access to; CVS needs to be
-able to create lock files (see section <A HREF="cvs.html#SEC42">Several
developers simultaneously attempting to run CVS</A>).
-
-</P>
-<P>
-<A NAME="IDX94"></A>
-To create a repository, run the <CODE>cvs init</CODE>
-command. It will set up an empty repository in the
-CVS root specified in the usual way
-(see section <A HREF="cvs.html#SEC15">The Repository</A>). For example,
-
-</P>
-
-<PRE>
-cvs -d /usr/local/cvsroot init
-</PRE>
-
-<P>
-<CODE>cvs init</CODE> is careful to never overwrite any
-existing files in the repository, so no harm is done if
-you run <CODE>cvs init</CODE> on an already set-up
-repository.
-
-</P>
-<P>
-<CODE>cvs init</CODE> will enable history logging; if you
-don't want that, remove the history file after running
-<CODE>cvs init</CODE>. See section <A HREF="cvs.html#SEC149">The history
file</A>.
-
-</P>
-
-
-<H2><A NAME="SEC24" HREF="cvs.html#TOC24">Remote repositories</A></H2>
-<P>
-<A NAME="IDX95"></A>
-<A NAME="IDX96"></A>
-<A NAME="IDX97"></A>
-
-</P>
-<P>
- Your working copy of the sources can be on a
-different machine than the repository. Generally,
-using a remote repository is just like using a local
-one, except that the format of the repository name is:
-
-</P>
-
-<PRE>
-:<VAR>method</VAR>:<VAR>user</VAR>@<VAR>hostname</VAR>:/path/to/repository
-</PRE>
-
-<P>
-The details of exactly what needs to be set up depend
-on how you are connecting to the server.
-
-</P>
-<P>
-If <VAR>method</VAR> is not specified, and the repository
-name contains <SAMP>`:'</SAMP>, then the default is <CODE>ext</CODE>
-or <CODE>server</CODE>, depending on your platform; both are
-described in section <A HREF="cvs.html#SEC25">Connecting with rsh</A>.
-
-</P>
-
-
-
-<H3><A NAME="SEC25" HREF="cvs.html#TOC25">Connecting with rsh</A></H3>
-
-<P>
-<A NAME="IDX98"></A>
-CVS uses the <TT>`rsh'</TT> protocol to perform these
-operations, so the remote user host needs to have a
-<TT>`.rhosts'</TT> file which grants access to the local
-user.
-
-</P>
-<P>
-For example, suppose you are the user <TT>`mozart'</TT> on
-the local machine <TT>`anklet.grunge.com'</TT>, and the
-server machine is <TT>`chainsaw.brickyard.com'</TT>. On
-chainsaw, put the following line into the file
-<TT>`.rhosts'</TT> in <TT>`bach'</TT>'s home directory:
-
-</P>
-
-<PRE>
-anklet.grunge.com mozart
-</PRE>
-
-<P>
-Then test that <CODE>rsh</CODE> is working with
-
-</P>
-
-<PRE>
-rsh -l bach chainsaw.brickyard.com 'echo $PATH'
-</PRE>
-
-<P>
-<A NAME="IDX99"></A>
-Next you have to make sure that <CODE>rsh</CODE> will be able
-to find the server. Make sure that the path which
-<CODE>rsh</CODE> printed in the above example includes the
-directory containing a program named <CODE>cvs</CODE> which
-is the server. You need to set the path in
-<TT>`.bashrc'</TT>, <TT>`.cshrc'</TT>, etc., not <TT>`.login'</TT>
-or <TT>`.profile'</TT>. Alternately, you can set the
-environment variable <CODE>CVS_SERVER</CODE> on the client
-machine to the filename of the server you want to use,
-for example <TT>`/usr/local/bin/cvs-1.6'</TT>.
-
-</P>
-<P>
-There is no need to edit <CODE>inetd.conf</CODE> or start a
-CVS server daemon.
-
-</P>
-<P>
-<A NAME="IDX100"></A>
-<A NAME="IDX101"></A>
-There are two access methods that you use in CVSROOT
-for rsh. <CODE>:server:</CODE> specifies an internal rsh
-client, which is supported only by some CVS ports.
-<CODE>:ext:</CODE> specifies an external rsh program. By
-default this is <CODE>rsh</CODE> but you may set the
-<CODE>CVS_RSH</CODE> environment variable to invoke another
-program which can access the remote server (for
-example, <CODE>remsh</CODE> on HP-UX 9 because <CODE>rsh</CODE> is
-something different). It must be a program which can
-transmit data to and from the server without modifying
-it; for example the Windows NT <CODE>rsh</CODE> is not
-suitable since it by default translates between CRLF
-and LF. The OS/2 CVS port has a hack to pass <SAMP>`-b'</SAMP>
-to <CODE>rsh</CODE> to get around this, but since this could
-potentially cause programs for programs other than the
-standard <CODE>rsh</CODE>, it may change in the future. If
-you set <CODE>CVS_RSH</CODE> to <CODE>SSH</CODE> or some other rsh
-replacement, the instructions in the rest of this
-section concerning <TT>`.rhosts'</TT> and so on are likely
-to be incorrect; consult the documentation for your rsh
-replacement.
-
-</P>
-<P>
-Continuing our example, supposing you want to access
-the module <TT>`foo'</TT> in the repository
-<TT>`/usr/local/cvsroot/'</TT>, on machine
-<TT>`chainsaw.brickyard.com'</TT>, you are ready to go:
-
-</P>
-
-<PRE>
-cvs -d :ext:address@hidden:/usr/local/cvsroot checkout foo
-</PRE>
-
-<P>
-(The <TT>`bach@'</TT> can be omitted if the username is
-the same on both the local and remote hosts.)
-
-</P>
-
-
-
-<H3><A NAME="SEC26" HREF="cvs.html#TOC26">Direct connection with password
authentication</A></H3>
-
-<P>
-The CVS client can also connect to the server
-using a password protocol. This is particularly useful
-if using <CODE>rsh</CODE> is not feasible (for example,
-the server is behind a firewall), and Kerberos also is
-not available.
-
-</P>
-<P>
- To use this method, it is necessary to make
-some adjustments on both the server and client sides.
-
-</P>
-
-
-
-<H4><A NAME="SEC27" HREF="cvs.html#TOC27">Setting up the server for password
authentication</A></H4>
-
-<P>
-<A NAME="IDX102"></A>
-<A NAME="IDX103"></A>
-<A NAME="IDX104"></A>
-On the server side, the file <TT>`/etc/inetd.conf'</TT>
-needs to be edited so <CODE>inetd</CODE> knows to run the
-command <CODE>cvs pserver</CODE> when it receives a
-connection on the right port. By default, the port
-number is 2401; it would be different if your client
-were compiled with <CODE>CVS_AUTH_PORT</CODE> defined to
-something else, though.
-
-</P>
-<P>
- If your <CODE>inetd</CODE> allows raw port numbers in
-<TT>`/etc/inetd.conf'</TT>, then the following (all on a
-single line in <TT>`inetd.conf'</TT>) should be sufficient:
-
-</P>
-
-<PRE>
-2401 stream tcp nowait root /usr/local/bin/cvs
-cvs -b /usr/local/bin pserver
-</PRE>
-
-<P>
-The <SAMP>`-b'</SAMP> option specifies the directory which contains
-the RCS binaries on the server. You could also use the
-<SAMP>`-T'</SAMP> option to specify a temporary directory.
-
-</P>
-<P>
- If your <CODE>inetd</CODE> wants a symbolic service
-name instead of a raw port number, then put this in
-<TT>`/etc/services'</TT>:
-
-</P>
-
-<PRE>
-cvspserver 2401/tcp
-</PRE>
-
-<P>
- and put <CODE>cvspserver</CODE> instead of
-<CODE>2401</CODE> in <TT>`inetd.conf'</TT>.
-
-</P>
-<P>
- Once the above is taken care of, restart your
-<CODE>inetd</CODE>, or do whatever is necessary to force it
-to reread its initialization files.
-
-</P>
-
-<P>
-<A NAME="IDX105"></A>
-<A NAME="IDX106"></A>
-Because the client stores and transmits passwords in
-cleartext (almost--see section <A HREF="cvs.html#SEC29">Security
considerations with password authentication</A> for details), a separate CVS
password
-file may be used, so people don't compromise their
-regular passwords when they access the repository.
-This file is <TT>`$CVSROOT/CVSROOT/passwd'</TT>
-(see section <A HREF="cvs.html#SEC20">The administrative files</A>). Its
format is
-similar to <TT>`/etc/passwd'</TT>, except that it only has
-two fields, username and password. For example:
-
-</P>
-
-<PRE>
-bach:ULtgRLXo7NRxs
-cwang:1sOp854gDF3DY
-</PRE>
-
-<P>
-The password is encrypted according to the standard
-Unix <CODE>crypt()</CODE> function, so it is possible to
-paste in passwords directly from regular Unix
-<TT>`passwd'</TT> files.
-
-</P>
-<P>
-When authenticating a password, the server first checks
-for the user in the CVS <TT>`passwd'</TT> file. If it
-finds the user, it compares against that password. If
-it does not find the user, or if the CVS
-<TT>`passwd'</TT> file does not exist, then the server
-tries to match the password using the system's
-user-lookup routine. When using the CVS
-<TT>`passwd'</TT> file, the server runs under as the
-username specified in the the third argument in the
-entry, or as the first argument if there is no third
-argument (in this way CVS allows imaginary
-usernames provided the CVS <TT>`passwd'</TT> file
-indicates corresponding valid system usernames). In
-any case, CVS will have no privileges which the
-(valid) user would not have.
-
-</P>
-<P>
-Right now, the only way to put a password in the
-CVS <TT>`passwd'</TT> file is to paste it there from
-somewhere else. Someday, there may be a <CODE>cvs
-passwd</CODE> command.
-
-</P>
-
-
-<H4><A NAME="SEC28" HREF="cvs.html#TOC28">Using the client with password
authentication</A></H4>
-<P>
-<A NAME="IDX107"></A>
-<A NAME="IDX108"></A>
-<A NAME="IDX109"></A>
-<A NAME="IDX110"></A>
-Before connecting to the server, the client must <EM>log
-in</EM> with the command <CODE>cvs login</CODE>. Logging in
-verifies a password with the server, and also records
-the password for later transactions with the server.
-The <CODE>cvs login</CODE> command needs to know the
-username, server hostname, and full repository path,
-and it gets this information from the repository
-argument or the <CODE>CVSROOT</CODE> environment variable.
-
-</P>
-<P>
-<CODE>cvs login</CODE> is interactive -- it prompts for a
-password:
-
-</P>
-
-<PRE>
-cvs -d :pserver:address@hidden:/usr/local/cvsroot login
-CVS password:
-</PRE>
-
-<P>
-The password is checked with the server; if it is
-correct, the <CODE>login</CODE> succeeds, else it fails,
-complaining that the password was incorrect.
-
-</P>
-<P>
-Once you have logged in, you can force CVS to
-connect directly to the server and authenticate with
-the stored password:
-
-</P>
-
-<PRE>
-cvs -d :pserver:address@hidden:/usr/local/cvsroot checkout foo
-</PRE>
-
-<P>
-The <SAMP>`:pserver:'</SAMP> is necessary because without it,
-CVS will assume it should use <CODE>rsh</CODE> to
-connect with the server (see section <A HREF="cvs.html#SEC25">Connecting with
rsh</A>).
-(Once you have a working copy checked out and are
-running CVS commands from within it, there is no
-longer any need to specify the repository explicitly,
-because CVS records it in the working copy's
-<TT>`CVS'</TT> subdirectory.)
-
-</P>
-<P>
-<A NAME="IDX111"></A>
-Passwords are stored by default in the file
-<TT>`$HOME/.cvspass'</TT>. Its format is human-readable,
-but don't edit it unless you know what you are doing.
-The passwords are not stored in cleartext, but are
-trivially encoded to protect them from "innocent"
-compromise (i.e., inadvertently being seen by a system
-administrator who happens to look at that file).
-
-</P>
-<P>
-The <CODE>CVS_PASSFILE</CODE> environment variable overrides
-this default. If you use this variable, make sure you
-set it <EM>before</EM> <CODE>cvs login</CODE> is run. If you
-were to set it after running <CODE>cvs login</CODE>, then
-later CVS commands would be unable to look up the
-password for transmission to the server.
-
-</P>
-<P>
-<A NAME="IDX112"></A>
-The <CODE>CVS_PASSWORD</CODE> environment variable overrides
-<EM>all</EM> stored passwords. If it is set, CVS
-will use it for all password-authenticated
-connections.
-
-</P>
-
-
-<H4><A NAME="SEC29" HREF="cvs.html#TOC29">Security considerations with
password authentication</A></H4>
-
-<P>
-The passwords are stored on the client side in a
-trivial encoding of the cleartext, and transmitted in
-the same encoding. The encoding is done only to
-prevent inadvertent password compromises (i.e., a
-system administrator accidentally looking at the file),
-and will not prevent even a naive attacker from gaining
-the password.
-
-</P>
-<P>
-The separate CVS password file (see section <A HREF="cvs.html#SEC27">Setting
up the server for password authentication</A>) allows people
-to use a different password for repository access than
-for login access. On the other hand, once a user has
-access to the repository, she can execute programs on
-the server system through a variety of means. Thus, repository
-access implies fairly broad system access as well. It
-might be possible to modify CVS to prevent that,
-but no one has done so as of this writing.
-Furthermore, there may be other ways in which having
-access to CVS allows people to gain more general
-access to the system; noone has done a careful audit.
-
-</P>
-<P>
-In summary, anyone who gets the password gets
-repository access, and some measure of general system
-access as well. The password is available to anyone
-who can sniff network packets or read a protected
-(i.e., user read-only) file. If you want real
-security, get Kerberos.
-
-</P>
-
-
-<H3><A NAME="SEC30" HREF="cvs.html#TOC30">Direct connection with
kerberos</A></H3>
-
-<P>
-<A NAME="IDX113"></A>
-<A NAME="IDX114"></A>
-The main disadvantage of using rsh is that all the data
-needs to pass through additional programs, so it may be
-slower. So if you have kerberos installed you can
-connect via a direct TCP connection,
-authenticating with kerberos.
-
-</P>
-<P>
-To do this, CVS needs to be compiled with kerberos
-support; when configuring CVS it tries to detect
-whether kerberos is present or you can use the
-<TT>`--with-krb4'</TT> flag to configure.
-
-</P>
-<P>
-The data transmitted is <EM>not</EM> encrypted by
-default. Encryption support must be compiled into both
-the client and server; use the
-<TT>`--enable-encryption'</TT> configure option to turn it
-on. You must then use the <CODE>-x</CODE> global option to
-request encryption.
-
-</P>
-<P>
-<A NAME="IDX115"></A>
-You need to edit <CODE>inetd.conf</CODE> on the server
-machine to run <CODE>cvs kserver</CODE>. The client uses
-port 1999 by default; if you want to use another port
-specify it in the <CODE>CVS_CLIENT_PORT</CODE> environment
-variable on the client.
-
-</P>
-<P>
-<A NAME="IDX116"></A>
-When you want to use CVS, get a ticket in the
-usual way (generally <CODE>kinit</CODE>); it must be a ticket
-which allows you to log into the server machine. Then
-you are ready to go:
-
-</P>
-
-<PRE>
-cvs -d :kserver:chainsaw.brickyard.com:/user/local/cvsroot checkout foo
-</PRE>
-
-<P>
-Previous versions of CVS would fall back to a
-connection via rsh; this version will not do so.
-
-</P>
-
-
-<H1><A NAME="SEC31" HREF="cvs.html#TOC31">Starting a project with CVS</A></H1>
-<P>
-<A NAME="IDX117"></A>
-<A NAME="IDX118"></A>
-
-</P>
-<P>
-Because renaming files and moving them between
-directories is somewhat inconvenient, the first thing
-you do when you start a new project should be to think
-through your file organization. It is not impossible
-to rename or move files, but it does increase the
-potential for confusion and CVS does have some
-quirks particularly in the area of renaming
-directories. See section <A HREF="cvs.html#SEC67">Moving and renaming
files</A>.
-
-</P>
-<P>
-What to do next depends on the situation at hand.
-
-</P>
-
-
-
-<H2><A NAME="SEC32" HREF="cvs.html#TOC32">Setting up the files</A></H2>
-
-<P>
-The first step is to create the files inside the repository. This can
-be done in a couple of different ways.
-
-</P>
-
-
-
-<H3><A NAME="SEC33" HREF="cvs.html#TOC33">Creating a directory tree from a
number of files</A></H3>
-<P>
-<A NAME="IDX119"></A>
-
-</P>
-<P>
-When you begin using CVS, you will probably already have several
-projects that can be
-put under CVS control. In these cases the easiest way is to use the
-<CODE>import</CODE> command. An example is probably the easiest way to
-explain how to use it. If the files you want to install in
-CVS reside in <TT>`<VAR>wdir</VAR>'</TT>, and you want them to appear in the
-repository as <TT>`$CVSROOT/yoyodyne/<VAR>rdir</VAR>'</TT>, you can do this:
-
-</P>
-
-<PRE>
-$ cd <VAR>wdir</VAR>
-$ cvs import -m "Imported sources" yoyodyne/<VAR>rdir</VAR> yoyo start
-</PRE>
-
-<P>
-Unless you supply a log message with the <SAMP>`-m'</SAMP>
-flag, CVS starts an editor and prompts for a
-message. The string <SAMP>`yoyo'</SAMP> is a <EM>vendor tag</EM>,
-and <SAMP>`start'</SAMP> is a <EM>release tag</EM>. They may fill
-no purpose in this context, but since CVS requires
-them they must be present. See section <A HREF="cvs.html#SEC63">Tracking
third-party sources</A>, for
-more information about them.
-
-</P>
-<P>
-You can now verify that it worked, and remove your
-original source directory.
-
-</P>
-
-<PRE>
-$ cd ..
-$ mv <VAR>dir</VAR> <VAR>dir</VAR>.orig
-$ cvs checkout yoyodyne/<VAR>dir</VAR> # Explanation below
-$ ls -R yoyodyne
-$ rm -r <VAR>dir</VAR>.orig
-</PRE>
-
-<P>
-Erasing the original sources is a good idea, to make sure that you do
-not accidentally edit them in <VAR>dir</VAR>, bypassing CVS.
-Of course, it would be wise to make sure that you have
-a backup of the sources before you remove them.
-
-</P>
-<P>
-The <CODE>checkout</CODE> command can either take a module
-name as argument (as it has done in all previous
-examples) or a path name relative to <CODE>$CVSROOT</CODE>,
-as it did in the example above.
-
-</P>
-<P>
-It is a good idea to check that the permissions
-CVS sets on the directories inside <SAMP>`$CVSROOT'</SAMP>
-are reasonable, and that they belong to the proper
-groups. See section <A HREF="cvs.html#SEC19">File permissions</A>.
-
-</P>
-<P>
-If some of the files you want to import are binary, you
-may want to use the wrappers features to specify which
-files are binary and which are not. See section <A HREF="cvs.html#SEC138">The
cvswrappers file</A>.
-
-</P>
-
-
-<H3><A NAME="SEC34" HREF="cvs.html#TOC34">Creating Files From Other Version
Control Systems</A></H3>
-<P>
-<A NAME="IDX120"></A>
-
-</P>
-<P>
-If you have a project which you are maintaining with
-another version control system, such as RCS, you
-may wish to put the files from that project into
-CVS, and preserve the revision history of the
-files.
-
-</P>
-<DL COMPACT>
-
-<DT>From RCS
-<DD>
-<A NAME="IDX121"></A>
-
-If you have been using RCS, find the RCS
-files--usually a file named <TT>`foo.c'</TT> will have its
-RCS file in <TT>`RCS/foo.c,v'</TT> (but it could be
-other places; consult the RCS documentation for
-details). Then create the appropriate directories in
-CVS if they do not already exist. Then copy the
-files into the appropriate directories in the CVS
-repository (the name in the repository must be the name
-of the source file with <SAMP>`,v'</SAMP> added; the files go
-directly in the appopriate directory of the repository,
-not in an <TT>`RCS'</TT> subdirectory). This is one of the
-few times when it is a good idea to access the CVS
-repository directly, rather than using CVS
-commands. Then you are ready to check out a new
-working directory.
-
-The RCS file should not be locked when you move it
-into CVS; if it is, CVS will have trouble
-letting you operate on it.
-
-<DT>From another version control system
-<DD>
-Many version control systems have the ability to export
-RCS files in the standard format. If yours does,
-export the RCS files and then follow the above
-instructions.
-
-<A NAME="IDX122"></A>
-<DT>From SCCS
-<DD>
-There is a script in the <TT>`contrib'</TT> directory of
-the CVS source distribution called <TT>`sccs2rcs'</TT>
-which converts SCCS files to RCS files.
-Note: you must run it on a machine which has both
-SCCS and RCS installed, and like everything
-else in contrib it is unsupported (your mileage may
-vary).
-</DL>
-
-
-
-<H3><A NAME="SEC35" HREF="cvs.html#TOC35">Creating a directory tree from
scratch</A></H3>
-
-<P>
-For a new project, the easiest thing to do is probably
-to create an empty directory structure, like this:
-
-</P>
-
-<PRE>
-$ mkdir tc
-$ mkdir tc/man
-$ mkdir tc/testing
-</PRE>
-
-<P>
-After that, you use the <CODE>import</CODE> command to create
-the corresponding (empty) directory structure inside
-the repository:
-
-</P>
-
-<PRE>
-$ cd tc
-$ cvs import -m "Created directory structure" yoyodyne/<VAR>dir</VAR> yoyo
start
-</PRE>
-
-<P>
-Then, use <CODE>add</CODE> to add files (and new directories)
-as they appear.
-
-</P>
-<P>
-Check that the permissions CVS sets on the
-directories inside <SAMP>`$CVSROOT'</SAMP> are reasonable.
-
-</P>
-
-
-<H2><A NAME="SEC36" HREF="cvs.html#TOC36">Defining the module</A></H2>
-<P>
-<A NAME="IDX123"></A>
-<A NAME="IDX124"></A>
-<A NAME="IDX125"></A>
-<A NAME="IDX126"></A>
-
-</P>
-<P>
-The next step is to define the module in the
-<TT>`modules'</TT> file. This is not strictly necessary,
-but modules can be convenient in grouping together
-related files and directories.
-
-</P>
-<P>
-In simple cases these steps are sufficient to define a module.
-
-</P>
-
-<OL>
-<LI>
-
-Get a working copy of the modules file.
-
-
-<PRE>
-$ cvs checkout CVSROOT/modules
-$ cd CVSROOT
-</PRE>
-
-<LI>
-
-Edit the file and insert a line that defines the module. See section <A
HREF="cvs.html#SEC20">The administrative files</A>, for an introduction. See
section <A HREF="cvs.html#SEC137">The modules file</A>, for a full
-description of the modules file. You can use the
-following line to define the module <SAMP>`tc'</SAMP>:
-
-
-<PRE>
-tc yoyodyne/tc
-</PRE>
-
-<LI>
-
-Commit your changes to the modules file.
-
-
-<PRE>
-$ cvs commit -m "Added the tc module." modules
-</PRE>
-
-<LI>
-
-Release the modules module.
-
-
-<PRE>
-$ cd ..
-$ cvs release -d CVSROOT
-</PRE>
-
-</OL>
-
-
-
-<H1><A NAME="SEC37" HREF="cvs.html#TOC37">Multiple developers</A></H1>
-<P>
-<A NAME="IDX127"></A>
-<A NAME="IDX128"></A>
-<A NAME="IDX129"></A>
-<A NAME="IDX130"></A>
-<A NAME="IDX131"></A>
-<A NAME="IDX132"></A>
-<A NAME="IDX133"></A>
-<A NAME="IDX134"></A>
-
-</P>
-<P>
-When more than one person works on a software project
-things often get complicated. Often, two people try to
-edit the same file simultaneously. One solution, known
-as <EM>file locking</EM> or <EM>reserved checkouts</EM>, is
-to allow only one person to edit each file at a time.
-This is the only solution with some version control
-systems, including RCS and SCCS. CVS
-doesn't have a very nice implementation of reserved
-checkouts (yet) but there are ways to get it working
-(for example, see the <CODE>cvs admin -l</CODE> command in
-section <A HREF="cvs.html#SEC92">admin options</A>). It also may be possible
to use
-the watches features described below, together with
-suitable procedures (not enforced by software), to
-avoid having two people edit at the same time.
-
-</P>
-<P>
-The default model with CVS is known as
-<EM>unreserved checkouts</EM>. In this model, developers
-can edit their own <EM>working copy</EM> of a file
-simultaneously. The first person that commits his
-changes has no automatic way of knowing that another
-has started to edit it. Others will get an error
-message when they try to commit the file. They must
-then use CVS commands to bring their working copy
-up to date with the repository revision. This process
-is almost automatic.
-
-</P>
-<P>
-CVS also supports mechanisms which facilitate
-various kinds of communcation, without actually
-enforcing rules like reserved checkouts do.
-
-</P>
-<P>
-The rest of this chapter describes how these various
-models work, and some of the issues involved in
-choosing between them.
-
-</P>
-
-
-
-<H2><A NAME="SEC38" HREF="cvs.html#TOC38">File status</A></H2>
-<P>
-<A NAME="IDX135"></A>
-<A NAME="IDX136"></A>
-
-</P>
-<P>
-Based on what operations you have performed on a
-checked out file, and what operations others have
-performed to that file in the repository, one can
-classify a file in a number of states. The states, as
-reported by the <CODE>status</CODE> command, are:
-
-</P>
-<DL COMPACT>
-
-<DT>Up-to-date
-<DD>
-<A NAME="IDX137"></A>
-
-The file is identical with the latest revision in the
-repository for the branch in use.
-
-<DT>Locally Modified
-<DD>
-<A NAME="IDX138"></A>
-You have edited the file, and not yet committed your changes.
-
-<DT>Locally Added
-<DD>
-<A NAME="IDX139"></A>
-You have added the file with <CODE>add</CODE>, and not yet
-committed your changes.
-
-<DT>Locally Removed
-<DD>
-<A NAME="IDX140"></A>
-You have removed the file with <CODE>remove</CODE>, and not yet
-committed your changes.
-
-<DT>Needs Checkout
-<DD>
-<A NAME="IDX141"></A>
-Someone else has committed a newer revision to the
-repository. The name is slightly misleading; you will
-ordinarily use <CODE>update</CODE> rather than
-<CODE>checkout</CODE> to get that newer revision.
-
-<DT>Needs Patch
-<DD>
-<A NAME="IDX142"></A>
-Like Needs Checkout, but the CVS server will send
-a patch rather than the entire file. Sending a patch or
-sending an entire file accomplishes the same thing.
-
-<DT>Needs Merge
-<DD>
-<A NAME="IDX143"></A>
-Someone else has committed a newer revision to the repository, and you
-have also made modifications to the file.
-
-<DT>Unresolved Conflict
-<DD>
-<A NAME="IDX144"></A>
-This is like Locally Modified, except that a previous
-<CODE>update</CODE> command gave a conflict. You need to
-resolve the conflict as described in section <A
HREF="cvs.html#SEC40">Conflicts example</A>.
-
-<DT>Unknown
-<DD>
-<A NAME="IDX145"></A>
-CVS doesn't know anything about this file. For
-example, you have created a new file and have not run
-<CODE>add</CODE>.
-
-</DL>
-
-<P>
-To help clarify the file status, <CODE>status</CODE> also
-reports the <CODE>Working revision</CODE> which is the
-revision that the file in the working directory derives
-from, and the <CODE>Repository revision</CODE> which is the
-latest revision in the repository for the branch in
-use.
-
-</P>
-<P>
-For information on the options to <CODE>status</CODE>, see
-section <A HREF="cvs.html#SEC128">status--Display status information on
checked out files</A>. For information on its <CODE>Sticky tag</CODE>
-and <CODE>Sticky date</CODE> output, see section <A
HREF="cvs.html#SEC54">Sticky tags</A>.
-For information on its <CODE>Sticky options</CODE> output,
-see the <SAMP>`-k'</SAMP> option in section <A HREF="cvs.html#SEC133">update
options</A>.
-
-</P>
-
-
-<H2><A NAME="SEC39" HREF="cvs.html#TOC39">Bringing a file up to date</A></H2>
-<P>
-<A NAME="IDX146"></A>
-<A NAME="IDX147"></A>
-<A NAME="IDX148"></A>
-<A NAME="IDX149"></A>
-
-</P>
-<P>
-When you want to update or merge a file, use the <CODE>update</CODE>
-command. For files that are not up to date this is roughly equivalent
-to a <CODE>checkout</CODE> command: the newest revision of the file is
-extracted from the repository and put in your working copy of the
-module.
-
-</P>
-<P>
-Your modifications to a file are never lost when you
-use <CODE>update</CODE>. If no newer revision exists,
-running <CODE>update</CODE> has no effect. If you have
-edited the file, and a newer revision is available,
-CVS will merge all changes into your working copy.
-
-</P>
-<P>
-For instance, imagine that you checked out revision 1.4 and started
-editing it. In the meantime someone else committed revision 1.5, and
-shortly after that revision 1.6. If you run <CODE>update</CODE> on the file
-now, CVS will incorporate all changes between revision 1.4 and 1.6 into
-your file.
-
-</P>
-<P>
-<A NAME="IDX150"></A>
-If any of the changes between 1.4 and 1.6 were made too
-close to any of the changes you have made, an
-<EM>overlap</EM> occurs. In such cases a warning is
-printed, and the resulting file includes both
-versions of the lines that overlap, delimited by
-special markers.
-See section <A HREF="cvs.html#SEC132">update--Bring work tree in sync with
repository</A>, for a complete description of the
-<CODE>update</CODE> command.
-
-</P>
-
-
-<H2><A NAME="SEC40" HREF="cvs.html#TOC40">Conflicts example</A></H2>
-<P>
-<A NAME="IDX151"></A>
-<A NAME="IDX152"></A>
-<A NAME="IDX153"></A>
-
-</P>
-<P>
-Suppose revision 1.4 of <TT>`driver.c'</TT> contains this:
-
-</P>
-
-<PRE>
-#include <stdio.h>
-
-void main()
-{
- parse();
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? 0 : 1);
-}
-</PRE>
-
-<P>
-Revision 1.6 of <TT>`driver.c'</TT> contains this:
-
-</P>
-
-<PRE>
-#include <stdio.h>
-
-int main(int argc,
- char **argv)
-{
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(!!nerr);
-}
-</PRE>
-
-<P>
-Your working copy of <TT>`driver.c'</TT>, based on revision
-1.4, contains this before you run <SAMP>`cvs update'</SAMP>:
-
-</P>
-
-<PRE>
-#include <stdlib.h>
-#include <stdio.h>
-
-void main()
-{
- init_scanner();
- parse();
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
-}
-</PRE>
-
-<P>
-You run <SAMP>`cvs update'</SAMP>:
-
-</P>
-
-<PRE>
-$ cvs update driver.c
-RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
-retrieving revision 1.4
-retrieving revision 1.6
-Merging differences between 1.4 and 1.6 into driver.c
-rcsmerge warning: overlaps during merge
-cvs update: conflicts found in driver.c
-C driver.c
-</PRE>
-
-<P>
-<A NAME="IDX154"></A>
-CVS tells you that there were some conflicts.
-Your original working file is saved unmodified in
-<TT>`.#driver.c.1.4'</TT>. The new version of
-<TT>`driver.c'</TT> contains this:
-
-</P>
-
-<PRE>
-#include <stdlib.h>
-#include <stdio.h>
-
-int main(int argc,
- char **argv)
-{
- init_scanner();
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
-<<<<<<< driver.c
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
-=======
- exit(!!nerr);
->>>>>>> 1.6
-}
-</PRE>
-
-<P>
-<A NAME="IDX155"></A>
-<A NAME="IDX156"></A>
-<A NAME="IDX157"></A>
-<A NAME="IDX158"></A>
-<A NAME="IDX159"></A>
-
-</P>
-<P>
-Note how all non-overlapping modifications are incorporated in your working
-copy, and that the overlapping section is clearly marked with
-<SAMP>`<<<<<<<'</SAMP>, <SAMP>`======='</SAMP> and
<SAMP>`>>>>>>>'</SAMP>.
-
-</P>
-<P>
-<A NAME="IDX160"></A>
-<A NAME="IDX161"></A>
-You resolve the conflict by editing the file, removing the markers and
-the erroneous line. Suppose you end up with this file:
-
-<PRE>
-#include <stdlib.h>
-#include <stdio.h>
-
-int main(int argc,
- char **argv)
-{
- init_scanner();
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
-}
-</PRE>
-
-<P>
-You can now go ahead and commit this as revision 1.7.
-
-</P>
-
-<PRE>
-$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
-Checking in driver.c;
-/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
-new revision: 1.7; previous revision: 1.6
-done
-</PRE>
-
-<P>
-For your protection, CVS will refuse to check in a
-file if a conflict occurred and you have not resolved
-the conflict. Currently to resolve a conflict, you
-must change the timestamp on the file, and must also
-insure that the file contains no conflict markers. If
-your file legitimately contains conflict markers (that
-is, occurrences of <SAMP>`>>>>>>> '</SAMP> at the
start of a
-line that don't mark a conflict), then CVS has
-trouble handling this and you need to start hacking on
-the <CODE>CVS/Entries</CODE> file or other such workarounds.
-
-</P>
-<P>
-<A NAME="IDX162"></A>
-If you use release 1.04 or later of pcl-cvs (a GNU
-Emacs front-end for CVS) you can use an Emacs
-package called emerge to help you resolve conflicts.
-See the documentation for pcl-cvs.
-
-</P>
-
-
-<H2><A NAME="SEC41" HREF="cvs.html#TOC41">Informing others about
commits</A></H2>
-<P>
-<A NAME="IDX163"></A>
-<A NAME="IDX164"></A>
-<A NAME="IDX165"></A>
-
-</P>
-<P>
-It is often useful to inform others when you commit a
-new revision of a file. The <SAMP>`-i'</SAMP> option of the
-<TT>`modules'</TT> file, or the <TT>`loginfo'</TT> file, can be
-used to automate this process. See section <A HREF="cvs.html#SEC137">The
modules file</A>.
-See section <A HREF="cvs.html#SEC144">Loginfo</A>. You can use these features
of CVS
-to, for instance, instruct CVS to mail a
-message to all developers, or post a message to a local
-newsgroup.
-
-</P>
-
-
-<H2><A NAME="SEC42" HREF="cvs.html#TOC42">Several developers simultaneously
attempting to run CVS</A></H2>
-
-<P>
-<A NAME="IDX166"></A>
-If several developers try to run CVS at the same
-time, one may get the following message:
-
-</P>
-
-<PRE>
-[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
-</PRE>
-
-<P>
-CVS will try again every 30 seconds, and either
-continue with the operation or print the message again,
-if it still needs to wait. If a lock seems to stick
-around for an undue amount of time, find the person
-holding the lock and ask them about the cvs command
-they are running. If they aren't running a cvs
-command, look for and remove files starting with
-<TT>`#cvs.tfl'</TT>, <TT>`#cvs.rfl'</TT>, or <TT>`#cvs.wfl'</TT>
-from the repository.
-
-</P>
-<P>
-Note that these locks are to protect CVS's
-internal data structures and have no relationship to
-the word <EM>lock</EM> in the sense used by
-RCS---which refers to reserved checkouts
-(see section <A HREF="cvs.html#SEC37">Multiple developers</A>).
-
-</P>
-<P>
-Any number of people can be reading from a given
-repository at a time; only when someone is writing do
-the locks prevent other people from reading or writing.
-
-</P>
-<P>
-<A NAME="IDX167"></A>
-<A NAME="IDX168"></A>
-One might hope for the following property
-
-</P>
-
-<PRE>
-If someone commits some changes in one cvs command,
-then an update by someone else will either get all the
-changes, or none of them.
-</PRE>
-
-<P>
-but CVS does <EM>not</EM> have this property. For
-example, given the files
-
-</P>
-
-<PRE>
-a/one.c
-a/two.c
-b/three.c
-b/four.c
-</PRE>
-
-<P>
-if someone runs
-
-</P>
-
-<PRE>
-cvs ci a/two.c b/three.c
-</PRE>
-
-<P>
-and someone else runs <CODE>cvs update</CODE> at the same
-time, the person running <CODE>update</CODE> might get only
-the change to <TT>`b/three.c'</TT> and not the change to
-<TT>`a/two.c'</TT>.
-
-</P>
-
-
-<H2><A NAME="SEC43" HREF="cvs.html#TOC43">Mechanisms to track who is editing
files</A></H2>
-<P>
-<A NAME="IDX169"></A>
-
-</P>
-<P>
-For many groups, use of CVS in its default mode is
-perfectly satisfactory. Users may sometimes go to
-check in a modification only to find that another
-modification has intervened, but they deal with it and
-proceed with their check in. Other groups prefer to be
-able to know who is editing what files, so that if two
-people try to edit the same file they can choose to
-talk about who is doing what when rather than be
-surprised at check in time. The features in this
-section allow such coordination, while retaining the
-ability of two developers to edit the same file at the
-same time.
-
-</P>
-<P>
-For maximum benefit developers should use <CODE>cvs
-edit</CODE> (not <CODE>chmod</CODE>) to make files read-write to
-edit them, and <CODE>cvs release</CODE> (not <CODE>rm</CODE>) to
-discard a working directory which is no longer in use,
-but CVS is not able to enforce this behavior.
-
-</P>
-
-
-
-<H3><A NAME="SEC44" HREF="cvs.html#TOC44">Telling CVS to watch certain
files</A></H3>
-
-<P>
-To enable the watch features, you first specify that
-certain files are to be watched.
-
-</P>
-<P>
-<A NAME="IDX170"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watch on</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX171"></A>
-
-</P>
-<P>
-<A NAME="IDX172"></A>
-Specify that developers should run <CODE>cvs edit</CODE>
-before editing <VAR>files</VAR>. CVS will create working
-copies of <VAR>files</VAR> read-only, to remind developers
-to run the <CODE>cvs edit</CODE> command before working on
-them.
-
-</P>
-<P>
-If <VAR>files</VAR> includes the name of a directory, CVS
-arranges to watch all files added to the corresponding
-repository directory, and sets a default for files
-added in the future; this allows the user to set
-notification policies on a per-directory basis. The
-contents of the directory are processed recursively,
-unless the <CODE>-l</CODE> option is given.
-
-</P>
-<P>
-If <VAR>files</VAR> is omitted, it defaults to the current directory.
-
-</P>
-<P>
-<A NAME="IDX173"></A>
-</DL>
-
-</P>
-<P>
-<DL>
-<DT><U>Command:</U> <B>cvs watch off</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX174"></A>
-
-</P>
-<P>
-Do not provide notification about work on <VAR>files</VAR>. CVS will create
-working copies of <VAR>files</VAR> read-write.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> arguments are processed as for
<CODE>cvs
-watch on</CODE>.
-
-</P>
-</DL>
-
-
-
-<H3><A NAME="SEC45" HREF="cvs.html#TOC45">Telling CVS to notify you</A></H3>
-
-<P>
-You can tell CVS that you want to receive
-notifications about various actions taken on a file.
-You can do this without using <CODE>cvs watch on</CODE> for
-the file, but generally you will want to use <CODE>cvs
-watch on</CODE>, so that developers use the <CODE>cvs edit</CODE>
-command.
-
-</P>
-<P>
-<A NAME="IDX175"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watch add</B> <I>[<CODE>-a</CODE> action]
[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX176"></A>
-
-</P>
-<P>
-Add the current user to the list of people to receive notification of
-work done on <VAR>files</VAR>.
-
-</P>
-<P>
-The <CODE>-a</CODE> option specifies what kinds of events CVS should notify
-the user about. <VAR>action</VAR> is one of the following:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>edit</CODE>
-<DD>
-Another user has applied the <CODE>cvs edit</CODE> command (described
-below) to a file.
-
-<DT><CODE>unedit</CODE>
-<DD>
-Another user has applied the <CODE>cvs unedit</CODE> command (described
-below) or the <CODE>cvs release</CODE> command to a file, or has deleted
-the file and allowed <CODE>cvs update</CODE> to recreate it.
-
-<DT><CODE>commit</CODE>
-<DD>
-Another user has committed changes to a file.
-
-<DT><CODE>all</CODE>
-<DD>
-All of the above.
-
-<DT><CODE>none</CODE>
-<DD>
-None of the above. (This is useful with <CODE>cvs edit</CODE>,
-described below.)
-
-</DL>
-
-<P>
-The <CODE>-a</CODE> option may appear more than once, or not at all. If
-omitted, the action defaults to <CODE>all</CODE>.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> option are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-</DL>
-
-<P>
-<A NAME="IDX177"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watch remove</B> <I>[<CODE>-a</CODE> action]
[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX178"></A>
-
-</P>
-<P>
-Remove a notification request established using <CODE>cvs watch add</CODE>;
-the arguments are the same. If the <CODE>-a</CODE> option is present, only
-watches for the specified actions are removed.
-
-</P>
-</DL>
-
-<P>
-<A NAME="IDX179"></A>
-When the conditions exist for notification, CVS
-calls the <TT>`notify'</TT> administrative file. Edit
-<TT>`notify'</TT> as one edits the other administrative
-files (see section <A HREF="cvs.html#SEC20">The administrative files</A>).
This
-file follows the usual conventions for administrative
-files (see section <A HREF="cvs.html#SEC140">The common syntax</A>), where
each line is a regular
-expression followed by a command to execute. The
-command should contain a single ocurrence of <SAMP>`%s'</SAMP>
-which will be replaced by the user to notify; the rest
-of the information regarding the notification will be
-supplied to the command on standard input. The
-standard thing to put in the <CODE>notify</CODE> file is the
-single line:
-
-</P>
-
-<PRE>
-ALL mail %s -s \"CVS notification\"
-</PRE>
-
-<P>
-This causes users to be notified by electronic mail.
-
-</P>
-<P>
-<A NAME="IDX180"></A>
-Note that if you set this up in the straightforward
-way, users receive notifications on the server machine.
-One could of course write a <TT>`notify'</TT> script which
-directed notifications elsewhere, but to make this
-easy, CVS allows you to associate a notification
-address for each user. To do so create a file
-<TT>`users'</TT> in <TT>`CVSROOT'</TT> with a line for each
-user in the format <VAR>user</VAR>:<VAR>value</VAR>. Then
-instead of passing the name of the user to be notified
-to <TT>`notify'</TT>, CVS will pass the <VAR>value</VAR>
-(normally an email address on some other machine).
-
-</P>
-
-
-<H3><A NAME="SEC46" HREF="cvs.html#TOC46">How to edit a file which is being
watched</A></H3>
-
-<P>
-<A NAME="IDX181"></A>
-Since a file which is being watched is checked out
-read-only, you cannot simply edit it. To make it
-read-write, and inform others that you are planning to
-edit it, use the <CODE>cvs edit</CODE> command. Some systems
-call this a <EM>checkout</EM>, but CVS uses that term
-for obtaining a copy of the sources (see section <A
HREF="cvs.html#SEC11">Getting the source</A>), an operation which those systems
call a
-<EM>get</EM> or a <EM>fetch</EM>.
-
-</P>
-<P>
-<A NAME="IDX182"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs edit</B> <I>[options] files ...</I>
-<DD><A NAME="IDX183"></A>
-
-</P>
-<P>
-Prepare to edit the working files <VAR>files</VAR>. CVS makes the
-<VAR>files</VAR> read-write, and notifies users who have requested
-<CODE>edit</CODE> notification for any of <VAR>files</VAR>.
-
-</P>
-<P>
-The <CODE>cvs edit</CODE> command accepts the same <VAR>options</VAR> as the
-<CODE>cvs watch add</CODE> command, and establishes a temporary watch for the
-user on <VAR>files</VAR>; CVS will remove the watch when <VAR>files</VAR> are
-<CODE>unedit</CODE>ed or <CODE>commit</CODE>ted. If the user does not wish to
-receive notifications, she should specify <CODE>-a none</CODE>.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> option are processed as for the
<CODE>cvs
-watch</CODE> commands.
-
-</P>
-</DL>
-
-<P>
-Normally when you are done with a set of changes, you
-use the <CODE>cvs commit</CODE> command, which checks in your
-changes and returns the watched files to their usual
-read-only state. But if you instead decide to abandon
-your changes, or not to make any changes, you can use
-the <CODE>cvs unedit</CODE> command.
-
-</P>
-<P>
-<A NAME="IDX184"></A>
-<A NAME="IDX185"></A>
-<A NAME="IDX186"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs unedit</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX187"></A>
-
-</P>
-<P>
-Abandon work on the working files <VAR>files</VAR>, and revert them to the
-repository versions on which they are based. CVS makes those
-<VAR>files</VAR> read-only for which users have requested notification using
-<CODE>cvs watch on</CODE>. CVS notifies users who have requested
<CODE>unedit</CODE>
-notification for any of <VAR>files</VAR>.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> option are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-<P>
-If watches are not in use, the <CODE>unedit</CODE> command
-probably does not work, and the way to revert to the
-repository version is to remove the file and then use
-<CODE>cvs update</CODE> to get a new copy. The meaning is
-not precisely the same; removing and updating may also
-bring in some changes which have been made in the
-repository since the last time you updated.
-</DL>
-
-</P>
-<P>
-When using client/server CVS, you can use the
-<CODE>cvs edit</CODE> and <CODE>cvs unedit</CODE> commands even if
-CVS is unable to succesfully communicate with the
-server; the notifications will be sent upon the next
-successful CVS command.
-
-</P>
-
-
-<H3><A NAME="SEC47" HREF="cvs.html#TOC47">Information about who is watching
and editing</A></H3>
-
-<P>
-<A NAME="IDX188"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watchers</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX189"></A>
-
-</P>
-<P>
-List the users currently watching changes to <VAR>files</VAR>. The report
-includes the files being watched, and the mail address of each watcher.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> arguments are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-</DL>
-
-<P>
-<A NAME="IDX190"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs editors</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX191"></A>
-
-</P>
-<P>
-List the users currently working on <VAR>files</VAR>. The report
-includes the mail address of each user, the time when the user began
-working with the file, and the host and path of the working directory
-containing the file.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> arguments are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-</DL>
-
-
-
-<H3><A NAME="SEC48" HREF="cvs.html#TOC48">Using watches with old versions of
CVS</A></H3>
-
-<P>
-<A NAME="IDX192"></A>
-If you use the watch features on a repository, it
-creates <TT>`CVS'</TT> directories in the repository and
-stores the information about watches in that directory.
-If you attempt to use CVS 1.6 or earlier with the
-repository, you get an error message such as
-
-</P>
-
-<PRE>
-cvs update: cannot open CVS/Entries for reading: No such file or directory
-</PRE>
-
-<P>
-and your operation will likely be aborted. To use the
-watch features, you must upgrade all copies of CVS
-which use that repository in local or server mode. If
-you cannot upgrade, use the <CODE>watch off</CODE> and
-<CODE>watch remove</CODE> commands to remove all watches, and
-that will restore the repository to a state which
-CVS 1.6 can cope with.
-
-</P>
-
-
-<H2><A NAME="SEC49" HREF="cvs.html#TOC49">Choosing between reserved or
unreserved checkouts</A></H2>
-<P>
-<A NAME="IDX193"></A>
-
-</P>
-<P>
-Reserved and unreserved checkouts each have pros and
-cons. Let it be said that a lot of this is a matter of
-opinion or what works given different groups' working
-styles, but here is an attempt to briefly describe the
-issues. There are many ways to organize a team of
-developers. CVS does not try to enforce a certain
-organization. It is a tool that can be used in several
-ways.
-
-</P>
-<P>
-Reserved checkouts can be very counter-productive. If
-two persons want to edit different parts of a file,
-there may be no reason to prevent either of them from
-doing so. Also, it is common for someone to take out a
-lock on a file, because they are planning to edit it,
-but then forget to release the lock.
-
-</P>
-<P>
-People, especially people who are familiar with
-reserved checkouts, often wonder how often conflicts
-occur if unreserved checkouts are used, and how
-difficult they are to resolve. The experience with
-many groups is that they occur rarely and usually are
-relatively straightforward to resolve.
-
-</P>
-<P>
-The rarity of serious conflicts may be surprising, until one realizes
-that they occur only when two developers disagree on the proper design
-for a given section of code; such a disagreement suggests that the
-team has not been communicating properly in the first place. In order
-to collaborate under <EM>any</EM> source management regimen, developers
-must agree on the general design of the system; given this agreement,
-overlapping changes are usually straightforward to merge.
-
-</P>
-<P>
-In some cases unreserved checkouts are clearly
-inappropriate. If no merge tool exists for the kind of
-file you are managing (for example word processor files
-or files edited by Computer Aided Design programs), and
-it is not desirable to change to a program which uses a
-mergeable data format, then resolving conflicts is
-going to be unpleasant enough that you generally will
-be better off to simply avoid the conflicts instead, by
-using reserved checkouts.
-
-</P>
-<P>
-The watches features described above in section <A
HREF="cvs.html#SEC43">Mechanisms to track who is editing files</A>
-can be considered to be an intermediate model between
-reserved checkouts and unreserved checkouts. When you
-go to edit a file, it is possible to find out who else
-is editing it. And rather than having the system
-simply forbid both people editing the file, it can tell
-you what the situation is and let you figure out
-whether it is a problem in that particular case or not.
-Therefore, for some groups it can be considered the
-best of both the reserved checkout and unreserved
-checkout worlds.
-
-</P>
-
-
-<H1><A NAME="SEC50" HREF="cvs.html#TOC50">Branches</A></H1>
-<P>
-<A NAME="IDX194"></A>
-<A NAME="IDX195"></A>
-<A NAME="IDX196"></A>
-
-</P>
-<P>
-So far, all revisions shown in this manual have been on
-the <EM>main trunk</EM>
-of the revision tree, i.e., all revision numbers
-have been of the form <VAR>x</VAR>.<VAR>y</VAR>. One useful
-feature, especially when maintaining several releases
-of a software product at once, is the ability to make
-branches on the revision tree. <EM>Tags</EM>, symbolic
-names for revisions, will also be
-introduced in this chapter.
-
-</P>
-
-
-
-<H2><A NAME="SEC51" HREF="cvs.html#TOC51">Tags--Symbolic revisions</A></H2>
-<P>
-<A NAME="IDX197"></A>
-
-</P>
-<P>
-The revision numbers live a life of their own. They
-need not have anything at all to do with the release
-numbers of your software product. Depending
-on how you use CVS the revision numbers might change several times
-between two releases. As an example, some of the
-source files that make up RCS 5.6 have the following
-revision numbers:
-<A NAME="IDX198"></A>
-
-</P>
-
-<PRE>
-ci.c 5.21
-co.c 5.9
-ident.c 5.3
-rcs.c 5.12
-rcsbase.h 5.11
-rcsdiff.c 5.10
-rcsedit.c 5.11
-rcsfcmp.c 5.9
-rcsgen.c 5.10
-rcslex.c 5.11
-rcsmap.c 5.2
-rcsutil.c 5.10
-</PRE>
-
-<P>
-<A NAME="IDX199"></A>
-<A NAME="IDX200"></A>
-<A NAME="IDX201"></A>
-<A NAME="IDX202"></A>
-You can use the <CODE>tag</CODE> command to give a symbolic name to a
-certain revision of a file. You can use the <SAMP>`-v'</SAMP> flag to the
-<CODE>status</CODE> command to see all tags that a file has, and
-which revision numbers they represent. Tag names can
-contain uppercase and lowercase letters, digits,
-<SAMP>`-'</SAMP>, and <SAMP>`_'</SAMP>. The two tag names <CODE>BASE</CODE>
-and <CODE>HEAD</CODE> are reserved for use by CVS. It
-is expected that future names which are special to
-CVS will contain characters such as <SAMP>`%'</SAMP> or
-<SAMP>`='</SAMP>, rather than being named analogously to
-<CODE>BASE</CODE> and <CODE>HEAD</CODE>, to avoid conflicts with
-actual tag names.
-
-</P>
-<P>
-<A NAME="IDX203"></A>
-<A NAME="IDX204"></A>
-The following example shows how you can add a tag to a
-file. The commands must be issued inside your working
-copy of the module. That is, you should issue the
-command in the directory where <TT>`backend.c'</TT>
-resides.
-
-</P>
-
-<PRE>
-$ cvs tag release-0-4 backend.c
-T backend.c
-$ cvs status -v backend.c
-===================================================================
-File: backend.c Status: Up-to-date
-
- Version: 1.4 Tue Dec 1 14:39:01 1992
- RCS Version: 1.4 /usr/local/cvsroot/yoyodyne/tc/backend.c,v
- Sticky Tag: (none)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-0-4 (revision: 1.4)
-
-</PRE>
-
-<P>
-There is seldom reason to tag a file in isolation. A more common use is
-to tag all the files that constitute a module with the same tag at
-strategic points in the development life-cycle, such as when a release
-is made.
-
-</P>
-
-<PRE>
-$ cvs tag release-1-0 .
-cvs tag: Tagging .
-T Makefile
-T backend.c
-T driver.c
-T frontend.c
-T parser.c
-</PRE>
-
-<P>
-(When you give CVS a directory as argument, it generally applies the
-operation to all the files in that directory, and (recursively), to any
-subdirectories that it may contain. See section <A
HREF="cvs.html#SEC60">Recursive behavior</A>.)
-
-</P>
-<P>
-<A NAME="IDX205"></A>
-<A NAME="IDX206"></A>
-The <CODE>checkout</CODE> command has a flag, <SAMP>`-r'</SAMP>, that lets you
check out
-a certain revision of a module. This flag makes it easy to
-retrieve the sources that make up release 1.0 of the module <SAMP>`tc'</SAMP>
at
-any time in the future:
-
-</P>
-
-<PRE>
-$ cvs checkout -r release-1-0 tc
-</PRE>
-
-<P>
-This is useful, for instance, if someone claims that there is a bug in
-that release, but you cannot find the bug in the current working copy.
-
-</P>
-<P>
-You can also check out a module as it was at any given date.
-See section <A HREF="cvs.html#SEC97">checkout options</A>.
-
-</P>
-<P>
-When you tag more than one file with the same tag you
-can think about the tag as "a curve drawn through a
-matrix of filename vs. revision number." Say we have 5
-files with the following revisions:
-
-</P>
-
-<PRE>
- file1 file2 file3 file4 file5
-
- 1.1 1.1 1.1 1.1 /--1.1* <-*- TAG
- 1.2*- 1.2 1.2 -1.2*-
- 1.3 \- 1.3*- 1.3 / 1.3
- 1.4 \ 1.4 / 1.4
- \-1.5*- 1.5
- 1.6
-</PRE>
-
-<P>
-At some time in the past, the <CODE>*</CODE> versions were tagged.
-You can think of the tag as a handle attached to the curve
-drawn through the tagged revisions. When you pull on
-the handle, you get all the tagged revisions. Another
-way to look at it is that you "sight" through a set of
-revisions that is "flat" along the tagged revisions,
-like this:
-
-</P>
-
-<PRE>
- file1 file2 file3 file4 file5
-
- 1.1
- 1.2
- 1.1 1.3 _
- 1.1 1.2 1.4 1.1 /
- 1.2*----1.3*----1.5*----1.2*----1.1 (--- <--- Look here
- 1.3 1.6 1.3 \_
- 1.4 1.4
- 1.5
-</PRE>
-
-
-
-<H2><A NAME="SEC52" HREF="cvs.html#TOC52">What branches are good for</A></H2>
-<P>
-<A NAME="IDX207"></A>
-<A NAME="IDX208"></A>
-<A NAME="IDX209"></A>
-
-</P>
-<P>
-Suppose that release 1.0 of tc has been made. You are continuing to
-develop tc, planning to create release 1.1 in a couple of months. After a
-while your customers start to complain about a fatal bug. You check
-out release 1.0 (see section <A HREF="cvs.html#SEC51">Tags--Symbolic
revisions</A>) and find the bug
-(which turns out to have a trivial fix). However, the current revision
-of the sources are in a state of flux and are not expected to be stable
-for at least another month. There is no way to make a
-bugfix release based on the newest sources.
-
-</P>
-<P>
-The thing to do in a situation like this is to create a <EM>branch</EM> on
-the revision trees for all the files that make up
-release 1.0 of tc. You can then make
-modifications to the branch without disturbing the main trunk. When the
-modifications are finished you can select to either incorporate them on
-the main trunk, or leave them on the branch.
-
-</P>
-
-
-<H2><A NAME="SEC53" HREF="cvs.html#TOC53">Creating a branch</A></H2>
-<P>
-<A NAME="IDX210"></A>
-<A NAME="IDX211"></A>
-<A NAME="IDX212"></A>
-
-</P>
-<P>
-The <CODE>rtag</CODE> command can be used to create a branch.
-The <CODE>rtag</CODE> command is much like <CODE>tag</CODE>, but it
-does not require that you have a working copy of the
-module. See section <A HREF="cvs.html#SEC126">rtag--Add a symbolic tag to a
module</A>. (You can also use the <CODE>tag</CODE>
-command; see section <A HREF="cvs.html#SEC130">tag--Add a symbolic tag to
checked out versions of files</A>).
-
-</P>
-
-<PRE>
-$ cvs rtag -b -r release-1-0 release-1-0-patches tc
-</PRE>
-
-<P>
-The <SAMP>`-b'</SAMP> flag makes <CODE>rtag</CODE> create a branch
-(rather than just a symbolic revision name). <SAMP>`-r
-release-1-0'</SAMP> says that this branch should be rooted at the node (in
-the revision tree) that corresponds to the tag
-<SAMP>`release-1-0'</SAMP>. Note that the numeric revision number that matches
-<SAMP>`release-1-0'</SAMP> will probably be different from file to file. The
-name of the new branch is <SAMP>`release-1-0-patches'</SAMP>, and the
-module affected is <SAMP>`tc'</SAMP>.
-
-</P>
-<P>
-To fix the problem in release 1.0, you need a working
-copy of the branch you just created.
-
-</P>
-
-<PRE>
-$ cvs checkout -r release-1-0-patches tc
-$ cvs status -v driver.c backend.c
-===================================================================
-File: driver.c Status: Up-to-date
-
- Version: 1.7 Sat Dec 5 18:25:54 1992
- RCS Version: 1.7 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
- Sticky Tag: release-1-0-patches (branch: 1.7.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.7.2)
- release-1-0 (revision: 1.7)
-
-===================================================================
-File: backend.c Status: Up-to-date
-
- Version: 1.4 Tue Dec 1 14:39:01 1992
- RCS Version: 1.4 /usr/local/cvsroot/yoyodyne/tc/backend.c,v
- Sticky Tag: release-1-0-patches (branch: 1.4.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.4.2)
- release-1-0 (revision: 1.4)
- release-0-4 (revision: 1.4)
-
-</PRE>
-
-<P>
-<A NAME="IDX213"></A>
-As the output from the <CODE>status</CODE> command shows the branch
-number is created by adding a digit at the tail of the revision number
-it is based on. (If <SAMP>`release-1-0'</SAMP> corresponds to revision 1.4,
the
-branch's revision number will be 1.4.2. For obscure reasons CVS always
-gives branches even numbers, starting at 2.
-See section <A HREF="cvs.html#SEC8">Revision numbers</A>).
-
-</P>
-
-
-<H2><A NAME="SEC54" HREF="cvs.html#TOC54">Sticky tags</A></H2>
-<P>
-<A NAME="IDX214"></A>
-<A NAME="IDX215"></A>
-<A NAME="IDX216"></A>
-
-</P>
-<P>
-The <SAMP>`-r release-1-0-patches'</SAMP> flag that was given
-to <CODE>checkout</CODE> in the previous example
-is <EM>sticky</EM>, that is, it will apply to subsequent commands
-in this directory. If you commit any modifications, they are
-committed on the branch. You can later merge the modifications into
-the main trunk. See section <A HREF="cvs.html#SEC55">Merging</A>.
-
-</P>
-<P>
-You can use the <CODE>status</CODE> command to see what
-sticky tags or dates are set:
-
-</P>
-
-<PRE>
-$ vi driver.c # Fix the bugs
-$ cvs commit -m "Fixed initialization bug" driver.c
-Checking in driver.c;
-/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
-new revision: 1.7.2.1; previous revision: 1.7
-done
-$ cvs status -v driver.c
-===================================================================
-File: driver.c Status: Up-to-date
-
- Version: 1.7.2.1 Sat Dec 5 19:35:03 1992
- RCS Version: 1.7.2.1 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
- Sticky Tag: release-1-0-patches (branch: 1.7.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.7.2)
- release-1-0 (revision: 1.7)
-
-</PRE>
-
-<P>
-<A NAME="IDX217"></A>
-<A NAME="IDX218"></A>
-<A NAME="IDX219"></A>
-The sticky tags will remain on your working files until
-you delete them with <SAMP>`cvs update -A'</SAMP>. The
-<SAMP>`-A'</SAMP> option retrieves the version of the file from
-the head of the trunk, and forgets any sticky tags,
-dates, or options.
-
-</P>
-<P>
-<A NAME="IDX220"></A>
-Sticky tags are not just for branches. For example,
-suppose that you want to avoid updating your working
-directory, to isolate yourself from possibly
-destabilizing changes other people are making. You
-can, of course, just refrain from running <CODE>cvs
-update</CODE>. But if you want to avoid updating only a
-portion of a larger tree, then sticky tags can help.
-If you check out a certain revision (such as 1.4) it
-will become sticky. Subsequent <CODE>cvs update</CODE> will
-not retrieve the latest revision until you reset the
-tag with <CODE>cvs update -A</CODE>. Likewise, use of the
-<SAMP>`-D'</SAMP> option to <CODE>update</CODE> or <CODE>checkout</CODE>
-sets a <EM>sticky date</EM>, which, similarly, causes that
-date to be used for future retrievals.
-
-</P>
-<P>
-<A NAME="IDX221"></A>
-<A NAME="IDX222"></A>
-Many times you will want to retrieve an old version of
-a file without setting a sticky tag. The way to do
-that is with the <SAMP>`-p'</SAMP> option to <CODE>checkout</CODE> or
-<CODE>update</CODE>, which sends the contents of the file to
-standard output. For example, suppose you have a file
-named <TT>`file1'</TT> which existed as revision 1.1, and
-you then removed it (thus adding a dead revision 1.2).
-Now suppose you want to add it again, with the same
-contents it had previously. Here is how to do it:
-
-</P>
-
-<PRE>
-$ cvs update -p -r 1.1 file1 >file1
-===================================================================
-Checking out file1
-RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
-VERS: 1.1
-***************
-$ cvs add file1
-cvs add: re-adding file file1 (in place of dead revision 1.2)
-cvs add: use 'cvs commit' to add this file permanently
-$ cvs commit -m test
-Checking in file1;
-/tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1
-new revision: 1.3; previous revision: 1.2
-done
-$
-</PRE>
-
-
-
-<H1><A NAME="SEC55" HREF="cvs.html#TOC55">Merging</A></H1>
-<P>
-<A NAME="IDX223"></A>
-<A NAME="IDX224"></A>
-<A NAME="IDX225"></A>
-<A NAME="IDX226"></A>
-<A NAME="IDX227"></A>
-
-</P>
-<P>
-You can include the changes made between any two
-revisions into your working copy, by <EM>merging</EM>.
-You can then commit that revision, and thus effectively
-copy the changes onto another branch.
-
-</P>
-
-
-
-<H2><A NAME="SEC56" HREF="cvs.html#TOC56">Merging an entire branch</A></H2>
-<P>
-<A NAME="IDX228"></A>
-<A NAME="IDX229"></A>
-
-</P>
-<P>
-You can merge changes made on a branch into your working copy by giving
-the <SAMP>`-j <VAR>branch</VAR>'</SAMP> flag to the <CODE>update</CODE>
command. With one
-<SAMP>`-j <VAR>branch</VAR>'</SAMP> option it merges the changes made between
the
-point where the branch forked and newest revision on that branch (into
-your working copy).
-
-</P>
-<P>
-<A NAME="IDX230"></A>
-The <SAMP>`-j'</SAMP> stands for "join".
-
-</P>
-<P>
-<A NAME="IDX231"></A>
-<A NAME="IDX232"></A>
-<A NAME="IDX233"></A>
-Consider this revision tree:
-
-</P>
-
-<PRE>
-+-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+
- !
- !
- ! +---------+ +---------+
-Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
- +---------+ +---------+
-</PRE>
-
-<P>
-The branch 1.2.2 has been given the tag (symbolic name) <SAMP>`R1fix'</SAMP>.
The
-following example assumes that the module <SAMP>`mod'</SAMP> contains only one
-file, <TT>`m.c'</TT>.
-
-</P>
-
-<PRE>
-$ cvs checkout mod # Retrieve the latest revision, 1.4
-
-$ cvs update -j R1fix m.c # Merge all changes made on the branch,
- # i.e. the changes between revision 1.2
- # and 1.2.2.2, into your working copy
- # of the file.
-
-$ cvs commit -m "Included R1fix" # Create revision 1.5.
-</PRE>
-
-<P>
-A conflict can result from a merge operation. If that
-happens, you should resolve it before committing the
-new revision. See section <A HREF="cvs.html#SEC40">Conflicts example</A>.
-
-</P>
-<P>
-The <CODE>checkout</CODE> command also supports the <SAMP>`-j
<VAR>branch</VAR>'</SAMP> flag. The
-same effect as above could be achieved with this:
-
-</P>
-
-<PRE>
-$ cvs checkout -j R1fix mod
-$ cvs commit -m "Included R1fix"
-</PRE>
-
-
-
-<H2><A NAME="SEC57" HREF="cvs.html#TOC57">Merging from a branch several
times</A></H2>
-
-<P>
-Continuing our example, the revision tree now looks
-like this:
-
-</P>
-
-<PRE>
-+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+ +-----+
- ! *
- ! *
- ! +---------+ +---------+
-Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
- +---------+ +---------+
-</PRE>
-
-<P>
-where the starred line represents the merge from the
-<SAMP>`R1fix'</SAMP> branch to the main trunk, as just
-discussed.
-
-</P>
-<P>
-Now suppose that development continues on the
-<SAMP>`R1fix'</SAMP> branch:
-
-</P>
-
-<PRE>
-+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+ +-----+
- ! *
- ! *
- ! +---------+ +---------+ +---------+
-Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
- +---------+ +---------+ +---------+
-</PRE>
-
-<P>
-and then you want to merge those new changes onto the
-main trunk. If you just use the <CODE>cvs update -j
-R1fix m.c</CODE> command again, CVS will attempt to
-merge again the changes which you have already merged,
-which can have undesirable side effects.
-
-</P>
-<P>
-So instead you need to specify that you only want to
-merge the changes on the branch which have not yet been
-merged into the trunk. To do that you specify two
-<SAMP>`-j'</SAMP> options, and CVS merges the changes from
-the first revision to the second revision. For
-example, in this case the simplest way would be
-
-</P>
-
-<PRE>
-cvs update -j 1.2.2.2 -j R1fix m.c # Merge changes from 1.2.2.2 to the
- # head of the R1fix branch
-</PRE>
-
-<P>
-The problem with this is that you need to specify the
-1.2.2.2 revision manually. A slightly better approach
-might be to use the date the last merge was done:
-
-</P>
-
-<PRE>
-cvs update -j R1fix:yesterday -j R1fix m.c
-</PRE>
-
-<P>
-Better yet, tag the R1fix branch after every merge into
-the trunk, and then use that tag for subsequent merges:
-
-</P>
-
-<PRE>
-cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
-</PRE>
-
-
-
-<H2><A NAME="SEC58" HREF="cvs.html#TOC58">Merging differences between any two
revisions</A></H2>
-<P>
-<A NAME="IDX234"></A>
-<A NAME="IDX235"></A>
-<A NAME="IDX236"></A>
-
-</P>
-<P>
-With two <SAMP>`-j <VAR>revision</VAR>'</SAMP> flags, the <CODE>update</CODE>
-(and <CODE>checkout</CODE>) command can merge the differences
-between any two revisions into your working file.
-
-</P>
-<P>
-<A NAME="IDX237"></A>
-<A NAME="IDX238"></A>
-
-<PRE>
-$ cvs update -j 1.5 -j 1.3 backend.c
-</PRE>
-
-<P>
-will <EM>remove</EM> all changes made between revision
-1.3 and 1.5. Note the order of the revisions!
-
-</P>
-<P>
-If you try to use this option when operating on
-multiple files, remember that the numeric revisions will
-probably be very different between the various files
-that make up a module. You almost always use symbolic
-tags rather than revision numbers when operating on
-multiple files.
-
-</P>
-
-
-<H2><A NAME="SEC59" HREF="cvs.html#TOC59">Merging can add or remove
files</A></H2>
-
-<P>
-If the changes which you are merging involve removing
-or adding some files, <CODE>update -j</CODE> will reflect
-such additions or removals.
-
-</P>
-<P>
-For example:
-
-<PRE>
-cvs update -A
-touch a b c
-cvs add a b c ; cvs ci -m "added" a b c
-cvs tag -b branchtag
-cvs update -r branchtag
-touch d ; cvs add d
-rm a ; cvs rm a
-cvs ci -m "added d, removed a"
-cvs update -A
-cvs update -jbranchtag
-</PRE>
-
-
-
-<H1><A NAME="SEC60" HREF="cvs.html#TOC60">Recursive behavior</A></H1>
-<P>
-<A NAME="IDX239"></A>
-<A NAME="IDX240"></A>
-<A NAME="IDX241"></A>
-<A NAME="IDX242"></A>
-
-</P>
-<P>
-Almost all of the subcommands of CVS work
-recursively when you specify a directory as an
-argument. For instance, consider this directory
-structure:
-
-</P>
-
-<PRE>
- <CODE>$HOME</CODE>
- |
- +--<TT>tc</TT>
- | |
- +--<TT>CVS</TT>
- | (internal CVS files)
- +--<TT>Makefile</TT>
- +--<TT>backend.c</TT>
- +--<TT>driver.c</TT>
- +--<TT>frontend.c</TT>
- +--<TT>parser.c</TT>
- +--<TT>man</TT>
- | |
- | +--<TT>CVS</TT>
- | | (internal CVS files)
- | +--<TT>tc.1</TT>
- |
- +--<TT>testing</TT>
- |
- +--<TT>CVS</TT>
- | (internal CVS files)
- +--<TT>testpgm.t</TT>
- +--<TT>test2.t</TT>
-</PRE>
-
-<P>
-If <TT>`tc'</TT> is the current working directory, the
-following is true:
-
-</P>
-
-<UL>
-<LI>
-
-<SAMP>`cvs update testing'</SAMP> is equivalent to <SAMP>`cvs
-update testing/testpgm.t testing/test2.t'</SAMP>
-
-<LI>
-
-<SAMP>`cvs update testing man'</SAMP> updates all files in the
-subdirectories
-
-<LI>
-
-<SAMP>`cvs update .'</SAMP> or just <SAMP>`cvs update'</SAMP> updates
-all files in the <CODE>tc</CODE> module
-</UL>
-
-<P>
-If no arguments are given to <CODE>update</CODE> it will
-update all files in the current working directory and
-all its subdirectories. In other words, <TT>`.'</TT> is a
-default argument to <CODE>update</CODE>. This is also true
-for most of the CVS subcommands, not only the
-<CODE>update</CODE> command.
-
-</P>
-<P>
-The recursive behavior of the CVS subcommands can be
-turned off with the <SAMP>`-l'</SAMP> option.
-
-</P>
-
-<PRE>
-$ cvs update -l # Don't update files in subdirectories
-</PRE>
-
-
-
-<H1><A NAME="SEC61" HREF="cvs.html#TOC61">Adding files to a directory</A></H1>
-<P>
-<A NAME="IDX243"></A>
-
-</P>
-<P>
-To add a new file to a directory, follow these steps.
-
-</P>
-
-<UL>
-<LI>
-
-You must have a working copy of the directory.
-See section <A HREF="cvs.html#SEC11">Getting the source</A>.
-
-<LI>
-
-Create the new file inside your working copy of the directory.
-
-<LI>
-
-Use <SAMP>`cvs add <VAR>filename</VAR>'</SAMP> to tell CVS that you
-want to version control the file. If the file contains
-binary data, specify <SAMP>`-kb'</SAMP> (see section <A
HREF="cvs.html#SEC83">Handling binary files</A>).
-
-<LI>
-
-Use <SAMP>`cvs commit <VAR>filename</VAR>'</SAMP> to actually check
-in the file into the repository. Other developers
-cannot see the file until you perform this step.
-</UL>
-
-<P>
-You can also use the <CODE>add</CODE> command to add a new
-directory.
-
-</P>
-<P>
-Unlike most other commands, the <CODE>add</CODE> command is
-not recursive. You cannot even type <SAMP>`cvs add
-foo/bar'</SAMP>! Instead, you have to
-
-</P>
-
-<PRE>
-$ cd foo
-$ cvs add bar
-</PRE>
-
-<P>
-<A NAME="IDX244"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs add</B> <I>[<CODE>-k</CODE> kflag] [<CODE>-m</CODE>
message] files ...</I>
-<DD><A NAME="IDX245"></A>
-
-</P>
-<P>
-Schedule <VAR>files</VAR> to be added to the repository.
-The files or directories specified with <CODE>add</CODE> must
-already exist in the current directory. To add a whole
-new directory hierarchy to the source repository (for
-example, files received from a third-party vendor), use
-the <CODE>import</CODE> command instead. See section <A
HREF="cvs.html#SEC112">import--Import sources into CVS, using vendor
branches</A>.
-
-</P>
-<P>
-The added files are not placed in the source repository
-until you use <CODE>commit</CODE> to make the change
-permanent. Doing an <CODE>add</CODE> on a file that was
-removed with the <CODE>remove</CODE> command will undo the
-effect of the <CODE>remove</CODE>, unless a <CODE>commit</CODE>
-command intervened. See section <A HREF="cvs.html#SEC62">Removing files from
a module</A>, for an
-example.
-
-</P>
-<P>
-The <SAMP>`-k'</SAMP> option specifies the default way that
-this file will be checked out; for more information see
-section <A HREF="cvs.html#SEC81">Substitution modes</A>.
-
-</P>
-<P>
-The <SAMP>`-m'</SAMP> option specifies a description for the
-file. This description appears in the history log (if
-it is enabled, see section <A HREF="cvs.html#SEC149">The history file</A>).
It will also be
-saved in the version history inside the repository when
-the file is committed. The <CODE>log</CODE> command displays
-this description. The description can be changed using
-<SAMP>`admin -t'</SAMP>. See section <A
HREF="cvs.html#SEC91">admin--Administration front end for rcs</A>. If you omit
the
-<SAMP>`-m <VAR>description</VAR>'</SAMP> flag, an empty string will
-be used. You will not be prompted for a description.
-</DL>
-
-</P>
-<P>
-For example, the following commands add the file
-<TT>`backend.c'</TT> to the repository:
-
-</P>
-
-<PRE>
-$ cvs add backend.c
-$ cvs commit -m "Early version. Not yet compilable." backend.c
-</PRE>
-
-<P>
-When you add a file it is added only on the branch
-which you are working on (see section <A HREF="cvs.html#SEC50">Branches</A>).
You can
-later merge the additions to another branch if you want
-(see section <A HREF="cvs.html#SEC59">Merging can add or remove files</A>).
-
-</P>
-
-
-<H1><A NAME="SEC62" HREF="cvs.html#TOC62">Removing files from a module</A></H1>
-<P>
-<A NAME="IDX246"></A>
-<A NAME="IDX247"></A>
-
-</P>
-<P>
-Modules change. New files are added, and old files
-disappear. Still, you want to be able to retrieve an
-exact copy of old releases of the module.
-
-</P>
-<P>
-Here is what you can do to remove a file from a module,
-but remain able to retrieve old revisions:
-
-</P>
-
-<UL>
-<LI>
-
-Make sure that you have not made any uncommitted
-modifications to the file. See section <A HREF="cvs.html#SEC14">Viewing
differences</A>,
-for one way to do that. You can also use the
-<CODE>status</CODE> or <CODE>update</CODE> command. If you remove
-the file without committing your changes, you will of
-course not be able to retrieve the file as it was
-immediately before you deleted it.
-
-<LI>
-
-Remove the file from your working copy of the module.
-You can for instance use <CODE>rm</CODE>.
-
-<LI>
-
-Use <SAMP>`cvs remove <VAR>filename</VAR>'</SAMP> to tell CVS that
-you really want to delete the file.
-
-<LI>
-
-Use <SAMP>`cvs commit <VAR>filename</VAR>'</SAMP> to actually
-perform the removal of the file from the repository.
-</UL>
-
-<P>
-When you commit the removal of the file, CVS
-records the fact that the file no longer exists. It is
-possible for a file to exist on only some branches and
-not on others, or to re-add another file with the same
-name later. CVS will correctly create or not create
-the file, based on the <SAMP>`-r'</SAMP> and <SAMP>`-D'</SAMP> options
-specified to <CODE>checkout</CODE> or <CODE>update</CODE>.
-
-</P>
-<P>
-<A NAME="IDX248"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs remove</B> <I>[<CODE>-lR</CODE>] files ...</I>
-<DD><A NAME="IDX249"></A>
-
-</P>
-<P>
-Schedule file(s) to be removed from the repository
-(files which have not already been removed from the
-working directory are not processed). This command
-does not actually remove the file from the repository
-until you commit the removal. The <SAMP>`-R'</SAMP> option
-(the default) specifies that it will recurse into
-subdirectories; <SAMP>`-l'</SAMP> specifies that it will not.
-</DL>
-
-</P>
-<P>
-Here is an example of removing several files:
-
-</P>
-
-<PRE>
-$ cd test
-$ rm ?.c
-$ cvs remove
-cvs remove: Removing .
-cvs remove: scheduling a.c for removal
-cvs remove: scheduling b.c for removal
-cvs remove: use 'cvs commit' to remove these files permanently
-$ cvs ci -m "Removed unneeded files"
-cvs commit: Examining .
-cvs commit: Committing .
-</PRE>
-
-<P>
-If you change your mind you can easily resurrect the
-file before you commit it, using the <CODE>add</CODE>
-command.
-
-</P>
-
-<PRE>
-$ ls
-CVS ja.h oj.c
-$ rm oj.c
-$ cvs remove oj.c
-cvs remove: scheduling oj.c for removal
-cvs remove: use 'cvs commit' to remove this file permanently
-$ cvs add oj.c
-U oj.c
-cvs add: oj.c, version 1.1.1.1, resurrected
-</PRE>
-
-<P>
-If you realize your mistake before you run the
-<CODE>remove</CODE> command you can use <CODE>update</CODE> to
-resurrect the file:
-
-</P>
-
-<PRE>
-$ rm oj.c
-$ cvs update oj.c
-cvs update: warning: oj.c was lost
-U oj.c
-</PRE>
-
-<P>
-When you remove a file it is added only on the branch
-which you are working on (see section <A HREF="cvs.html#SEC50">Branches</A>).
You can
-later merge the additions to another branch if you want
-(see section <A HREF="cvs.html#SEC59">Merging can add or remove files</A>).
-
-</P>
-
-
-<H1><A NAME="SEC63" HREF="cvs.html#TOC63">Tracking third-party sources</A></H1>
-<P>
-<A NAME="IDX250"></A>
-<A NAME="IDX251"></A>
-
-</P>
-<P>
-If you modify a program to better fit your site, you
-probably want to include your modifications when the next
-release of the program arrives. CVS can help you with
-this task.
-
-</P>
-<P>
-<A NAME="IDX252"></A>
-<A NAME="IDX253"></A>
-<A NAME="IDX254"></A>
-In the terminology used in CVS, the supplier of the
-program is called a <EM>vendor</EM>. The unmodified
-distribution from the vendor is checked in on its own
-branch, the <EM>vendor branch</EM>. CVS reserves branch
-1.1.1 for this use.
-
-</P>
-<P>
-When you modify the source and commit it, your revision
-will end up on the main trunk. When a new release is
-made by the vendor, you commit it on the vendor branch
-and copy the modifications onto the main trunk.
-
-</P>
-<P>
-Use the <CODE>import</CODE> command to create and update
-the vendor branch. After a successful <CODE>import</CODE>
-the vendor branch is made the `head' revision, so
-anyone that checks out a copy of the file gets that
-revision. When a local modification is committed it is
-placed on the main trunk, and made the `head'
-revision.
-
-</P>
-
-
-
-<H2><A NAME="SEC64" HREF="cvs.html#TOC64">Importing a module for the first
time</A></H2>
-<P>
-<A NAME="IDX255"></A>
-
-</P>
-<P>
-Use the <CODE>import</CODE> command to check in the sources
-for the first time. When you use the <CODE>import</CODE>
-command to track third-party sources, the <EM>vendor
-tag</EM> and <EM>release tags</EM> are useful. The
-<EM>vendor tag</EM> is a symbolic name for the branch
-(which is always 1.1.1, unless you use the <SAMP>`-b
-<VAR>branch</VAR>'</SAMP> flag---See section <A HREF="cvs.html#SEC113">import
options</A>). The
-<EM>release tags</EM> are symbolic names for a particular
-release, such as <SAMP>`FSF_0_04'</SAMP>.
-
-</P>
-<P>
-<A NAME="IDX256"></A>
-Suppose you use <CODE>wdiff</CODE> (a variant of <CODE>diff</CODE>
-that ignores changes that only involve whitespace), and
-are going to make private modifications that you want
-to be able to use even when new releases are made in
-the future. You start by importing the source to your
-repository:
-
-</P>
-
-<PRE>
-$ tar xfz wdiff-0.04.tar.gz
-$ cd wdiff-0.04
-$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
-</PRE>
-
-<P>
-The vendor tag is named <SAMP>`FSF_DIST'</SAMP> in the above
-example, and the only release tag assigned is
-<SAMP>`WDIFF_0_04'</SAMP>.
-
-</P>
-
-
-<H2><A NAME="SEC65" HREF="cvs.html#TOC65">Updating a module with the import
command</A></H2>
-
-<P>
-When a new release of the source arrives, you import it into the
-repository with the same <CODE>import</CODE> command that you used to set up
-the repository in the first place. The only difference is that you
-specify a different release tag this time.
-
-</P>
-
-<PRE>
-$ tar xfz wdiff-0.05.tar.gz
-$ cd wdiff-0.05
-$ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
-</PRE>
-
-<P>
-For files that have not been modified locally, the newly created
-revision becomes the head revision. If you have made local
-changes, <CODE>import</CODE> will warn you that you must merge the changes
-into the main trunk, and tell you to use <SAMP>`checkout -j'</SAMP> to do so.
-
-</P>
-
-<PRE>
-$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
-</PRE>
-
-<P>
-The above command will check out the latest revision of
-<SAMP>`wdiff'</SAMP>, merging the changes made on the vendor branch
<SAMP>`FSF_DIST'</SAMP>
-since yesterday into the working copy. If any conflicts arise during
-the merge they should be resolved in the normal way (see section <A
HREF="cvs.html#SEC40">Conflicts example</A>). Then, the modified files may be
committed.
-
-</P>
-<P>
-Using a date, as suggested above, assumes that you do
-not import more than one release of a product per
-day. If you do, you can always use something like this
-instead:
-
-</P>
-
-<PRE>
-$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
-</PRE>
-
-<P>
-In this case, the two above commands are equivalent.
-
-</P>
-
-
-<H2><A NAME="SEC66" HREF="cvs.html#TOC66">How to handle binary files with cvs
import</A></H2>
-
-<P>
-Use the <SAMP>`-k'</SAMP> wrapper option to tell import which
-files are binary. See section <A HREF="cvs.html#SEC138">The cvswrappers
file</A>.
-
-</P>
-
-
-<H1><A NAME="SEC67" HREF="cvs.html#TOC67">Moving and renaming files</A></H1>
-<P>
-<A NAME="IDX257"></A>
-<A NAME="IDX258"></A>
-<A NAME="IDX259"></A>
-
-</P>
-<P>
-Moving files to a different directory or renaming them
-is not difficult, but some of the ways in which this
-works may be non-obvious. (Moving or renaming a
-directory is even harder. See section <A HREF="cvs.html#SEC71">Moving and
renaming directories</A>).
-
-</P>
-<P>
-The examples below assume that the file <VAR>old</VAR> is renamed to
-<VAR>new</VAR>.
-
-</P>
-
-
-
-<H2><A NAME="SEC68" HREF="cvs.html#TOC68">The Normal way to Rename</A></H2>
-
-<P>
-The normal way to move a file is to copy <VAR>old</VAR> to
-<VAR>new</VAR>, and then issue the normal CVS commands
-to remove <VAR>old</VAR> from the repository, and add
-<VAR>new</VAR> to it. (Both <VAR>old</VAR> and <VAR>new</VAR> could
-contain relative paths, for example <TT>`foo/bar.c'</TT>).
-
-</P>
-
-<PRE>
-$ mv <VAR>old</VAR> <VAR>new</VAR>
-$ cvs remove <VAR>old</VAR>
-$ cvs add <VAR>new</VAR>
-$ cvs commit -m "Renamed <VAR>old</VAR> to <VAR>new</VAR>" <VAR>old</VAR>
<VAR>new</VAR>
-</PRE>
-
-<P>
-This is the simplest way to move a file, it is not
-error-prone, and it preserves the history of what was
-done. Note that to access the history of the file you
-must specify the old or the new name, depending on what
-portion of the history you are accessing. For example,
-<CODE>cvs log <VAR>old</VAR></CODE> will give the log up until the
-time of the rename.
-
-</P>
-<P>
-When <VAR>new</VAR> is committed its revision numbers will
-start at 1.0 again, so if that bothers you, use the
-<SAMP>`-r rev'</SAMP> option to commit (see section <A
HREF="cvs.html#SEC100">commit options</A>)
-
-</P>
-
-
-<H2><A NAME="SEC69" HREF="cvs.html#TOC69">Moving the history file</A></H2>
-
-<P>
-This method is more dangerous, since it involves moving
-files inside the repository. Read this entire section
-before trying it out!
-
-</P>
-
-<PRE>
-$ cd $CVSROOT/<VAR>module</VAR>
-$ mv <VAR>old</VAR>,v <VAR>new</VAR>,v
-</PRE>
-
-<P>
-Advantages:
-
-</P>
-
-<UL>
-<LI>
-
-The log of changes is maintained intact.
-
-<LI>
-
-The revision numbers are not affected.
-</UL>
-
-<P>
-Disadvantages:
-
-</P>
-
-<UL>
-<LI>
-
-Old releases of the module cannot easily be fetched from the
-repository. (The file will show up as <VAR>new</VAR> even
-in revisions from the time before it was renamed).
-
-<LI>
-
-There is no log information of when the file was renamed.
-
-<LI>
-
-Nasty things might happen if someone accesses the history file
-while you are moving it. Make sure no one else runs any of the CVS
-commands while you move it.
-</UL>
-
-
-
-<H2><A NAME="SEC70" HREF="cvs.html#TOC70">Copying the history file</A></H2>
-
-<P>
-This way also involves direct modifications to the
-repository. It is safe, but not without drawbacks.
-
-</P>
-
-<PRE>
-# Copy the RCS file inside the repository
-$ cd $CVSROOT/<VAR>module</VAR>
-$ cp <VAR>old</VAR>,v <VAR>new</VAR>,v
-# Remove the old file
-$ cd ~/<VAR>module</VAR>
-$ rm <VAR>old</VAR>
-$ cvs remove <VAR>old</VAR>
-$ cvs commit <VAR>old</VAR>
-# Remove all tags from <VAR>new</VAR>
-$ cvs update <VAR>new</VAR>
-$ cvs log <VAR>new</VAR> # Remember the non-branch tag names
-$ cvs tag -d <VAR>tag1</VAR> <VAR>new</VAR>
-$ cvs tag -d <VAR>tag2</VAR> <VAR>new</VAR>
-...
-</PRE>
-
-<P>
-By removing the tags you will be able to check out old
-revisions of the module.
-
-</P>
-<P>
-Advantages:
-
-</P>
-
-<UL>
-<LI>
-
-Checking out old revisions works correctly, as long as
-you use <SAMP>`-r<VAR>tag</VAR>'</SAMP> and not
<SAMP>`-D<VAR>date</VAR>'</SAMP>
-to retrieve the revisions.
-
-<LI>
-
-The log of changes is maintained intact.
-
-<LI>
-
-The revision numbers are not affected.
-</UL>
-
-<P>
-Disadvantages:
-
-</P>
-
-<UL>
-<LI>
-
-You cannot easily see the history of the file across the rename.
-
-<LI>
-
-Unless you use the <SAMP>`-r rev'</SAMP> (see section <A
HREF="cvs.html#SEC100">commit options</A>) flag when <VAR>new</VAR> is
committed its revision
-numbers will start at 1.0 again.
-</UL>
-
-
-
-<H1><A NAME="SEC71" HREF="cvs.html#TOC71">Moving and renaming
directories</A></H1>
-<P>
-<A NAME="IDX260"></A>
-<A NAME="IDX261"></A>
-<A NAME="IDX262"></A>
-
-</P>
-<P>
-If you want to be able to retrieve old versions of the
-module, you must move each file in the directory
-with the CVS commands. See section <A HREF="cvs.html#SEC68">The Normal way to
Rename</A>. The old, empty
-directory will remain inside the repository, but it
-will not appear in your workspace when you check out
-the module in the future.
-
-</P>
-<P>
-If you really want to rename or delete a directory, you
-can do it like this:
-
-</P>
-
-<OL>
-<LI>
-
-Inform everyone who has a copy of the module that the
-directory will be renamed. They should commit all
-their changes, and remove their working copies of the
-module, before you take the steps below.
-
-<LI>
-
-Rename the directory inside the repository.
-
-
-<PRE>
-$ cd $CVSROOT/<VAR>module</VAR>
-$ mv <VAR>old-dir</VAR> <VAR>new-dir</VAR>
-</PRE>
-
-<LI>
-
-Fix the CVS administrative files, if necessary (for
-instance if you renamed an entire module).
-
-<LI>
-
-Tell everyone that they can check out the module and continue
-working.
-
-</OL>
-
-<P>
-If someone had a working copy of the module the CVS commands will
-cease to work for him, until he removes the directory
-that disappeared inside the repository.
-
-</P>
-<P>
-It is almost always better to move the files in the
-directory instead of moving the directory. If you move the
-directory you are unlikely to be able to retrieve old
-releases correctly, since they probably depend on the
-name of the directories.
-
-</P>
-
-
-<H1><A NAME="SEC72" HREF="cvs.html#TOC72">History browsing</A></H1>
-<P>
-<A NAME="IDX263"></A>
-<A NAME="IDX264"></A>
-<A NAME="IDX265"></A>
-
-</P>
-
-<P>
-Once you have used CVS to store a version control
-history--what files have changed when, how, and by
-whom, there are a variety of mechanisms for looking
-through the history.
-
-</P>
-
-
-
-<H2><A NAME="SEC73" HREF="cvs.html#TOC73">Log messages</A></H2>
-
-<P>
-Whenever you commit a file you specify a log message.
-
-</P>
-<P>
-To look through the log messages which have been
-specified for every revision which has been committed,
-use the <CODE>cvs log</CODE> command (see section <A
HREF="cvs.html#SEC116">log--Print out log information for files</A>).
-
-</P>
-
-
-<H2><A NAME="SEC74" HREF="cvs.html#TOC74">The history database</A></H2>
-
-<P>
-You can use the history file (see section <A HREF="cvs.html#SEC149">The
history file</A>) to
-log various CVS actions. To retrieve the
-information from the history file, use the <CODE>cvs
-history</CODE> command (see section <A HREF="cvs.html#SEC110">history--Show
status of files and users</A>).
-
-</P>
-
-
-<H2><A NAME="SEC75" HREF="cvs.html#TOC75">User-defined logging</A></H2>
-
-<P>
-You can customize CVS to log various kinds of
-actions, in whatever manner you choose. These
-mechanisms operate by executing a script at various
-times. The script might append a message to a file
-listing the information and the programmer who created
-it, or send mail to a group of developers, or, perhaps,
-post a message to a particular newsgroup. To log
-commits, use the <TT>`loginfo'</TT> file (see section <A
HREF="cvs.html#SEC144">Loginfo</A>).
-To log commits, checkouts, exports, and tags,
-respectively, you can also use the <SAMP>`-i'</SAMP>,
-<SAMP>`-o'</SAMP>, <SAMP>`-e'</SAMP>, and <SAMP>`-t'</SAMP> options in the
-modules file. For a more flexible way of giving
-notifications to various users, which requires less in
-the way of keeping centralized scripts up to date, use
-the <CODE>cvs watch add</CODE> command (see section <A
HREF="cvs.html#SEC45">Telling CVS to notify you</A>); this command is useful
even if you are not
-using <CODE>cvs watch on</CODE>.
-
-</P>
-<P>
-<A NAME="IDX266"></A>
-The <TT>`taginfo'</TT> file defines programs to execute
-when someone executes a <CODE>tag</CODE> or <CODE>rtag</CODE>
-command. The <TT>`taginfo'</TT> file has the standard form
-for administrative files (see section <A HREF="cvs.html#SEC136">Reference
manual for the Administrative files</A>), where each line is a regular
expression
-followed by a command to execute. The arguments passed
-to the command are, in order, the <VAR>tagname</VAR>,
-<VAR>operation</VAR> (<CODE>add</CODE> for <CODE>tag</CODE>,
-<CODE>mov</CODE> for <CODE>tag -F</CODE>, and <CODE>del</CODE> for
-<CODE>tag -d</CODE>), <VAR>repository</VAR>, and any remaining are
-pairs of <VAR>filename</VAR> <VAR>revision</VAR>. A non-zero
-exit of the filter program will cause the tag to be
-aborted.
-
-</P>
-
-
-<H2><A NAME="SEC76" HREF="cvs.html#TOC76">Annotate command</A></H2>
-<P>
-<A NAME="IDX267"></A>
-
-</P>
-<P>
-<DL>
-<DT><U>Command:</U> <B>cvs annotate</B> <I>[<CODE>-lf</CODE>] [<CODE>-r
rev</CODE>|<CODE>-D date</CODE>] files ...</I>
-<DD><A NAME="IDX268"></A>
-
-</P>
-<P>
-For each file in <VAR>files</VAR>, print the head revision
-of the trunk, together with information on the last
-modification for each line. For example:
-
-</P>
-
-<PRE>
-$ cvs annotate ssfile
-Annotations for ssfile
-***************
-1.1 (mary 27-Mar-96): ssfile line 1
-1.2 (joe 28-Mar-96): ssfile line 2
-</PRE>
-
-<P>
-The file <TT>`ssfile'</TT> currently contains two lines.
-The <CODE>ssfile line 1</CODE> line was checked in by
-<CODE>mary</CODE> on March 27. Then, on March 28, <CODE>joe</CODE>
-added a line <CODE>ssfile line 2</CODE>, without modifying
-the <CODE>ssfile line 1</CODE> line. This report doesn't
-tell you anything about lines which have been deleted
-or replaced; you need to use <CODE>cvs diff</CODE> for that
-(see section <A HREF="cvs.html#SEC105">diff--Run diffs between revisions</A>).
-
-</P>
-</DL>
-
-<P>
-These standard options are available with
-<CODE>annotate</CODE> (see section <A HREF="cvs.html#SEC90">Common command
options</A>, for a complete
-description of them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Annotate the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
-<VAR>tag</VAR>'</SAMP> flags. If no matching revision is found,
-annotate the most recent revision (instead of ignoring
-the file).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory. See section <A
HREF="cvs.html#SEC60">Recursive behavior</A>.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Annotate revision <VAR>tag</VAR>.
-</DL>
-
-
-
-<H1><A NAME="SEC77" HREF="cvs.html#TOC77">Keyword substitution</A></H1>
-<P>
-<A NAME="IDX269"></A>
-<A NAME="IDX270"></A>
-<A NAME="IDX271"></A>
-
-</P>
-
-<P>
-As long as you edit source files inside your working
-copy of a module you can always find out the state of
-your files via <SAMP>`cvs status'</SAMP> and <SAMP>`cvs log'</SAMP>.
-But as soon as you export the files from your
-development environment it becomes harder to identify
-which revisions they are.
-
-</P>
-<P>
-RCS uses a mechanism known as <EM>keyword
-substitution</EM> (or <EM>keyword expansion</EM>) to help
-identifying the files. Embedded strings of the form
-<CODE>$<VAR>keyword</VAR>$</CODE> and
-<CODE>$<VAR>keyword</VAR>:...$</CODE> in a file are replaced
-with strings of the form
-<CODE>$<VAR>keyword</VAR>:<VAR>value</VAR>$</CODE> whenever you obtain
-a new revision of the file.
-
-</P>
-
-
-
-<H2><A NAME="SEC78" HREF="cvs.html#TOC78">RCS Keywords</A></H2>
-<P>
-<A NAME="IDX272"></A>
-
-</P>
-<P>
-This is a list of the keywords that RCS currently
-(in release 5.6.0.1) supports:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>$Author: ward $</CODE>
-<DD>
-<A NAME="IDX273"></A>
-
-The login name of the user who checked in the revision.
-
-<A NAME="IDX274"></A>
-<DT><CODE>$Date: 2009/06/08 20:46:55 $</CODE>
-<DD>
-The date and time (UTC) the revision was checked in.
-
-<A NAME="IDX275"></A>
-<DT><CODE>$Header: /web/www/www/software/cvs/manual/html_mono/Attic/cvs.html,v
1.3 2009/06/08 20:46:55 ward Exp $</CODE>
-<DD>
-A standard header containing the full pathname of the
-RCS file, the revision number, the date (UTC), the
-author, the state, and the locker (if locked). Files
-will normally never be locked when you use CVS.
-
-<A NAME="IDX276"></A>
-<DT><CODE>$Id: cvs.html,v 1.3 2009/06/08 20:46:55 ward Exp $</CODE>
-<DD>
-Same as <CODE>$Header:
/web/www/www/software/cvs/manual/html_mono/Attic/cvs.html,v 1.3 2009/06/08
20:46:55 ward Exp $</CODE>, except that the RCS
-filename is without a path.
-
-<A NAME="IDX277"></A>
-<DT><CODE>$Name: $</CODE>
-<DD>
-Tag name used to check out this file.
-
-<A NAME="IDX278"></A>
-<DT><CODE>$Locker: $</CODE>
-<DD>
-The login name of the user who locked the revision
-(empty if not locked, and thus almost always useless
-when you are using CVS).
-
-<A NAME="IDX279"></A>
-<DT><CODE>$Log: cvs.html,v $
-<DT><CODE>Revision 1.3 2009/06/08 20:46:55 ward
-<DT><CODE>changes that were lost from the CVS tree due to the savannah crash
of 2009/05/29
-<DT><CODE>
-<DT><CODE>Revision 1.2 2007/02/07 02:36:39 mattl
-<DT><CODE>Changed 'UNIX' to 'Unix' on request of SCO/dbe/RMS^rms ;)
-<DT><CODE>
-<DT><CODE>Revision 1.1 2003/11/07 20:55:32 sinuhe
-<DT><CODE>Add manual.
-<DT><CODE></CODE>
-<DD>
-The log message supplied during commit, preceded by a
-header containing the RCS filename, the revision
-number, the author, and the date (UTC). Existing log
-messages are <EM>not</EM> replaced. Instead, the new log
-message is inserted after <CODE>$Log: cvs.html,v $
-message is inserted after <CODE>Revision 1.2 2007/02/07 02:36:39 mattl
-message is inserted after <CODE>Changed 'UNIX' to 'Unix' on request of
SCO/dbe/RMS^rms ;)
-message is inserted after <CODE>
-message is inserted after <CODE>Revision 1.1 2003/11/07 20:55:32 sinuhe
-message is inserted after <CODE>Add manual.
-message is inserted after <CODE></CODE>.
-Each new line is prefixed with a <EM>comment leader</EM>
-which RCS guesses from the file name extension.
-It can be changed with <CODE>cvs admin -c</CODE>.
-See section <A HREF="cvs.html#SEC92">admin options</A>. This keyword is
useful for
-accumulating a complete change log in a source file,
-but for several reasons it can be problematic.
-See section <A HREF="cvs.html#SEC82">Problems with the $Log: cvs.html,v $
-See section <A HREF="cvs.html#SEC82">Problems with the Revision 1.2
2007/02/07 02:36:39 mattl
-See section <A HREF="cvs.html#SEC82">Problems with the Changed 'UNIX' to
'Unix' on request of SCO/dbe/RMS^rms ;)
-See section <A HREF="cvs.html#SEC82">Problems with the
-See section <A HREF="cvs.html#SEC82">Problems with the Revision 1.1
2003/11/07 20:55:32 sinuhe
-See section <A HREF="cvs.html#SEC82">Problems with the Add manual.
-See section <A HREF="cvs.html#SEC82">Problems with the keyword.</A>.
-
-<A NAME="IDX280"></A>
-<DT><CODE>$RCSfile: cvs.html,v $</CODE>
-<DD>
-The name of the RCS file without a path.
-
-<A NAME="IDX281"></A>
-<DT><CODE>$Revision: 1.3 $</CODE>
-<DD>
-The revision number assigned to the revision.
-
-<A NAME="IDX282"></A>
-<DT><CODE>$Source: /web/www/www/software/cvs/manual/html_mono/Attic/cvs.html,v
$</CODE>
-<DD>
-The full pathname of the RCS file.
-
-<A NAME="IDX283"></A>
-<DT><CODE>$State: Exp $</CODE>
-<DD>
-The state assigned to the revision. States can be
-assigned with <CODE>cvs admin -s</CODE>---See section <A
HREF="cvs.html#SEC92">admin options</A>.
-
-</DL>
-
-
-
-<H2><A NAME="SEC79" HREF="cvs.html#TOC79">Using keywords</A></H2>
-
-<P>
-To include a keyword string you simply include the
-relevant text string, such as <CODE>$Id: cvs.html,v 1.3 2009/06/08 20:46:55
ward Exp $</CODE>, inside the
-file, and commit the file. CVS will automatically
-expand the string as part of the commit operation.
-
-</P>
-<P>
-It is common to embed <CODE>$</CODE>Id$ string in the
-C source code. This example shows the first few lines
-of a typical file, after keyword substitution has been
-performed:
-
-</P>
-
-<PRE>
-static char *rcsid="$Id: cvs.html,v 1.3 2009/06/08 20:46:55 ward Exp $";
-/* The following lines will prevent <CODE>gcc</CODE> version 2.<VAR>x</VAR>
- from issuing an "unused variable" warning. */
-#if __GNUC__ == 2
-#define USE(var) static void * use_##var = (&use_##var, (void *) &var)
-USE (rcsid);
-#endif
-</PRE>
-
-<P>
-Even though a clever optimizing compiler could remove
-the unused variable <CODE>rcsid</CODE>, most compilers tend
-to include the string in the binary. Some compilers
-have a <CODE>#pragma</CODE> directive to include literal text
-in the binary.
-
-</P>
-<P>
-<A NAME="IDX284"></A>
-The <CODE>ident</CODE> command (which is part of the RCS
-package) can be used to extract keywords and their
-values from a file. This can be handy for text files,
-but it is even more useful for extracting keywords from
-binary files.
-
-</P>
-
-<PRE>
-$ ident samp.c
-samp.c:
- $Id: cvs.html,v 1.3 2009/06/08 20:46:55 ward Exp $
-$ gcc samp.c
-$ ident a.out
-a.out:
- $Id: cvs.html,v 1.3 2009/06/08 20:46:55 ward Exp $
-</PRE>
-
-<P>
-<A NAME="IDX285"></A>
-SCCS is another popular revision control system.
-It has a command, <CODE>what</CODE>, which is very similar to
-<CODE>ident</CODE> and used for the same purpose. Many sites
-without RCS have SCCS. Since <CODE>what</CODE>
-looks for the character sequence <CODE>@(#)</CODE> it is
-easy to include keywords that are detected by either
-command. Simply prefix the RCS keyword with the
-magic SCCS phrase, like this:
-
-</P>
-
-<PRE>
-static char *id="@(#) $Id: cvs.html,v 1.3 2009/06/08 20:46:55 ward Exp $";
-</PRE>
-
-
-
-<H2><A NAME="SEC80" HREF="cvs.html#TOC80">Avoiding substitution</A></H2>
-
-<P>
-Keyword substitution has its disadvantages. Sometimes
-you might want the literal text string
-<SAMP>`$'</SAMP>Author$ to appear inside a file without
-RCS interpreting it as a keyword and expanding it
-into something like <SAMP>`$'</SAMP>Author: ceder $.
-
-</P>
-<P>
-There is unfortunately no way to selectively turn off
-keyword substitution. You can use <SAMP>`-ko'</SAMP>
-(see section <A HREF="cvs.html#SEC81">Substitution modes</A>) to turn off
keyword
-substitution entirely.
-
-</P>
-<P>
-In many cases you can avoid using RCS keywords in
-the source, even though they appear in the final
-product. For example, the source for this manual
-contains <SAMP>address@hidden'</SAMP> whenever the text
-<SAMP>`$'</SAMP>Author$ should appear. In <CODE>nroff</CODE>
-and <CODE>troff</CODE> you can embed the null-character
-<CODE>\&</CODE> inside the keyword for a similar effect.
-
-</P>
-
-
-<H2><A NAME="SEC81" HREF="cvs.html#TOC81">Substitution modes</A></H2>
-<P>
-<A NAME="IDX286"></A>
-<A NAME="IDX287"></A>
-
-</P>
-<P>
-Each file has a stored default substitution mode, and
-each working directory copy of a file also has a
-substitution mode. The former is set by the <SAMP>`-k'</SAMP>
-option to <CODE>cvs add</CODE> and <CODE>cvs admin</CODE>; the
-latter is set by the -k or -A options to <CODE>cvs
-checkout</CODE> or <CODE>cvs update</CODE>. <CODE>cvs diff</CODE> also
-has a <SAMP>`-k'</SAMP> option. For some examples,
-See section <A HREF="cvs.html#SEC83">Handling binary files</A>.
-
-</P>
-<P>
-The modes available are:
-
-</P>
-<DL COMPACT>
-
-<DT><SAMP>`-kkv'</SAMP>
-<DD>
-Generate keyword strings using the default form, e.g.
-<CODE>$</CODE>Revision: 5.7 $ for the <CODE>Revision</CODE>
-keyword.
-
-<DT><SAMP>`-kkvl'</SAMP>
-<DD>
-Like <SAMP>`-kkv'</SAMP>, except that a locker's name is always
-inserted if the given revision is currently locked.
-This option is normally not useful when CVS is used.
-
-<DT><SAMP>`-kk'</SAMP>
-<DD>
-Generate only keyword names in keyword strings; omit
-their values. For example, for the <CODE>Revision</CODE>
-keyword, generate the string <CODE>$</CODE>Revision$
-instead of <CODE>$</CODE>Revision: 5.7 $. This option
-is useful to ignore differences due to keyword
-substitution when comparing different revisions of a
-file.
-
-<DT><SAMP>`-ko'</SAMP>
-<DD>
-Generate the old keyword string, present in the working
-file just before it was checked in. For example, for
-the <CODE>Revision</CODE> keyword, generate the string
-<CODE>$</CODE>Revision: 1.1 $ instead of
-<CODE>$</CODE>Revision: 5.7 $ if that is how the
-string appeared when the file was checked in.
-
-<DT><SAMP>`-kb'</SAMP>
-<DD>
-Like <SAMP>`-ko'</SAMP>, but also inhibit conversion of line
-endings between the canonical form in which they are
-stored in the repository (linefeed only), and the form
-appropriate to the operating system in use on the
-client. For systems, like unix, which use linefeed
-only to terminate lines, this is the same as
-<SAMP>`-ko'</SAMP>. For more information on binary files, see
-section <A HREF="cvs.html#SEC83">Handling binary files</A>.
-
-<DT><SAMP>`-kv'</SAMP>
-<DD>
-Generate only keyword values for keyword strings. For
-example, for the <CODE>Revision</CODE> keyword, generate the string
-<CODE>5.7</CODE> instead of <CODE>$</CODE>Revision: 5.7 $.
-This can help generate files in programming languages
-where it is hard to strip keyword delimiters like
-<CODE>$</CODE>Revision: $ from a string. However,
-further keyword substitution cannot be performed once
-the keyword names are removed, so this option should be
-used with care.
-
-One often would like to use <SAMP>`-kv'</SAMP> with <CODE>cvs
-export</CODE>---see section <A HREF="cvs.html#SEC108">export--Export sources
from CVS, similar to checkout</A>. But be aware that doesn't
-handle an export containing binary files correctly.
-
-</DL>
-
-
-
-<H2><A NAME="SEC82" HREF="cvs.html#TOC82">Problems with the $Log: cvs.html,v $
-<H2><A NAME="SEC82" HREF="cvs.html#TOC82">Problems with the Revision 1.2
2007/02/07 02:36:39 mattl
-<H2><A NAME="SEC82" HREF="cvs.html#TOC82">Problems with the Changed 'UNIX' to
'Unix' on request of SCO/dbe/RMS^rms ;)
-<H2><A NAME="SEC82" HREF="cvs.html#TOC82">Problems with the
-<H2><A NAME="SEC82" HREF="cvs.html#TOC82">Problems with the Revision 1.1
2003/11/07 20:55:32 sinuhe
-<H2><A NAME="SEC82" HREF="cvs.html#TOC82">Problems with the Add manual.
-<H2><A NAME="SEC82" HREF="cvs.html#TOC82">Problems with the keyword.</A></H2>
-
-<P>
-The <CODE>$</CODE>Log$ keyword is somewhat
-controversial. As long as you are working on your
-development system the information is easily accessible
-even if you do not use the <CODE>$</CODE>Log$
-keyword--just do a <CODE>cvs log</CODE>. Once you export
-the file the history information might be useless
-anyhow.
-
-</P>
-<P>
-A more serious concern is that RCS is not good at
-handling <CODE>$</CODE>Log$ entries when a branch is
-merged onto the main trunk. Conflicts often result
-from the merging operation.
-
-</P>
-<P>
-People also tend to "fix" the log entries in the file
-(correcting spelling mistakes and maybe even factual
-errors). If that is done the information from
-<CODE>cvs log</CODE> will not be consistent with the
-information inside the file. This may or may not be a
-problem in real life.
-
-</P>
-<P>
-It has been suggested that the <CODE>$</CODE>Log$
-keyword should be inserted <EM>last</EM> in the file, and
-not in the files header, if it is to be used at all.
-That way the long list of change messages will not
-interfere with everyday source file browsing.
-
-</P>
-
-
-<H1><A NAME="SEC83" HREF="cvs.html#TOC83">Handling binary files</A></H1>
-<P>
-<A NAME="IDX288"></A>
-
-</P>
-<P>
-There are two issues with using CVS to store
-binary files. The first is that CVS by default
-convert line endings between the canonical form in
-which they are stored in the repository (linefeed
-only), and the form appropriate to the operating system
-in use on the client (for example, carriage return
-followed by line feed for Windows NT).
-
-</P>
-<P>
-The second is that a binary file might happen to
-contain data which looks like a keyword (see section <A
HREF="cvs.html#SEC77">Keyword substitution</A>), so keyword expansion must be
turned
-off.
-
-</P>
-<P>
-The <SAMP>`-kb'</SAMP> option available with some CVS
-commands insures that neither line ending conversion
-nor keyword expansion will be done. If you are using
-an old version of RCS without this option, and you
-are using an operating system, such as unix, which
-terminates lines with linefeeds only, you can use
-<SAMP>`-ko'</SAMP> instead; if you are on another operating
-system, upgrade to a version of RCS, such as 5.7
-or later, which supports <SAMP>`-kb'</SAMP>.
-
-</P>
-<P>
-Here is an example of how you can create a new file
-using the <SAMP>`-kb'</SAMP> flag:
-
-</P>
-
-<PRE>
-$ echo '$Id: cvs.html,v 1.3 2009/06/08 20:46:55 ward Exp $' > kotest
-$ cvs add -kb -m"A test file" kotest
-$ cvs ci -m"First checkin; contains a keyword" kotest
-</PRE>
-
-<P>
-If a file accidentally gets added without <SAMP>`-kb'</SAMP>,
-one can use the <CODE>cvs admin</CODE> command to recover.
-For example:
-
-</P>
-
-<PRE>
-$ echo '$Id: cvs.html,v 1.3 2009/06/08 20:46:55 ward Exp $' > kotest
-$ cvs add -m"A test file" kotest
-$ cvs ci -m"First checkin; contains a keyword" kotest
-$ cvs admin -kb kotest
-$ cvs update -A kotest
-$ cvs commit -m "make it binary" kotest # For non-unix systems
-</PRE>
-
-<P>
-When you check in the file <TT>`kotest'</TT> the keywords
-are expanded. (Try the above example, and do a
-<CODE>cat kotest</CODE> after every command). The <CODE>cvs
-admin -kb</CODE> command sets the default keyword
-substitution method for this file, but it does not
-alter the working copy of the file that you have. The
-easiest way to get the unexpanded version of
-<TT>`kotest'</TT> is <CODE>cvs update -A</CODE>. If you need to
-cope with line endings (that is, you are using a
-CVS client on a non-unix system), then you need to
-check in a new copy of the file, as shown by the
-<CODE>cvs commit</CODE> command above.
-
-</P>
-<P>
-However, in using <CODE>cvs admin -k</CODE> to change the
-keyword expansion, be aware that the keyword expansion
-mode is not version controlled. This means that, for
-example, that if you have a text file in old releases,
-and a binary file with the same name in new releases,
-CVS provides no way to check out the file in text
-or binary mode depending on what version you are
-checking out. There is no good workaround for this
-problem.
-
-</P>
-<P>
-You can also set a default for whether <CODE>cvs add</CODE>
-and <CODE>cvs import</CODE> treat a file as binary based on
-its name; for example you could say that files who
-names end in <SAMP>`.exe'</SAMP> are binary. See section <A
HREF="cvs.html#SEC138">The cvswrappers file</A>.
-
-</P>
-
-
-<H1><A NAME="SEC84" HREF="cvs.html#TOC84">Revision management</A></H1>
-<P>
-<A NAME="IDX289"></A>
-
-</P>
-
-<P>
-If you have read this far, you probably have a pretty
-good grasp on what CVS can do for you. This
-chapter talks a little about things that you still have
-to decide.
-
-</P>
-<P>
-If you are doing development on your own using CVS
-you could probably skip this chapter. The questions
-this chapter takes up become more important when more
-than one person is working in a repository.
-
-</P>
-
-
-
-<H2><A NAME="SEC85" HREF="cvs.html#TOC85">When to commit?</A></H2>
-<P>
-<A NAME="IDX290"></A>
-<A NAME="IDX291"></A>
-<A NAME="IDX292"></A>
-
-</P>
-<P>
-Your group should decide which policy to use regarding
-commits. Several policies are possible, and as your
-experience with CVS grows you will probably find
-out what works for you.
-
-</P>
-<P>
-If you commit files too quickly you might commit files
-that do not even compile. If your partner updates his
-working sources to include your buggy file, he will be
-unable to compile the code. On the other hand, other
-persons will not be able to benefit from the
-improvements you make to the code if you commit very
-seldom, and conflicts will probably be more common.
-
-</P>
-<P>
-It is common to only commit files after making sure
-that they can be compiled. Some sites require that the
-files pass a test suite. Policies like this can be
-enforced using the commitinfo file
-(see section <A HREF="cvs.html#SEC141">Commitinfo</A>), but you should think
twice before
-you enforce such a convention. By making the
-development environment too controlled it might become
-too regimented and thus counter-productive to the real
-goal, which is to get software written.
-
-</P>
-
-
-<H1><A NAME="SEC86" HREF="cvs.html#TOC86">Reference manual for CVS
commands</A></H1>
-<P>
-<A NAME="IDX293"></A>
-<A NAME="IDX294"></A>
-<A NAME="IDX295"></A>
-
-</P>
-
-<P>
-This appendix describes how to invoke CVS, and
-describes in detail those subcommands of CVS which
-are not fully described elsewhere. To look up a
-particular subcommand, see section <A HREF="cvs.html#SEC155">Index</A>.
-
-</P>
-
-
-
-<H2><A NAME="SEC87" HREF="cvs.html#TOC87">Overall structure of CVS
commands</A></H2>
-<P>
-<A NAME="IDX296"></A>
-<A NAME="IDX297"></A>
-<A NAME="IDX298"></A>
-<A NAME="IDX299"></A>
-
-</P>
-<P>
-The overall format of all CVS commands is:
-
-</P>
-
-<PRE>
-cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
-</PRE>
-
-<DL COMPACT>
-
-<DT><CODE>cvs</CODE>
-<DD>
-The name of the CVS program.
-
-<DT><CODE>cvs_options</CODE>
-<DD>
-Some options that affect all sub-commands of CVS. These are
-described below.
-
-<DT><CODE>cvs_command</CODE>
-<DD>
-One of several different sub-commands. Some of the commands have
-aliases that can be used instead; those aliases are noted in the
-reference manual for that command. There are only two situations
-where you may omit <SAMP>`cvs_command'</SAMP>: <SAMP>`cvs -H'</SAMP> elicits a
-list of available commands, and <SAMP>`cvs -v'</SAMP> displays version
-information on CVS itself.
-
-<DT><CODE>command_options</CODE>
-<DD>
-Options that are specific for the command.
-
-<DT><CODE>command_args</CODE>
-<DD>
-Arguments to the commands.
-</DL>
-
-<P>
-There is unfortunately some confusion between
-<CODE>cvs_options</CODE> and <CODE>command_options</CODE>.
-<SAMP>`-l'</SAMP>, when given as a <CODE>cvs_option</CODE>, only
-affects some of the commands. When it is given as a
-<CODE>command_option</CODE> is has a different meaning, and
-is accepted by more commands. In other words, do not
-take the above categorization too seriously. Look at
-the documentation instead.
-
-</P>
-
-
-<H2><A NAME="SEC88" HREF="cvs.html#TOC88">Default options and the ~/.cvsrc
file</A></H2>
-<P>
-<A NAME="IDX300"></A>
-<A NAME="IDX301"></A>
-
-</P>
-<P>
-There are some <CODE>command_options</CODE> that are used so
-often that you might have set up an alias or some other
-means to make sure you always specify that option. One
-example (the one that drove the implementation of the
-.cvsrc support, actually) is that many people find the
-default output of the <SAMP>`diff'</SAMP> command to be very
-hard to read, and that either context diffs or unidiffs
-are much easier to understand.
-
-</P>
-<P>
-The <TT>`~/.cvsrc'</TT> file is a way that you can add
-default options to <CODE>cvs_commands</CODE> within cvs,
-instead of relying on aliases or other shell scripts.
-
-</P>
-<P>
-The format of the <TT>`~/.cvsrc'</TT> file is simple. The
-file is searched for a line that begins with the same
-name as the <CODE>cvs_command</CODE> being executed. If a
-match is found, then the remainder of the line is split
-up (at whitespace characters) into separate options and
-added to the command arguments <EM>before</EM> any
-options from the command line.
-
-</P>
-<P>
-If a command has two names (e.g., <CODE>checkout</CODE> and
-<CODE>co</CODE>), the official name, not necessarily the one
-used on the command line, will be used to match against
-the file. So if this is the contents of the user's
-<TT>`~/.cvsrc'</TT> file:
-
-</P>
-
-<PRE>
-log -N
-diff -u
-update -P
-co -P
-</PRE>
-
-<P>
-the command <SAMP>`cvs checkout foo'</SAMP> would have the
-<SAMP>`-P'</SAMP> option added to the arguments, as well as
-<SAMP>`cvs co foo'</SAMP>.
-
-</P>
-<P>
-With the example file above, the output from <SAMP>`cvs
-diff foobar'</SAMP> will be in unidiff format. <SAMP>`cvs diff
--c foobar'</SAMP> will provide context diffs, as usual.
-Getting "old" format diffs would be slightly more
-complicated, because <CODE>diff</CODE> doesn't have an option
-to specify use of the "old" format, so you would need
-<SAMP>`cvs -f diff foobar'</SAMP>.
-
-</P>
-<P>
-In place of the command name you can use <CODE>cvs</CODE> to
-specify global options (see section <A HREF="cvs.html#SEC89">Global
options</A>). For
-example the following line in <TT>`.cvsrc'</TT>
-
-</P>
-
-<PRE>
-cvs -z6
-</PRE>
-
-<P>
-causes CVS to use compression level 6
-
-</P>
-
-
-<H2><A NAME="SEC89" HREF="cvs.html#TOC89">Global options</A></H2>
-<P>
-<A NAME="IDX302"></A>
-<A NAME="IDX303"></A>
-<A NAME="IDX304"></A>
-
-</P>
-<P>
-The available <SAMP>`cvs_options'</SAMP> (that are given to the
-left of <SAMP>`cvs_command'</SAMP>) are:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b <VAR>bindir</VAR></CODE>
-<DD>
-<A NAME="IDX305"></A>
- <A NAME="IDX306"></A>
-
-Use <VAR>bindir</VAR> as the directory where RCS programs are
-located. Overrides the setting of the <CODE>$RCSBIN</CODE> environment
-variable and any precompiled directory. This parameter should be
-specified as an absolute pathname.
-
-<A NAME="IDX307"></A>
-<A NAME="IDX308"></A>
-<DT><CODE>-T <VAR>tempdir</VAR></CODE>
-<DD>
-Use <VAR>tempdir</VAR> as the directory where temporary files are
-located. Overrides the setting of the <CODE>$TMPDIR</CODE> environment
-variable and any precompiled directory. This parameter should be
-specified as an absolute pathname.
-
-<A NAME="IDX309"></A>
-<A NAME="IDX310"></A>
-<DT><CODE>-d <VAR>cvs_root_directory</VAR></CODE>
-<DD>
-Use <VAR>cvs_root_directory</VAR> as the root directory
-pathname of the repository. Overrides the setting of
-the <CODE>$CVSROOT</CODE> environment variable. See section <A
HREF="cvs.html#SEC15">The Repository</A>.
-
-<A NAME="IDX311"></A>
-<A NAME="IDX312"></A>
-<DT><CODE>-e <VAR>editor</VAR></CODE>
-<DD>
-Use <VAR>editor</VAR> to enter revision log information. Overrides the
-setting of the <CODE>$CVSEDITOR</CODE> and <CODE>$EDITOR</CODE> environment
variables.
-
-<DT><CODE>-f</CODE>
-<DD>
-Do not read the <TT>`~/.cvsrc'</TT> file. This
-option is most often used because of the
-non-orthogonality of the CVS option set. For
-example, the <SAMP>`cvs log'</SAMP> option <SAMP>`-N'</SAMP> (turn off
-display of tag names) does not have a corresponding
-option to turn the display on. So if you have
-<SAMP>`-N'</SAMP> in the <TT>`~/.cvsrc'</TT> entry for <SAMP>`log'</SAMP>,
-you may need to use <SAMP>`-f'</SAMP> to show the tag names.
-
-<DT><CODE>-H</CODE>
-<DD>
-Display usage information about the specified <SAMP>`cvs_command'</SAMP>
-(but do not actually execute the command). If you don't specify
-a command name, <SAMP>`cvs -H'</SAMP> displays a summary of all the
-commands available.
-
-<DT><CODE>-l</CODE>
-<DD>
-Do not log the cvs_command in the command history (but execute it
-anyway). See section <A HREF="cvs.html#SEC110">history--Show status of files
and users</A>, for information on command history.
-
-<A NAME="IDX313"></A>
-<DT><CODE>-n</CODE>
-<DD>
-Do not change any files. Attempt to execute the
-<SAMP>`cvs_command'</SAMP>, but only to issue reports; do not remove,
-update, or merge any existing files, or create any new files.
-
-<DT><CODE>-Q</CODE>
-<DD>
-Cause the command to be really quiet; the command will only
-generate output for serious problems.
-
-<DT><CODE>-q</CODE>
-<DD>
-Cause the command to be somewhat quiet; informational messages,
-such as reports of recursion through subdirectories, are
-suppressed.
-
-<A NAME="IDX314"></A>
-<DT><CODE>-r</CODE>
-<DD>
-Make new working files files read-only. Same effect
-as if the <CODE>$CVSREAD</CODE> environment variable is set
-(see section <A HREF="cvs.html#SEC151">All environment variables which affect
CVS</A>). The default is to
-make working files writable, unless watches are on
-(see section <A HREF="cvs.html#SEC43">Mechanisms to track who is editing
files</A>).
-
-<DT><CODE>-s <VAR>variable</VAR>=<VAR>value</VAR></CODE>
-<DD>
-Set a user variable (see section <A HREF="cvs.html#SEC150">Expansions in
administrative files</A>).
-
-<A NAME="IDX315"></A>
-<DT><CODE>-t</CODE>
-<DD>
-Trace program execution; display messages showing the steps of
-CVS activity. Particularly useful with <SAMP>`-n'</SAMP> to explore the
-potential impact of an unfamiliar command.
-
-<DT><CODE>-v</CODE>
-<DD>
-Display version and copyright information for CVS.
-
-<A NAME="IDX316"></A>
-<A NAME="IDX317"></A>
-<DT><CODE>-w</CODE>
-<DD>
-Make new working files read-write. Overrides the
-setting of the <CODE>$CVSREAD</CODE> environment variable.
-Files are created read-write by default, unless <CODE>$CVSREAD</CODE> is
-set or <SAMP>`-r'</SAMP> is given.
-
-<DT><CODE>-x</CODE>
-<DD>
-Encrypt all communication between the client and the
-server. Only has an effect on the CVS client. As
-of this writing, this is only implemented when using a
-Kerberos connection (see section <A HREF="cvs.html#SEC30">Direct connection
with kerberos</A>).
-Encryption support is not available by default; it must
-be enabled using a special configure option,
-<TT>`--enable-encryption'</TT>, when you build CVS.
-
-<DT><CODE>-z <VAR>gzip-level</VAR></CODE>
-<DD>
-Set the compression level. Only has an effect on the
-CVS client.
-
-</DL>
-
-
-
-<H2><A NAME="SEC90" HREF="cvs.html#TOC90">Common command options</A></H2>
-<P>
-<A NAME="IDX318"></A>
-<A NAME="IDX319"></A>
-
-</P>
-<P>
-This section describes the <SAMP>`command_options'</SAMP> that
-are available across several CVS commands. These
-options are always given to the right of
-<SAMP>`cvs_command'</SAMP>. Not all
-commands support all of these options; each option is
-only supported for commands where it makes sense.
-However, when a command has one of these options you
-can almost always count on the same behavior of the
-option as in other commands. (Other command options,
-which are listed with the individual commands, may have
-different behavior from one CVS command to the other).
-
-</P>
-<P>
-<STRONG>Warning:</STRONG> the <SAMP>`history'</SAMP> command is an exception;
it supports
-many options that conflict even with these standard options.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date_spec</VAR></CODE>
-<DD>
-<A NAME="IDX320"></A>
- <A NAME="IDX321"></A>
- <A NAME="IDX322"></A>
-
-Use the most recent revision no later than <VAR>date_spec</VAR>.
-<VAR>date_spec</VAR> is a single argument, a date description
-specifying a date in the past.
-
-The specification is <EM>sticky</EM> when you use it to make a
-private copy of a source file; that is, when you get a working
-file using <SAMP>`-D'</SAMP>, CVS records the date you specified, so that
-further updates in the same directory will use the same date
-(for more information on sticky tags/dates, see section <A
HREF="cvs.html#SEC54">Sticky tags</A>).
-
-<A NAME="IDX323"></A>
-<A NAME="IDX324"></A>
-A wide variety of date formats are supported by
-CVS. The <VAR>date_spec</VAR> is interpreted as being
-in the local timezone, unless a specific timezone is
-specified. Examples of valid date specifications
-include:
-
-
-<PRE>
- 1 month ago
- 2 hours ago
- 400000 seconds ago
- last year
- last Monday
- yesterday
- a fortnight ago
- 3/31/92 10:00:07 PST
- January 23, 1987 10:05pm
- 22:00 GMT
-</PRE>
-
-<SAMP>`-D'</SAMP> is available with the <CODE>checkout</CODE>,
-<CODE>diff</CODE>, <CODE>export</CODE>, <CODE>history</CODE>,
-<CODE>rdiff</CODE>, <CODE>rtag</CODE>, and <CODE>update</CODE> commands.
-(The <CODE>history</CODE> command uses this option in a
-slightly different way; see section <A HREF="cvs.html#SEC111">history
options</A>). Note
-that when specifying a date like <SAMP>`3/31/92'</SAMP> it is
-<CODE><VAR>month</VAR>/<VAR>day</VAR>/<VAR>year</VAR></CODE>. So
-<SAMP>`1/4/96'</SAMP> is January 4, not March 1.
-
-Remember to quote the argument to the <SAMP>`-D'</SAMP>
-flag so that your shell doesn't interpret spaces as
-argument separators. A command using the <SAMP>`-D'</SAMP>
-flag can look like this:
-
-
-<PRE>
-$ cvs diff -D "1 hour ago" cvs.texinfo
-</PRE>
-
-<A NAME="IDX325"></A>
-<DT><CODE>-f</CODE>
-<DD>
-When you specify a particular date or tag to CVS commands, they
-normally ignore files that do not contain the tag (or did not
-exist prior to the date) that you specified. Use the <SAMP>`-f'</SAMP> option
-if you want files retrieved even when there is no match for the
-tag or date. (The most recent revision of the file
-will be used).
-
-<SAMP>`-f'</SAMP> is available with these commands: <CODE>checkout</CODE>,
-<CODE>export</CODE>, <CODE>rdiff</CODE>, <CODE>rtag</CODE>, and
<CODE>update</CODE>.
-
-<STRONG>Warning:</STRONG> The <CODE>commit</CODE> command also has a
-<SAMP>`-f'</SAMP> option, but it has a different behavior for
-that command. See section <A HREF="cvs.html#SEC100">commit options</A>.
-
-<DT><CODE>-H</CODE>
-<DD>
-Help; describe the options available for this command. This is
-the only option supported for all CVS commands.
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Alter the default RCS processing of keywords.
-See section <A HREF="cvs.html#SEC77">Keyword substitution</A>, for the meaning
of
-<VAR>kflag</VAR>. Your <VAR>kflag</VAR> specification is
-<EM>sticky</EM> when you use it to create a private copy
-of a source file; that is, when you use this option
-with the <CODE>checkout</CODE> or <CODE>update</CODE> commands,
-CVS associates your selected <VAR>kflag</VAR> with the
-file, and continues to use it with future update
-commands on the same file until you specify otherwise.
-
-The <SAMP>`-k'</SAMP> option is available with the <CODE>add</CODE>,
-<CODE>checkout</CODE>, <CODE>diff</CODE> and
-<CODE>update</CODE> commands.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory, rather than
-recursing through subdirectories.
-
-<STRONG>Warning:</STRONG> this is not the same
-as the overall <SAMP>`cvs -l'</SAMP> option, which you can specify to the
-left of a cvs command!
-
-Available with the following commands: <CODE>checkout</CODE>,
-<CODE>commit</CODE>, <CODE>diff</CODE>, <CODE>export</CODE>, <CODE>log</CODE>,
-<CODE>remove</CODE>, <CODE>rdiff</CODE>, <CODE>rtag</CODE>,
-<CODE>status</CODE>, <CODE>tag</CODE>, and <CODE>update</CODE>.
-
-<A NAME="IDX326"></A>
-<A NAME="IDX327"></A>
-<DT><CODE>-m <VAR>message</VAR></CODE>
-<DD>
-Use <VAR>message</VAR> as log information, instead of
-invoking an editor.
-
-Available with the following commands: <CODE>add</CODE>,
-<CODE>commit</CODE> and <CODE>import</CODE>.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any checkout/commit/tag program. (A program can be
-specified to run on each of these activities, in the modules
-database (see section <A HREF="cvs.html#SEC137">The modules file</A>); this
option bypasses it).
-
-<STRONG>Warning:</STRONG> this is not the same as the overall <SAMP>`cvs
-n'</SAMP>
-option, which you can specify to the left of a cvs command!
-
-Available with the <CODE>checkout</CODE>, <CODE>commit</CODE>,
<CODE>export</CODE>,
-and <CODE>rtag</CODE> commands.
-
-<DT><CODE>-P</CODE>
-<DD>
-Prune (remove) directories that are empty after being updated, on
-<CODE>checkout</CODE>, or <CODE>update</CODE>. Normally, an empty directory
-(one that is void of revision-controlled files) is left alone.
-Specifying <SAMP>`-P'</SAMP> will cause these directories to be silently
-removed from your checked-out sources. This does not remove the
-directory from the repository, only from your checked out copy.
-Note that this option is implied by the <SAMP>`-r'</SAMP> or <SAMP>`-D'</SAMP>
-options of <CODE>checkout</CODE> and <CODE>export</CODE>.
-
-<DT><CODE>-p</CODE>
-<DD>
-Pipe the files retrieved from the repository to standard output,
-rather than writing them in the current directory. Available
-with the <CODE>checkout</CODE> and <CODE>update</CODE> commands.
-
-<DT><CODE>-W</CODE>
-<DD>
-Specify file names that should be filtered. You can
-use this option repeatedly. The spec can be a file
-name pattern of the same type that you can specify in
-the <TT>`.cvswrappers'</TT> file.
-Avaliable with the following commands: <CODE>import</CODE>,
-and <CODE>update</CODE>.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use the revision specified by the <VAR>tag</VAR> argument instead of the
-default <EM>head</EM> revision. As well as arbitrary tags defined
-with the <CODE>tag</CODE> or <CODE>rtag</CODE> command, two special tags are
-always available: <SAMP>`HEAD'</SAMP> refers to the most recent version
-available in the repository, and <SAMP>`BASE'</SAMP> refers to the
-revision you last checked out into the current working directory.
-
-The tag specification is sticky when you use this
-with <CODE>checkout</CODE> or <CODE>update</CODE> to make your own
-copy of a file: CVS remembers the tag and continues to use it on
-future update commands, until you specify otherwise (for more information
-on sticky tags/dates, see section <A HREF="cvs.html#SEC54">Sticky tags</A>).
The
-tag can be either a symbolic or numeric tag.
-See section <A HREF="cvs.html#SEC51">Tags--Symbolic revisions</A>.
-
-Specifying the <SAMP>`-q'</SAMP> global option along with the
-<SAMP>`-r'</SAMP> command option is often useful, to suppress
-the warning messages when the RCS history file
-does not contain the specified tag.
-
-<STRONG>Warning:</STRONG> this is not the same as the overall `cvs -r' option,
-which you can specify to the left of a cvs command!
-
-<SAMP>`-r'</SAMP> is available with the <CODE>checkout</CODE>,
<CODE>commit</CODE>,
-<CODE>diff</CODE>, <CODE>history</CODE>, <CODE>export</CODE>,
<CODE>rdiff</CODE>,
-<CODE>rtag</CODE>, and <CODE>update</CODE> commands.
-
-</DL>
-
-
-
-<H2><A NAME="SEC91" HREF="cvs.html#TOC91">admin--Administration front end for
rcs</A></H2>
-<P>
-<A NAME="IDX328"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Requires: repository, working directory.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: rcs
-</UL>
-
-<P>
-This is the CVS interface to assorted administrative RCS
-facilities, documented in rcs(1). <CODE>admin</CODE> simply passes
-all its options and arguments to the <CODE>rcs</CODE> command; it does
-no filtering or other processing. This command <EM>does</EM> work
-recursively, however, so extreme care should be used.
-
-</P>
-<P>
-If there is a group whose name matches a compiled in
-value which defaults to <CODE>cvsadmin</CODE>, only members
-of that group can use <CODE>cvs admin</CODE>. To disallow
-<CODE>cvs admin</CODE> for all users, create a group with no
-users in it.
-
-</P>
-
-
-
-<H3><A NAME="SEC92" HREF="cvs.html#TOC92">admin options</A></H3>
-
-<P>
-Not all valid <CODE>rcs</CODE> options are useful together
-with CVS. Some even makes it impossible to use
-CVS until you undo the effect!
-
-</P>
-<P>
-This description of the available options is based on
-the <SAMP>`rcs(1)'</SAMP> man page, but modified to suit
-readers that are more interrested in CVS than
-RCS.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-A<VAR>oldfile</VAR></CODE>
-<DD>
-Might not work together with CVS. Append the
-access list of <VAR>oldfile</VAR> to the access list of the
-RCS file.
-
-<DT><CODE>-a<VAR>logins</VAR></CODE>
-<DD>
-Might not work together with CVS. Append the
-login names appearing in the comma-separated list
-<VAR>logins</VAR> to the access list of the RCS file.
-
-<DT><CODE>-b[<VAR>rev</VAR>]</CODE>
-<DD>
-When used with bare RCS, this
-option sets the default branch to <VAR>rev</VAR>; in
-CVS sticky tags (see section <A HREF="cvs.html#SEC54">Sticky tags</A>) are a
better
-way to decide which branch you want to work on. With
-CVS, this option can be used to control behavior
-with respect to the vendor branch.
-
-<DT><CODE>-c<VAR>string</VAR></CODE>
-<DD>
-Useful with CVS. Sets the comment leader to
-<VAR>string</VAR>. The comment leader is printed before
-every log message line generated by the keyword
-<CODE>$</CODE>Log$ (see section <A HREF="cvs.html#SEC77">Keyword
substitution</A>).
-This is useful for programming languages without
-multi-line comments. RCS initially guesses the
-value of the comment leader from the file name
-extension when the file is first committed.
-
-<DT><CODE>-e[<VAR>logins</VAR>]</CODE>
-<DD>
-Might not work together with CVS. Erase the login
-names appearing in the comma-separated list
-<VAR>logins</VAR> from the access list of the RCS file. If
-<VAR>logins</VAR> is omitted, erase the entire access list.
-
-<DT><CODE>-I</CODE>
-<DD>
-Run interactively, even if the standard input is not a
-terminal.
-
-<DT><CODE>-i</CODE>
-<DD>
-Useless with CVS. When using bare RCS, this
-is used to create and initialize a new RCS file,
-without depositing a revision.
-
-<DT><CODE>-k<VAR>subst</VAR></CODE>
-<DD>
-Useful with CVS. Set the default keyword
-substitution to <VAR>subst</VAR>. See section <A
HREF="cvs.html#SEC77">Keyword substitution</A>. Giving an explicit
<SAMP>`-k'</SAMP> option to
-<CODE>cvs update</CODE>, <CODE>cvs export</CODE>, or <CODE>cvs
-checkout</CODE> overrides this default.
-
-<DT><CODE>-l[<VAR>rev</VAR>]</CODE>
-<DD>
-Lock the revision with number <VAR>rev</VAR>. If a branch
-is given, lock the latest revision on that branch. If
-<VAR>rev</VAR> is omitted, lock the latest revision on the
-default branch.
-
-This can be used in conjunction with the
-<TT>`rcslock.pl'</TT> script in the <TT>`contrib'</TT>
-directory of the CVS source distribution to
-provide reserved checkouts (where only one user can be
-editing a given file at a time). See the comments in
-that file for details (and see the <TT>`README'</TT> file
-in that directory for disclaimers about the unsupported
-nature of contrib). According to comments in that
-file, locking must set to strict (which is the default).
-
-<DT><CODE>-L</CODE>
-<DD>
-Set locking to strict. Strict locking means that the
-owner of an RCS file is not exempt from locking for
-checkin. For use with CVS, strict locking must be
-set; see the discussion under the <SAMP>`-l'</SAMP> option above.
-
-<A NAME="IDX329"></A>
-<A NAME="IDX330"></A>
-<A NAME="IDX331"></A>
-<A NAME="IDX332"></A>
-<A NAME="IDX333"></A>
-<DT><CODE>-m<VAR>rev</VAR>:<VAR>msg</VAR></CODE>
-<DD>
-Replace the log message of revision <VAR>rev</VAR> with
-<VAR>msg</VAR>.
-
-<DT><CODE>-N<VAR>name</VAR>[:[<VAR>rev</VAR>]]</CODE>
-<DD>
-Act like <SAMP>`-n'</SAMP>, except override any previous
-assignment of <VAR>name</VAR>.
-
-<DT><CODE>-n<VAR>name</VAR>[:[<VAR>rev</VAR>]]</CODE>
-<DD>
-Associate the symbolic name <VAR>name</VAR> with the branch
-or revision <VAR>rev</VAR>. It is normally better to use
-<SAMP>`cvs tag'</SAMP> or <SAMP>`cvs rtag'</SAMP> instead. Delete the
-symbolic name if both <SAMP>`:'</SAMP> and <VAR>rev</VAR> are
-omitted; otherwise, print an error message if
-<VAR>name</VAR> is already associated with another number.
-If <VAR>rev</VAR> is symbolic, it is expanded before
-association. A <VAR>rev</VAR> consisting of a branch number
-followed by a <SAMP>`.'</SAMP> stands for the current latest
-revision in the branch. A <SAMP>`:'</SAMP> with an empty
-<VAR>rev</VAR> stands for the current latest revision on the
-default branch, normally the trunk. For example,
-<SAMP>`rcs -n<VAR>name</VAR>: RCS/*'</SAMP> associates <VAR>name</VAR> with the
-current latest revision of all the named RCS files;
-this contrasts with <SAMP>`rcs -n<VAR>name</VAR>:$ RCS/*'</SAMP> which
-associates <VAR>name</VAR> with the revision numbers
-extracted from keyword strings in the corresponding
-working files.
-
-<A NAME="IDX334"></A>
-<A NAME="IDX335"></A>
-<A NAME="IDX336"></A>
-<DT><CODE>-o<VAR>range</VAR></CODE>
-<DD>
-Potentially useful, but dangerous, with CVS (see below).
-Deletes (<EM>outdates</EM>) the revisions given by
-<VAR>range</VAR>. A range consisting of a single revision
-number means that revision. A range consisting of a
-branch number means the latest revision on that branch.
-A range of the form <SAMP>`<VAR>rev1</VAR>:<VAR>rev2</VAR>'</SAMP> means
-revisions <VAR>rev1</VAR> to <VAR>rev2</VAR> on the same branch,
-<SAMP>`:<VAR>rev</VAR>'</SAMP> means from the beginning of the
-branch containing <VAR>rev</VAR> up to and including
-<VAR>rev</VAR>, and <SAMP>`<VAR>rev</VAR>:'</SAMP> means from revision
-<VAR>rev</VAR> to the end of the branch containing
-<VAR>rev</VAR>. None of the outdated revisions may have
-branches or locks.
-
-Due to the way CVS handles branches <VAR>rev</VAR>
-cannot be specified symbolically if it is a branch.
-See section <A HREF="cvs.html#SEC153">Magic branch numbers</A>, for an
explanation.
-
-Make sure that no-one has checked out a copy of the
-revision you outdate. Strange things will happen if he
-starts to edit it and tries to check it back in. For
-this reason, this option is not a good way to take back
-a bogus commit; commit a new revision undoing the bogus
-change instead (see section <A HREF="cvs.html#SEC58">Merging differences
between any two revisions</A>).
-
-<DT><CODE>-q</CODE>
-<DD>
-Run quietly; do not print diagnostics.
-
-<DT><CODE>-s<VAR>state</VAR>[:<VAR>rev</VAR>]</CODE>
-<DD>
-Useful with CVS. Set the state attribute of the
-revision <VAR>rev</VAR> to <VAR>state</VAR>. If <VAR>rev</VAR> is a
-branch number, assume the latest revision on that
-branch. If <VAR>rev</VAR> is omitted, assume the latest
-revision on the default branch. Any identifier is
-acceptable for <VAR>state</VAR>. A useful set of states is
-<SAMP>`Exp'</SAMP> (for experimental), <SAMP>`Stab'</SAMP> (for
-stable), and <SAMP>`Rel'</SAMP> (for released). By default,
-the state of a new revision is set to <SAMP>`Exp'</SAMP> when
-it is created. The state is visible in the output from
-<VAR>cvs log</VAR> (see section <A HREF="cvs.html#SEC116">log--Print out log
information for files</A>), and in the
-<SAMP>`$'</SAMP>Log$ and <SAMP>`$'</SAMP>State$ keywords
-(see section <A HREF="cvs.html#SEC77">Keyword substitution</A>). Note that CVS
-uses the <CODE>dead</CODE> state for its own purposes; to
-take a file to or from the <CODE>dead</CODE> state use
-commands like <CODE>cvs remove</CODE> and <CODE>cvs add</CODE>, not
-<CODE>cvs admin -s</CODE>.
-
-<DT><CODE>-t[<VAR>file</VAR>]</CODE>
-<DD>
-Useful with CVS. Write descriptive text from the
-contents of the named <VAR>file</VAR> into the RCS file,
-deleting the existing text. The <VAR>file</VAR> pathname
-may not begin with <SAMP>`-'</SAMP>. If <VAR>file</VAR> is omitted,
-obtain the text from standard input, terminated by
-end-of-file or by a line containing <SAMP>`.'</SAMP> by itself.
-Prompt for the text if interaction is possible; see
-<SAMP>`-I'</SAMP>. The descriptive text can be seen in the
-output from <SAMP>`cvs log'</SAMP> (see section <A
HREF="cvs.html#SEC116">log--Print out log information for files</A>).
-
-<DT><CODE>-t-<VAR>string</VAR></CODE>
-<DD>
-Similar to <SAMP>`-t<VAR>file</VAR>'</SAMP>. Write descriptive text
-from the <VAR>string</VAR> into the RCS file, deleting
-the existing text.
-
-<DT><CODE>-U</CODE>
-<DD>
-Set locking to non-strict. Non-strict locking means
-that the owner of a file need not lock a revision for
-checkin. For use with CVS, strict locking must be
-set; see the discussion under the <SAMP>`-l'</SAMP> option
-above.
-
-<DT><CODE>-u[<VAR>rev</VAR>]</CODE>
-<DD>
-See the option <SAMP>`-l'</SAMP> above, for a discussion of
-using this option with CVS. Unlock the revision
-with number <VAR>rev</VAR>. If a branch is given, unlock
-the latest revision on that branch. If <VAR>rev</VAR> is
-omitted, remove the latest lock held by the caller.
-Normally, only the locker of a revision may unlock it.
-Somebody else unlocking a revision breaks the lock.
-This causes a mail message to be sent to the original
-locker. The message contains a commentary solicited
-from the breaker. The commentary is terminated by
-end-of-file or by a line containing <CODE>.</CODE> by itself.
-
-<DT><CODE>-V<VAR>n</VAR></CODE>
-<DD>
-Emulate RCS version <VAR>n</VAR>. Use -V<VAR>n</VAR> to make
-an RCS file acceptable to RCS version <VAR>n</VAR>
-by discarding information that would confuse version
-<VAR>n</VAR>.
-
-<DT><CODE>-x<VAR>suffixes</VAR></CODE>
-<DD>
-Useless with CVS. Use <VAR>suffixes</VAR> to
-characterize RCS files.
-</DL>
-
-
-
-<H3><A NAME="SEC93" HREF="cvs.html#TOC93">admin examples</A></H3>
-
-
-
-<H4><A NAME="SEC94" HREF="cvs.html#TOC94">Outdating is dangerous</A></H4>
-
-<P>
-First, an example of how <EM>not</EM> to use the
-<CODE>admin</CODE> command. It is included to stress the
-fact that this command can be quite dangerous unless
-you know <EM>exactly</EM> what you are doing.
-
-</P>
-<P>
-The <SAMP>`-o'</SAMP> option can be used to <EM>outdate</EM> old revisions
-from the history file. If you are short on disc this option
-might help you. But think twice before using it--there is no
-way short of restoring the latest backup to undo this command!
-
-</P>
-<P>
-The next line is an example of a command that you would
-<EM>not</EM> like to execute.
-
-</P>
-
-<PRE>
-$ cvs admin -o:R_1_02 .
-</PRE>
-
-<P>
-The above command will delete all revisions up to, and
-including, the revision that corresponds to the tag
-R_1_02. But beware! If there are files that have not
-changed between R_1_02 and R_1_03 the file will have
-<EM>the same</EM> numerical revision number assigned to
-the tags R_1_02 and R_1_03. So not only will it be
-impossible to retrieve R_1_02; R_1_03 will also have to
-be restored from the tapes!
-
-</P>
-
-
-<H4><A NAME="SEC95" HREF="cvs.html#TOC95">Comment leaders</A></H4>
-<P>
-<A NAME="IDX337"></A>
-<A NAME="IDX338"></A>
-<A NAME="IDX339"></A>
-
-</P>
-<P>
-If you use the <CODE>$</CODE>Log$ keyword and you do
-not agree with the guess for comment leader that
-CVS has done, you can enforce your will with
-<CODE>cvs admin -c</CODE>. This might be suitable for
-<CODE>nroff</CODE> source:
-
-</P>
-
-<PRE>
-$ cvs admin -c'.\" ' *.man
-$ rm *.man
-$ cvs update
-</PRE>
-
-<P>
-The two last steps are to make sure that you get the
-versions with correct comment leaders in your working
-files.
-
-</P>
-
-
-<H2><A NAME="SEC96" HREF="cvs.html#TOC96">checkout--Check out sources for
editing</A></H2>
-<P>
-<A NAME="IDX340"></A>
-<A NAME="IDX341"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: checkout [options] modules...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: working directory.
-<LI>
-
-Synonyms: co, get
-</UL>
-
-<P>
-Make a working directory containing copies of the
-source files specified by <VAR>modules</VAR>. You must execute
-<CODE>checkout</CODE> before using most of the other CVS
-commands, since most of them operate on your working
-directory.
-
-</P>
-<P>
-The <VAR>modules</VAR> part of the command are either
-symbolic names for some
-collection of source directories and files, or paths to
-directories or files in the repository. The symbolic
-names are defined in the <SAMP>`modules'</SAMP> file.
-See section <A HREF="cvs.html#SEC137">The modules file</A>.
-
-</P>
-<P>
-Depending on the modules you specify, <CODE>checkout</CODE> may
-recursively create directories and populate them with
-the appropriate source files. You can then edit these
-source files at any time (regardless of whether other
-software developers are editing their own copies of the
-sources); update them to include new changes applied by
-others to the source repository; or commit your work as
-a permanent change to the source repository.
-
-</P>
-<P>
-Note that <CODE>checkout</CODE> is used to create
-directories. The top-level directory created is always
-added to the directory where <CODE>checkout</CODE> is
-invoked, and usually has the same name as the specified
-module. In the case of a module alias, the created
-sub-directory may have a different name, but you can be
-sure that it will be a sub-directory, and that
-<CODE>checkout</CODE> will show the relative path leading to
-each file as it is extracted into your private work
-area (unless you specify the <SAMP>`-Q'</SAMP> global option).
-
-</P>
-<P>
-The files created by <CODE>checkout</CODE> are created
-read-write, unless the <SAMP>`-r'</SAMP> option to CVS
-(see section <A HREF="cvs.html#SEC89">Global options</A>) is specified, the
-<CODE>CVSREAD</CODE> environment variable is specified
-(see section <A HREF="cvs.html#SEC151">All environment variables which affect
CVS</A>), or a watch is in
-effect for that file (see section <A HREF="cvs.html#SEC43">Mechanisms to track
who is editing files</A>).
-
-</P>
-<P>
-Running <CODE>checkout</CODE> on a directory that was already
-built by a prior <CODE>checkout</CODE> is also permitted, and
-has the same effect as specifying the <SAMP>`-d'</SAMP> option
-to the <CODE>update</CODE> command, that is, any new
-directories that have been created in the repository
-will appear in your work area. See section <A
HREF="cvs.html#SEC132">update--Bring work tree in sync with repository</A>.
-
-</P>
-<P>
-For the output produced by the <CODE>checkout</CODE> command
-see section <A HREF="cvs.html#SEC134">update output</A>.
-
-</P>
-
-
-
-<H3><A NAME="SEC97" HREF="cvs.html#TOC97">checkout options</A></H3>
-
-<P>
-These standard options are supported by <CODE>checkout</CODE>
-(see section <A HREF="cvs.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-This option is sticky, and implies <SAMP>`-P'</SAMP>. See
-section <A HREF="cvs.html#SEC54">Sticky tags</A>, for more information on
sticky tags/dates.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
-<VAR>tag</VAR>'</SAMP> flags. If no matching revision is found,
-retrieve the most recent revision (instead of ignoring
-the file).
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Process RCS keywords according to <VAR>kflag</VAR>. See
-co(1). This option is sticky; future updates of
-this file in this working directory will use the same
-<VAR>kflag</VAR>. The <CODE>status</CODE> command can be viewed
-to see the sticky options. See section <A
HREF="cvs.html#SEC128">status--Display status information on checked out
files</A>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any checkout program (as specified
-with the <SAMP>`-o'</SAMP> option in the modules file;
-see section <A HREF="cvs.html#SEC137">The modules file</A>).
-
-<DT><CODE>-P</CODE>
-<DD>
-Prune empty directories.
-
-<DT><CODE>-p</CODE>
-<DD>
-Pipe files to the standard output.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use revision <VAR>tag</VAR>. This option is sticky, and implies
<SAMP>`-P'</SAMP>.
-See section <A HREF="cvs.html#SEC54">Sticky tags</A>, for more information on
sticky tags/dates.
-</DL>
-
-<P>
-In addition to those, you can use these special command
-options with <CODE>checkout</CODE>:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-A</CODE>
-<DD>
-Reset any sticky tags, dates, or <SAMP>`-k'</SAMP> options.
-See section <A HREF="cvs.html#SEC54">Sticky tags</A>, for more information on
sticky tags/dates.
-
-<DT><CODE>-c</CODE>
-<DD>
-Copy the module file, sorted, to the standard output,
-instead of creating or modifying any files or
-directories in your working directory.
-
-<DT><CODE>-d <VAR>dir</VAR></CODE>
-<DD>
-Create a directory called <VAR>dir</VAR> for the working
-files, instead of using the module name. Unless you
-also use <SAMP>`-N'</SAMP>, the paths created under <VAR>dir</VAR>
-will be as short as possible.
-
-<DT><CODE>-j <VAR>tag</VAR></CODE>
-<DD>
-With two <SAMP>`-j'</SAMP> options, merge changes from the
-revision specified with the first <SAMP>`-j'</SAMP> option to
-the revision specified with the second <SAMP>`j'</SAMP> option,
-into the working directory.
-
-With one <SAMP>`-j'</SAMP> option, merge changes from the
-ancestor revision to the revision specified with the
-<SAMP>`-j'</SAMP> option, into the working directory. The
-ancestor revision is the common ancestor of the
-revision which the working directory is based on, and
-the revision specified in the <SAMP>`-j'</SAMP> option.
-
-In addition, each -j option can contain an optional
-date specification which, when used with branches, can
-limit the chosen revision to one within a specific
-date. An optional date is specified by adding a colon
-(:) to the tag:
-<SAMP>`-j<VAR>Symbolic_Tag</VAR>:<VAR>Date_Specifier</VAR>'</SAMP>.
-
-See section <A HREF="cvs.html#SEC55">Merging</A>.
-
-<DT><CODE>-N</CODE>
-<DD>
-Only useful together with <SAMP>`-d <VAR>dir</VAR>'</SAMP>. With this
-option, CVS will not shorten module paths in your
-working directory. (Normally, CVS shortens paths as
-much as possible when you specify an explicit target
-directory).
-
-<DT><CODE>-s</CODE>
-<DD>
-Like <SAMP>`-c'</SAMP>, but include the status of all modules,
-and sort it by the status string. See section <A HREF="cvs.html#SEC137">The
modules file</A>, for
-info about the <SAMP>`-s'</SAMP> option that is used inside the
-modules file to set the module status.
-</DL>
-
-
-
-<H3><A NAME="SEC98" HREF="cvs.html#TOC98">checkout examples</A></H3>
-
-<P>
-Get a copy of the module <SAMP>`tc'</SAMP>:
-
-</P>
-
-<PRE>
-$ cvs checkout tc
-</PRE>
-
-<P>
-Get a copy of the module <SAMP>`tc'</SAMP> as it looked one day
-ago:
-
-</P>
-
-<PRE>
-$ cvs checkout -D yesterday tc
-</PRE>
-
-
-
-<H2><A NAME="SEC99" HREF="cvs.html#TOC99">commit--Check files into the
repository</A></H2>
-<P>
-<A NAME="IDX342"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Version 1.3 Synopsis: commit [-lnR] [-m 'log_message' |
--f file] [-r revision] [files...]
-<LI>
-
-Version 1.3.1 Synopsis: commit [-lnRf] [-m 'log_message' |
--F file] [-r revision] [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: ci
-</UL>
-
-<P>
-<STRONG>Warning:</STRONG> The <SAMP>`-f <VAR>file</VAR>'</SAMP> option will
-probably be renamed to <SAMP>`-F <VAR>file</VAR>'</SAMP>, and <SAMP>`-f'</SAMP>
-will be given a new behavior in future releases of CVS.
-
-</P>
-<P>
-Use <CODE>commit</CODE> when you want to incorporate changes
-from your working source files into the source
-repository.
-
-</P>
-<P>
-If you don't specify particular files to commit, all of
-the files in your working current directory are
-examined. <CODE>commit</CODE> is careful to change in the
-repository only those files that you have really
-changed. By default (or if you explicitly specify the
-<SAMP>`-R'</SAMP> option), files in subdirectories are also
-examined and committed if they have changed; you can
-use the <SAMP>`-l'</SAMP> option to limit <CODE>commit</CODE> to the
-current directory only.
-
-</P>
-<P>
-<CODE>commit</CODE> verifies that the selected files are up
-to date with the current revisions in the source
-repository; it will notify you, and exit without
-committing, if any of the specified files must be made
-current first with <CODE>update</CODE> (see section <A
HREF="cvs.html#SEC132">update--Bring work tree in sync with repository</A>).
-<CODE>commit</CODE> does not call the <CODE>update</CODE> command
-for you, but rather leaves that for you to do when the
-time is right.
-
-</P>
-<P>
-When all is well, an editor is invoked to allow you to
-enter a log message that will be written to one or more
-logging programs (see section <A HREF="cvs.html#SEC137">The modules file</A>,
and see section <A HREF="cvs.html#SEC144">Loginfo</A>)
-and placed in the RCS history file inside the
-repository. This log message can be retrieved with the
-<CODE>log</CODE> command; See section <A HREF="cvs.html#SEC116">log--Print out
log information for files</A>. You can specify the
-log message on the command line with the <SAMP>`-m
-<VAR>message</VAR>'</SAMP> option, and thus avoid the editor invocation,
-or use the <SAMP>`-f <VAR>file</VAR>'</SAMP> option to specify
-that the argument file contains the log message.
-
-</P>
-
-
-
-<H3><A NAME="SEC100" HREF="cvs.html#TOC100">commit options</A></H3>
-
-<P>
-These standard options are supported by <CODE>commit</CODE>
-(see section <A HREF="cvs.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any module program.
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-
-<DT><CODE>-r <VAR>revision</VAR></CODE>
-<DD>
-Commit to <VAR>revision</VAR>. <VAR>revision</VAR> must be
-either a branch, or a revision on the main trunk that
-is higher than any existing revision number. You
-cannot commit to a specific revision on a branch.
-</DL>
-
-<P>
-<CODE>commit</CODE> also supports these options:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-F <VAR>file</VAR></CODE>
-<DD>
-This option is present in CVS releases 1.3-s3 and
-later. Read the log message from <VAR>file</VAR>, instead
-of invoking an editor.
-
-<DT><CODE>-f</CODE>
-<DD>
-This option is present in CVS 1.3-s3 and later releases
-of CVS. Note that this is not the standard behavior of
-the <SAMP>`-f'</SAMP> option as defined in See section <A
HREF="cvs.html#SEC90">Common command options</A>.
-
-Force CVS to commit a new revision even if you haven't
-made any changes to the file. If the current revision
-of <VAR>file</VAR> is 1.7, then the following two commands
-are equivalent:
-
-
-<PRE>
-$ cvs commit -f <VAR>file</VAR>
-$ cvs commit -r 1.8 <VAR>file</VAR>
-</PRE>
-
-<DT><CODE>-f <VAR>file</VAR></CODE>
-<DD>
-This option is present in CVS releases 1.3, 1.3-s1 and
-1.3-s2. Note that this is not the standard behavior of
-the <SAMP>`-f'</SAMP> option as defined in See section <A
HREF="cvs.html#SEC90">Common command options</A>.
-
-Read the log message from <VAR>file</VAR>, instead
-of invoking an editor.
-
-<DT><CODE>-m <VAR>message</VAR></CODE>
-<DD>
-Use <VAR>message</VAR> as the log message, instead of
-invoking an editor.
-</DL>
-
-
-
-<H3><A NAME="SEC101" HREF="cvs.html#TOC101">commit examples</A></H3>
-
-
-
-<H4><A NAME="SEC102" HREF="cvs.html#TOC102">New major release number</A></H4>
-
-<P>
-When you make a major release of your product, you
-might want the revision numbers to track your major
-release number. You should normally not care about
-the revision numbers, but this is a thing that many
-people want to do, and it can be done without doing any
-harm.
-
-</P>
-<P>
-To bring all your files up to the RCS revision 3.0
-(including those that haven't changed), you might do:
-
-</P>
-
-<PRE>
-$ cvs commit -r 3.0
-</PRE>
-
-<P>
-Note that it is generally a bad idea to try to make the
-RCS revision number equal to the current release number
-of your product. You should think of the revision
-number as an internal number that the CVS package
-maintains, and that you generally never need to care
-much about. Using the <CODE>tag</CODE> and <CODE>rtag</CODE>
-commands you can give symbolic names to the releases
-instead. See section <A HREF="cvs.html#SEC130">tag--Add a symbolic tag to
checked out versions of files</A> and See section <A
HREF="cvs.html#SEC126">rtag--Add a symbolic tag to a module</A>.
-
-</P>
-<P>
-Note that the number you specify with <SAMP>`-r'</SAMP> must be
-larger than any existing revision number. That is, if
-revision 3.0 exists, you cannot <SAMP>`cvs commit
--r 1.3'</SAMP>.
-
-</P>
-
-
-<H4><A NAME="SEC103" HREF="cvs.html#TOC103">Committing to a branch</A></H4>
-
-<P>
-You can commit to a branch revision (one that has an
-even number of dots) with the <SAMP>`-r'</SAMP> option. To
-create a branch revision, use the <SAMP>`-b'</SAMP> option
-of the <CODE>rtag</CODE> or <CODE>tag</CODE> commands (see section <A
HREF="cvs.html#SEC130">tag--Add a symbolic tag to checked out versions of
files</A>
-or see section <A HREF="cvs.html#SEC126">rtag--Add a symbolic tag to a
module</A>). Then, either <CODE>checkout</CODE> or
-<CODE>update</CODE> can be used to base your sources on the
-newly created branch. From that point on, all
-<CODE>commit</CODE> changes made within these working sources
-will be automatically added to a branch revision,
-thereby not disturbing main-line development in any
-way. For example, if you had to create a patch to the
-1.2 version of the product, even though the 2.0 version
-is already under development, you might do:
-
-</P>
-
-<PRE>
-$ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
-$ cvs checkout -r FCS1_2_Patch product_module
-$ cd product_module
-[[ hack away ]]
-$ cvs commit
-</PRE>
-
-<P>
-This works automatically since the <SAMP>`-r'</SAMP> option is
-sticky.
-
-</P>
-
-
-<H4><A NAME="SEC104" HREF="cvs.html#TOC104">Creating the branch after
editing</A></H4>
-
-<P>
-Say you have been working on some extremely
-experimental software, based on whatever revision you
-happened to checkout last week. If others in your
-group would like to work on this software with you, but
-without disturbing main-line development, you could
-commit your change to a new branch. Others can then
-checkout your experimental stuff and utilize the full
-benefit of CVS conflict resolution. The scenario might
-look like:
-
-</P>
-
-<PRE>
-[[ hacked sources are present ]]
-$ cvs tag -b EXPR1
-$ cvs update -r EXPR1
-$ cvs commit
-</PRE>
-
-<P>
-The <CODE>update</CODE> command will make the <SAMP>`-r
-EXPR1'</SAMP> option sticky on all files. Note that your
-changes to the files will never be removed by the
-<CODE>update</CODE> command. The <CODE>commit</CODE> will
-automatically commit to the correct branch, because the
-<SAMP>`-r'</SAMP> is sticky. You could also do like this:
-
-</P>
-
-<PRE>
-[[ hacked sources are present ]]
-$ cvs tag -b EXPR1
-$ cvs commit -r EXPR1
-</PRE>
-
-<P>
-but then, only those files that were changed by you
-will have the <SAMP>`-r EXPR1'</SAMP> sticky flag. If you hack
-away, and commit without specifying the <SAMP>`-r EXPR1'</SAMP>
-flag, some files may accidentally end up on the main
-trunk.
-
-</P>
-<P>
-To work with you on the experimental change, others
-would simply do
-
-</P>
-
-<PRE>
-$ cvs checkout -r EXPR1 whatever_module
-</PRE>
-
-
-
-<H2><A NAME="SEC105" HREF="cvs.html#TOC105">diff--Run diffs between
revisions</A></H2>
-<P>
-<A NAME="IDX343"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: diff [-l] [rcsdiff_options] [[-r rev1 | -D date1] [-r rev2 | -D
date2]] [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-The <CODE>diff</CODE> command is used to compare different
-revisions of files. The default action is to compare
-your working files with the revisions they were based
-on, and report any differences that are found.
-
-</P>
-<P>
-If any file names are given, only those files are
-compared. If any directories are given, all files
-under them will be compared.
-
-</P>
-<P>
-The exit status will be 0 if no differences were found,
-1 if some differences were found, and 2 if any error
-occurred.
-
-</P>
-
-
-
-<H3><A NAME="SEC106" HREF="cvs.html#TOC106">diff options</A></H3>
-
-<P>
-These standard options are supported by <CODE>diff</CODE>
-(see section <A HREF="cvs.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-See <SAMP>`-r'</SAMP> for how this affects the comparison.
-
-CVS can be configured to pass the <SAMP>`-D'</SAMP> option
-through to <CODE>rcsdiff</CODE> (which in turn passes it on
-to <CODE>diff</CODE>. GNU diff uses <SAMP>`-D'</SAMP> as a way to
-put <CODE>cpp</CODE>-style <SAMP>`#define'</SAMP> statements around the output
-differences. There is no way short of testing to
-figure out how CVS was configured. In the default
-configuration CVS will use the <SAMP>`-D <VAR>date</VAR>'</SAMP> option.
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Process RCS keywords according to <VAR>kflag</VAR>. See
-co(1).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-R</CODE>
-<DD>
-Examine directories recursively. This option is on by
-default.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Compare with revision <VAR>tag</VAR>. Zero, one or two
-<SAMP>`-r'</SAMP> options can be present. With no <SAMP>`-r'</SAMP>
-option, the working file will be compared with the
-revision it was based on. With one <SAMP>`-r'</SAMP>, that
-revision will be compared to your current working file.
-With two <SAMP>`-r'</SAMP> options those two revisions will be
-compared (and your working file will not affect the
-outcome in any way).
-
-One or both <SAMP>`-r'</SAMP> options can be replaced by a
-<SAMP>`-D <VAR>date</VAR>'</SAMP> option, described above.
-</DL>
-
-<P>
-Any other options that are found are passed through to
-<CODE>rcsdiff</CODE>, which in turn passes them to
-<CODE>diff</CODE>. The exact meaning of the options depends
-on which <CODE>diff</CODE> you are using. The long options
-introduced in GNU diff 2.0 are not yet supported in
-CVS. See the documentation for your <CODE>diff</CODE> to see
-which options are supported.
-
-</P>
-
-
-<H3><A NAME="SEC107" HREF="cvs.html#TOC107">diff examples</A></H3>
-
-<P>
-The following line produces a Unidiff (<SAMP>`-u'</SAMP> flag)
-between revision 1.14 and 1.19 of
-<TT>`backend.c'</TT>. Due to the <SAMP>`-kk'</SAMP> flag no
-keywords are substituted, so differences that only depend
-on keyword substitution are ignored.
-
-</P>
-
-<PRE>
-$ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
-</PRE>
-
-<P>
-Suppose the experimental branch EXPR1 was based on a
-set of files tagged RELEASE_1_0. To see what has
-happened on that branch, the following can be used:
-
-</P>
-
-<PRE>
-$ cvs diff -r RELEASE_1_0 -r EXPR1
-</PRE>
-
-<P>
-A command like this can be used to produce a context
-diff between two releases:
-
-</P>
-
-<PRE>
-$ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
-</PRE>
-
-<P>
-If you are maintaining ChangeLogs, a command like the following
-just before you commit your changes may help you write
-the ChangeLog entry. All local modifications that have
-not yet been committed will be printed.
-
-</P>
-
-<PRE>
-$ cvs diff -u | less
-</PRE>
-
-
-
-<H2><A NAME="SEC108" HREF="cvs.html#TOC108">export--Export sources from CVS,
similar to checkout</A></H2>
-<P>
-<A NAME="IDX344"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: export [-flNn] [-r rev|-D date] [-k subst] [-d dir] module...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: current directory.
-</UL>
-
-<P>
-This command is a variant of <CODE>checkout</CODE>; use it
-when you want a copy of the source for module without
-the CVS administrative directories. For example, you
-might use <CODE>export</CODE> to prepare source for shipment
-off-site. This command requires that you specify a
-date or tag (with <SAMP>`-D'</SAMP> or <SAMP>`-r'</SAMP>), so that you
-can count on reproducing the source you ship to others.
-
-</P>
-<P>
-One often would like to use <SAMP>`-kv'</SAMP> with <CODE>cvs
-export</CODE>. This causes any RCS keywords to be
-expanded such that an import done at some other site
-will not lose the keyword revision information. But be
-aware that doesn't handle an export containing binary
-files correctly. Also be aware that after having used
-<SAMP>`-kv'</SAMP>, one can no longer use the <CODE>ident</CODE>
-command (which is part of the RCS suite--see
-ident(1)) which looks for RCS keyword strings. If
-you want to be able to use <CODE>ident</CODE> you must not
-use <SAMP>`-kv'</SAMP>.
-
-</P>
-
-
-
-<H3><A NAME="SEC109" HREF="cvs.html#TOC109">export options</A></H3>
-
-<P>
-These standard options are supported by <CODE>export</CODE>
-(see section <A HREF="cvs.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-If no matching revision is found, retrieve the most
-recent revision (instead of ignoring the file).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any checkout program.
-
-<DT><CODE>-R</CODE>
-<DD>
-Export directories recursively. This is on by default.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use revision <VAR>tag</VAR>.
-</DL>
-
-<P>
-In addition, these options (that are common to
-<CODE>checkout</CODE> and <CODE>export</CODE>) are also supported:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-d <VAR>dir</VAR></CODE>
-<DD>
-Create a directory called <VAR>dir</VAR> for the working
-files, instead of using the module name. Unless you
-also use <SAMP>`-N'</SAMP>, the paths created under <VAR>dir</VAR>
-will be as short as possible.
-
-<DT><CODE>-k <VAR>subst</VAR></CODE>
-<DD>
-Set keyword expansion mode (see section <A HREF="cvs.html#SEC81">Substitution
modes</A>).
-
-<DT><CODE>-N</CODE>
-<DD>
-Only useful together with <SAMP>`-d <VAR>dir</VAR>'</SAMP>. With this
-option, CVS will not shorten module paths in your
-working directory. (Normally, CVS shortens paths as
-much as possible when you specify an explicit target
-directory.)
-</DL>
-
-
-
-<H2><A NAME="SEC110" HREF="cvs.html#TOC110">history--Show status of files and
users</A></H2>
-<P>
-<A NAME="IDX345"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: history [-report] [-flags] [-options args] [files...]
-<LI>
-
-Requires: the file <TT>`$CVSROOT/CVSROOT/history'</TT>
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-CVS can keep a history file that tracks each use of the
-<CODE>checkout</CODE>, <CODE>commit</CODE>, <CODE>rtag</CODE>,
-<CODE>update</CODE>, and <CODE>release</CODE> commands. You can
-use <CODE>history</CODE> to display this information in
-various formats.
-
-</P>
-<P>
-Logging must be enabled by creating the file
-<TT>`$CVSROOT/CVSROOT/history'</TT>.
-
-</P>
-<P>
-<STRONG>Warning:</STRONG> <CODE>history</CODE> uses <SAMP>`-f'</SAMP>,
<SAMP>`-l'</SAMP>,
-<SAMP>`-n'</SAMP>, and <SAMP>`-p'</SAMP> in ways that conflict with the
-normal use inside CVS (see section <A HREF="cvs.html#SEC90">Common command
options</A>).
-
-</P>
-
-
-
-<H3><A NAME="SEC111" HREF="cvs.html#TOC111">history options</A></H3>
-
-<P>
-Several options (shown above as <SAMP>`-report'</SAMP>) control what
-kind of report is generated:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-c</CODE>
-<DD>
-Report on each time commit was used (i.e., each time
-the repository was modified).
-
-<DT><CODE>-e</CODE>
-<DD>
-Everything (all record types); equivalent to specifying
-<SAMP>`-xMACFROGWUT'</SAMP>.
-
-<DT><CODE>-m <VAR>module</VAR></CODE>
-<DD>
-Report on a particular module. (You can meaningfully
-use <SAMP>`-m'</SAMP> more than once on the command line.)
-
-<DT><CODE>-o</CODE>
-<DD>
-Report on checked-out modules.
-
-<DT><CODE>-T</CODE>
-<DD>
-Report on all tags.
-
-<DT><CODE>-x <VAR>type</VAR></CODE>
-<DD>
-Extract a particular set of record types <VAR>type</VAR> from the CVS
-history. The types are indicated by single letters,
-which you may specify in combination.
-
-Certain commands have a single record type:
-
-<DL COMPACT>
-
-<DT><CODE>F</CODE>
-<DD>
-release
-<DT><CODE>O</CODE>
-<DD>
-checkout
-<DT><CODE>T</CODE>
-<DD>
-rtag
-</DL>
-
-One of four record types may result from an update:
-
-<DL COMPACT>
-
-<DT><CODE>C</CODE>
-<DD>
-A merge was necessary but collisions were
-detected (requiring manual merging).
-<DT><CODE>G</CODE>
-<DD>
-A merge was necessary and it succeeded.
-<DT><CODE>U</CODE>
-<DD>
-A working file was copied from the repository.
-<DT><CODE>W</CODE>
-<DD>
-The working copy of a file was deleted during
-update (because it was gone from the repository).
-</DL>
-
-One of three record types results from commit:
-
-<DL COMPACT>
-
-<DT><CODE>A</CODE>
-<DD>
-A file was added for the first time.
-<DT><CODE>M</CODE>
-<DD>
-A file was modified.
-<DT><CODE>R</CODE>
-<DD>
-A file was removed.
-</DL>
-</DL>
-
-<P>
-The options shown as <SAMP>`-flags'</SAMP> constrain or expand
-the report without requiring option arguments:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-a</CODE>
-<DD>
-Show data for all users (the default is to show data
-only for the user executing <CODE>history</CODE>).
-
-<DT><CODE>-l</CODE>
-<DD>
-Show last modification only.
-
-<DT><CODE>-w</CODE>
-<DD>
-Show only the records for modifications done from the
-same working directory where <CODE>history</CODE> is
-executing.
-</DL>
-
-<P>
-The options shown as <SAMP>`-options <VAR>args</VAR>'</SAMP> constrain the
report
-based on an argument:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b <VAR>str</VAR></CODE>
-<DD>
-Show data back to a record containing the string
-<VAR>str</VAR> in either the module name, the file name, or
-the repository path.
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Show data since <VAR>date</VAR>. This is slightly different
-from the normal use of <SAMP>`-D <VAR>date</VAR>'</SAMP>, which
-selects the newest revision older than <VAR>date</VAR>.
-
-<DT><CODE>-p <VAR>repository</VAR></CODE>
-<DD>
-Show data for a particular source repository (you
-can specify several <SAMP>`-p'</SAMP> options on the same command
-line).
-
-<DT><CODE>-r <VAR>rev</VAR></CODE>
-<DD>
-Show records referring to revisions since the revision
-or tag named <VAR>rev</VAR> appears in individual RCS
-files. Each RCS file is searched for the revision or
-tag.
-
-<DT><CODE>-t <VAR>tag</VAR></CODE>
-<DD>
-Show records since tag <VAR>tag</VAR> was last added to the the
-history file. This differs from the <SAMP>`-r'</SAMP> flag
-above in that it reads only the history file, not the
-RCS files, and is much faster.
-
-<DT><CODE>-u <VAR>name</VAR></CODE>
-<DD>
-Show records for user <VAR>name</VAR>.
-</DL>
-
-
-
-<H2><A NAME="SEC112" HREF="cvs.html#TOC112">import--Import sources into CVS,
using vendor branches</A></H2>
-<P>
-<A NAME="IDX346"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: import [-options] repository vendortag releasetag...
-<LI>
-
-Requires: Repository, source distribution directory.
-<LI>
-
-Changes: repository.
-</UL>
-
-<P>
-Use <CODE>import</CODE> to incorporate an entire source
-distribution from an outside source (e.g., a source
-vendor) into your source repository directory. You can
-use this command both for initial creation of a
-repository, and for wholesale updates to the module
-from the outside source. See section <A HREF="cvs.html#SEC63">Tracking
third-party sources</A>, for
-a discussion on this subject.
-
-</P>
-<P>
-The <VAR>repository</VAR> argument gives a directory name
-(or a path to a directory) under the CVS root directory
-for repositories; if the directory did not exist,
-import creates it.
-
-</P>
-<P>
-When you use import for updates to source that has been
-modified in your source repository (since a prior
-import), it will notify you of any files that conflict
-in the two branches of development; use <SAMP>`checkout
--j'</SAMP> to reconcile the differences, as import instructs
-you to do.
-
-</P>
-<P>
-If CVS decides a file should be ignored
-(see section <A HREF="cvs.html#SEC148">Ignoring files via cvsignore</A>), it
does not import it and prints
-<SAMP>`I '</SAMP> followed by the filename (see section <A
HREF="cvs.html#SEC114">import output</A>, for a
-complete description of the output).
-
-</P>
-<P>
-If the file <TT>`$CVSROOT/CVSROOT/cvswrappers'</TT> exists,
-any file whose names match the specifications in that
-file will be treated as packages and the appropriate
-filtering will be performed on the file/directory
-before being imported, See section <A HREF="cvs.html#SEC138">The cvswrappers
file</A>.
-
-</P>
-<P>
-The outside source is saved in a first-level RCS
-branch, by default 1.1.1. Updates are leaves of this
-branch; for example, files from the first imported
-collection of source will be revision 1.1.1.1, then
-files from the first imported update will be revision
-1.1.1.2, and so on.
-
-</P>
-<P>
-At least three arguments are required.
-<VAR>repository</VAR> is needed to identify the collection
-of source. <VAR>vendortag</VAR> is a tag for the entire
-branch (e.g., for 1.1.1). You must also specify at
-least one <VAR>releasetag</VAR> to identify the files at
-the leaves created each time you execute <CODE>import</CODE>.
-
-</P>
-
-
-
-<H3><A NAME="SEC113" HREF="cvs.html#TOC113">import options</A></H3>
-
-<P>
-This standard option is supported by <CODE>import</CODE>
-(see section <A HREF="cvs.html#SEC90">Common command options</A>, for a
complete description):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-m <VAR>message</VAR></CODE>
-<DD>
-Use <VAR>message</VAR> as log information, instead of
-invoking an editor.
-</DL>
-
-<P>
-There are three additional special options.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b <VAR>branch</VAR></CODE>
-<DD>
-Specify a first-level branch other than 1.1.1. Unless
-the <SAMP>`-b <VAR>branch</VAR>'</SAMP> flag is given, revisions will
-<EM>always</EM> be made to the branch 1.1.1--even if a
-<VAR>vendortag</VAR> that matches another branch is given!
-What happens in that case, is that the tag will be
-reset to 1.1.1. Warning: This behavior might change
-in the future.
-
-<DT><CODE>-k <VAR>subst</VAR></CODE>
-<DD>
-Indicate the RCS keyword expansion mode desired. This
-setting will apply to all files created during the
-import, but not to any files that previously existed in
-the repository. See section <A HREF="cvs.html#SEC81">Substitution modes</A>
for a
-list of valid <SAMP>`-k'</SAMP> settings.
-
-<DT><CODE>-I <VAR>name</VAR></CODE>
-<DD>
-Specify file names that should be ignored during
-import. You can use this option repeatedly. To avoid
-ignoring any files at all (even those ignored by
-default), specify `-I !'.
-
-<VAR>name</VAR> can be a file name pattern of the same type
-that you can specify in the <TT>`.cvsignore'</TT> file.
-See section <A HREF="cvs.html#SEC148">Ignoring files via cvsignore</A>.
-
-<DT><CODE>-W <VAR>spec</VAR></CODE>
-<DD>
-Specify file names that should be filtered during
-import. You can use this option repeatedly.
-
-<VAR>spec</VAR> can be a file name pattern of the same type
-that you can specify in the <TT>`.cvswrappers'</TT>
-file. See section <A HREF="cvs.html#SEC138">The cvswrappers file</A>.
-</DL>
-
-
-
-<H3><A NAME="SEC114" HREF="cvs.html#TOC114">import output</A></H3>
-
-<P>
-<CODE>import</CODE> keeps you informed of its progress by printing a line
-for each file, preceded by one character indicating the status of the file:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>U <VAR>file</VAR></CODE>
-<DD>
-The file already exists in the repository and has not been locally
-modified; a new revision has been created (if necessary).
-
-<DT><CODE>N <VAR>file</VAR></CODE>
-<DD>
-The file is a new file which has been added to the repository.
-
-<DT><CODE>C <VAR>file</VAR></CODE>
-<DD>
-The file already exists in the repository but has been locally modified;
-you will have to merge the changes.
-
-<DT><CODE>I <VAR>file</VAR></CODE>
-<DD>
-The file is being ignored (see section <A HREF="cvs.html#SEC148">Ignoring
files via cvsignore</A>).
-
-<DT><CODE>L <VAR>file</VAR></CODE>
-<DD>
-The file is a symbolic link; at the moment (and for the forseeable
-future), symbolic links are ignored.
-(Various options in the <TT>`modules'</TT> file can be used
-to recreate symbolic links on checkout, update, etc.;
-see section <A HREF="cvs.html#SEC137">The modules file</A>.)
-</DL>
-
-
-
-<H3><A NAME="SEC115" HREF="cvs.html#TOC115">import examples</A></H3>
-
-<P>
-See section <A HREF="cvs.html#SEC63">Tracking third-party sources</A>, and See
section <A HREF="cvs.html#SEC33">Creating a directory tree from a number of
files</A>.
-
-</P>
-
-
-<H2><A NAME="SEC116" HREF="cvs.html#TOC116">log--Print out log information for
files</A></H2>
-<P>
-<A NAME="IDX347"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: log [options] [files...]
-<LI>
-
-Requires: repository, working directory.
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-Display log information for files. <CODE>log</CODE> used to
-call the RCS utility <CODE>rlog</CODE>. Although this
-is no longer true in the current sources, this history
-determines the format of the output and the options,
-which are not quite in the style of the other CVS
-commands.
-
-</P>
-<P>
-<A NAME="IDX348"></A>
-<A NAME="IDX349"></A>
-The output includes the location of the RCS file,
-the <EM>head</EM> revision (the latest revision on the
-trunk), all symbolic names (tags) and some other
-things. For each revision, the revision number, the
-author, the number of lines added/deleted and the log
-message are printed. All times are displayed in
-Coordinated Universal Time (UTC). (Other parts of
-CVS print times in the local timezone).
-
-</P>
-
-
-
-<H3><A NAME="SEC117" HREF="cvs.html#TOC117">log options</A></H3>
-
-<P>
-By default, <CODE>log</CODE> prints all information that is
-available. All other options restrict the output.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b</CODE>
-<DD>
-Print information about the revisions on the default
-branch, normally the highest branch on the trunk.
-
-<DT><CODE>-d <VAR>dates</VAR></CODE>
-<DD>
-Print information about revisions with a checkin
-date/time in the range given by the
-semicolon-separated list of dates. The date formats
-accepted are those accepted by the <SAMP>`-D'</SAMP> option to
-many other CVS commands (see section <A HREF="cvs.html#SEC90">Common command
options</A>).
-Dates can be combined into ranges as follows:
-
-<DL COMPACT>
-
-<DT><CODE><VAR>d1</VAR><<VAR>d2</VAR></CODE>
-<DD>
-<DT><CODE><VAR>d2</VAR>><VAR>d1</VAR></CODE>
-<DD>
-Select the revisions that were deposited between
-<VAR>d1</VAR> and <VAR>d2</VAR>.
-
-<DT><CODE><<VAR>d</VAR></CODE>
-<DD>
-<DT><CODE><VAR>d</VAR>></CODE>
-<DD>
-Select all revisions dated <VAR>d</VAR> or earlier.
-
-<DT><CODE><VAR>d</VAR><</CODE>
-<DD>
-<DT><CODE>><VAR>d</VAR></CODE>
-<DD>
-Select all revisions dated <VAR>d</VAR> or later.
-
-<DT><CODE><VAR>d</VAR></CODE>
-<DD>
-Select the single, latest revision dated <VAR>d</VAR> or
-earlier.
-</DL>
-
-The <SAMP>`>'</SAMP> or <SAMP>`<'</SAMP> characters may be followed by
-<SAMP>`='</SAMP> to indicate an inclusive range rather than an
-exclusive one.
-
-Note that the separator is a semicolon (;).
-
-<DT><CODE>-h</CODE>
-<DD>
-Print only the RCS pathname, working pathname, head,
-default branch, access list, locks, symbolic names, and
-suffix.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory. (Default
-is to run recursively).
-
-<DT><CODE>-N</CODE>
-<DD>
-Do not print the list of tags for this file. This
-option can be very useful when your site uses a lot of
-tags, so rather than "more"'ing over 3 pages of tag
-information, the log information is presented without
-tags at all.
-
-<DT><CODE>-R</CODE>
-<DD>
-Print only the name of the RCS history file.
-
-<DT><CODE>-r<VAR>revisions</VAR></CODE>
-<DD>
-Print information about revisions given in the
-comma-separated list <VAR>revisions</VAR> of revisions and
-ranges. The following table explains the available
-range formats:
-
-<DL COMPACT>
-
-<DT><CODE><VAR>rev1</VAR>:<VAR>rev2</VAR></CODE>
-<DD>
-Revisions <VAR>rev1</VAR> to <VAR>rev2</VAR> (which must be on
-the same branch).
-
-<DT><CODE>:<VAR>rev</VAR></CODE>
-<DD>
-Revisions from the beginning of the branch up to
-and including <VAR>rev</VAR>.
-
-<DT><CODE><VAR>rev</VAR>:</CODE>
-<DD>
-Revisions starting with <VAR>rev</VAR> to the end of the
-branch containing <VAR>rev</VAR>.
-
-<DT><CODE><VAR>branch</VAR></CODE>
-<DD>
-An argument that is a branch means all revisions on
-that branch.
-
-<DT><CODE><VAR>branch1</VAR>:<VAR>branch2</VAR></CODE>
-<DD>
-A range of branches means all revisions
-on the branches in that range.
-
-<DT><CODE><VAR>branch</VAR>.</CODE>
-<DD>
-The latest revision in <VAR>branch</VAR>.
-</DL>
-
-A bare <SAMP>`-r'</SAMP> with no revisions means the latest
-revision on the default branch, normally the trunk.
-There can be no space between the <SAMP>`-r'</SAMP> option and
-its argument.
-
-<DT><CODE>-s <VAR>states</VAR></CODE>
-<DD>
-Print information about revisions whose state
-attributes match one of the states given in the
-comma-separated list <VAR>states</VAR>.
-
-<DT><CODE>-t</CODE>
-<DD>
-Print the same as <SAMP>`-h'</SAMP>, plus the descriptive text.
-
-<DT><CODE>-w<VAR>logins</VAR></CODE>
-<DD>
-Print information about revisions checked in by users
-with login names appearing in the comma-separated list
-<VAR>logins</VAR>. If <VAR>logins</VAR> is omitted, the user's
-login is assumed. There can be no space between the
-<SAMP>`-w'</SAMP> option and its argument.
-</DL>
-
-<P>
-<CODE>log</CODE> prints the intersection of the revisions
-selected with the options <SAMP>`-d'</SAMP>, <SAMP>`-s'</SAMP>, and
-<SAMP>`-w'</SAMP>, intersected with the union of the revisions
-selected by <SAMP>`-b'</SAMP> and <SAMP>`-r'</SAMP>.
-
-</P>
-
-
-<H3><A NAME="SEC118" HREF="cvs.html#TOC118">log examples</A></H3>
-
-<P>
-Contributed examples are gratefully accepted.
-
-</P>
-
-
-<H2><A NAME="SEC119" HREF="cvs.html#TOC119">rdiff---'patch' format diffs
between releases</A></H2>
-<P>
-<A NAME="IDX350"></A>
-
-</P>
-
-<UL>
-<LI>
-
-rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: nothing.
-<LI>
-
-Synonym: patch
-</UL>
-
-<P>
-Builds a Larry Wall format patch(1) file between two
-releases, that can be fed directly into the patch
-program to bring an old release up-to-date with the new
-release. (This is one of the few CVS commands that
-operates directly from the repository, and doesn't
-require a prior checkout.) The diff output is sent to
-the standard output device.
-
-</P>
-<P>
-You can specify (using the standard <SAMP>`-r'</SAMP> and
-<SAMP>`-D'</SAMP> options) any combination of one or two
-revisions or dates. If only one revision or date is
-specified, the patch file reflects differences between
-that revision or date and the current head revisions in
-the RCS file.
-
-</P>
-<P>
-Note that if the software release affected is contained
-in more than one directory, then it may be necessary to
-specify the <SAMP>`-p'</SAMP> option to the patch command when
-patching the old sources, so that patch is able to find
-the files that are located in other directories.
-
-</P>
-
-
-
-<H3><A NAME="SEC120" HREF="cvs.html#TOC120">rdiff options</A></H3>
-
-<P>
-These standard options are supported by <CODE>rdiff</CODE>
-(see section <A HREF="cvs.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-If no matching revision is found, retrieve the most
-recent revision (instead of ignoring the file).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; don't descend subdirectories.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use revision <VAR>tag</VAR>.
-</DL>
-
-<P>
-In addition to the above, these options are available:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-c</CODE>
-<DD>
-Use the context diff format. This is the default format.
-
-<DT><CODE>-s</CODE>
-<DD>
-Create a summary change report instead of a patch. The
-summary includes information about files that were
-changed or added between the releases. It is sent to
-the standard output device. This is useful for finding
-out, for example, which files have changed between two
-dates or revisions.
-
-<DT><CODE>-t</CODE>
-<DD>
-A diff of the top two revisions is sent to the standard
-output device. This is most useful for seeing what the
-last change to a file was.
-
-<DT><CODE>-u</CODE>
-<DD>
-Use the unidiff format for the context diffs.
-This option is not available if your diff does not
-support the unidiff format. Remember that old versions
-of the <CODE>patch</CODE> program can't handle the unidiff
-format, so if you plan to post this patch to the net
-you should probably not use <SAMP>`-u'</SAMP>.
-
-<DT><CODE>-V <VAR>vn</VAR></CODE>
-<DD>
-Expand RCS keywords according to the rules current in
-RCS version <VAR>vn</VAR> (the expansion format changed with
-RCS version 5).
-</DL>
-
-
-
-<H3><A NAME="SEC121" HREF="cvs.html#TOC121">rdiff examples</A></H3>
-
-<P>
-Suppose you receive mail from <TT>address@hidden</TT> asking for an
-update from release 1.2 to 1.4 of the tc compiler. You
-have no such patches on hand, but with CVS that can
-easily be fixed with a command such as this:
-
-</P>
-
-<PRE>
-$ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
-$$ Mail -s 'The patches you asked for' address@hidden
-</PRE>
-
-<P>
-Suppose you have made release 1.3, and forked a branch
-called <SAMP>`R_1_3fix'</SAMP> for bugfixes. <SAMP>`R_1_3_1'</SAMP>
-corresponds to release 1.3.1, which was made some time
-ago. Now, you want to see how much development has been
-done on the branch. This command can be used:
-
-</P>
-
-<PRE>
-$ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name
-cvs rdiff: Diffing module-name
-File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6
-File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4
-File bar.h,v changed from revision 1.29.2.1 to 1.2
-</PRE>
-
-
-
-<H2><A NAME="SEC122" HREF="cvs.html#TOC122">release--Indicate that a Module is
no longer in use</A></H2>
-<P>
-<A NAME="IDX351"></A>
-
-</P>
-
-<UL>
-<LI>
-
-release [-d] directories...
-<LI>
-
-Requires: Working directory.
-<LI>
-
-Changes: Working directory, history log.
-</UL>
-
-<P>
-This command is meant to safely cancel the effect of
-<SAMP>`cvs checkout'</SAMP>. Since CVS doesn't lock files, it
-isn't strictly necessary to use this command. You can
-always simply delete your working directory, if you
-like; but you risk losing changes you may have
-forgotten, and you leave no trace in the CVS history
-file (see section <A HREF="cvs.html#SEC149">The history file</A>) that you've
abandoned your
-checkout.
-
-</P>
-<P>
-Use <SAMP>`cvs release'</SAMP> to avoid these problems. This
-command checks that no uncommitted changes are
-present; that you are executing it from immediately
-above a CVS working directory; and that the repository
-recorded for your files is the same as the repository
-defined in the module database.
-
-</P>
-<P>
-If all these conditions are true, <SAMP>`cvs release'</SAMP>
-leaves a record of its execution (attesting to your
-intentionally abandoning your checkout) in the CVS
-history log.
-
-</P>
-
-
-
-<H3><A NAME="SEC123" HREF="cvs.html#TOC123">release options</A></H3>
-
-<P>
-The <CODE>release</CODE> command supports one command option:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-d</CODE>
-<DD>
-Delete your working copy of the file if the release
-succeeds. If this flag is not given your files will
-remain in your working directory.
-
-<STRONG>Warning:</STRONG> The <CODE>release</CODE> command deletes
-all directories and files recursively. This
-has the very serious side-effect that any directory
-that you have created inside your checked-out sources,
-and not added to the repository (using the <CODE>add</CODE>
-command; see section <A HREF="cvs.html#SEC61">Adding files to a directory</A>)
will be silently deleted--even
-if it is non-empty!
-</DL>
-
-
-
-<H3><A NAME="SEC124" HREF="cvs.html#TOC124">release output</A></H3>
-
-<P>
-Before <CODE>release</CODE> releases your sources it will
-print a one-line message for any file that is not
-up-to-date.
-
-</P>
-<P>
-<STRONG>Warning:</STRONG> Any new directories that you have
-created, but not added to the CVS directory hierarchy
-with the <CODE>add</CODE> command (see section <A HREF="cvs.html#SEC61">Adding
files to a directory</A>) will be
-silently ignored (and deleted, if <SAMP>`-d'</SAMP> is
-specified), even if they contain files.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>U <VAR>file</VAR></CODE>
-<DD>
-There exists a newer revision of this file in the
-repository, and you have not modified your local copy
-of the file.
-
-<DT><CODE>A <VAR>file</VAR></CODE>
-<DD>
-The file has been added to your private copy of the
-sources, but has not yet been committed to the
-repository. If you delete your copy of the sources
-this file will be lost.
-
-<DT><CODE>R <VAR>file</VAR></CODE>
-<DD>
-The file has been removed from your private copy of the
-sources, but has not yet been removed from the
-repository, since you have not yet committed the
-removal. See section <A HREF="cvs.html#SEC99">commit--Check files into the
repository</A>.
-
-<DT><CODE>M <VAR>file</VAR></CODE>
-<DD>
-The file is modified in your working directory. There
-might also be a newer revision inside the repository.
-
-<DT><CODE>? <VAR>file</VAR></CODE>
-<DD>
-<VAR>file</VAR> is in your working directory, but does not
-correspond to anything in the source repository, and is
-not in the list of files for CVS to ignore (see the
-description of the <SAMP>`-I'</SAMP> option, and
-see section <A HREF="cvs.html#SEC148">Ignoring files via cvsignore</A>). If
you remove your working
-sources, this file will be lost.
-
-Note that no warning message like this is printed for
-spurious directories that CVS encounters. The
-directory, and all its contents, are silently ignored.
-
-</DL>
-
-
-
-<H3><A NAME="SEC125" HREF="cvs.html#TOC125">release examples</A></H3>
-
-<P>
-Release the module, and delete your local working copy
-of the files.
-
-</P>
-
-<PRE>
-$ cd .. # You must stand immediately above the
- # sources when you issue <SAMP>`cvs release'</SAMP>.
-$ cvs release -d tc
-You have [0] altered files in this repository.
-Are you sure you want to release (and delete) module `tc': y
-$
-</PRE>
-
-
-
-<H2><A NAME="SEC126" HREF="cvs.html#TOC126">rtag--Add a symbolic tag to a
module</A></H2>
-<P>
-<A NAME="IDX352"></A>
-
-</P>
-
-<UL>
-<LI>
-
-rtag [-falnR] [-b] [-d] [-r tag | -Ddate] symbolic_tag modules...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: rfreeze
-</UL>
-
-<P>
-You can use this command to assign symbolic tags to
-particular, explicitly specified source revisions in
-the repository. <CODE>rtag</CODE> works directly on the
-repository contents (and requires no prior checkout).
-Use <CODE>tag</CODE> instead (see section <A HREF="cvs.html#SEC130">tag--Add a
symbolic tag to checked out versions of files</A>), to base the
-selection of revisions on the contents of your
-working directory.
-
-</P>
-<P>
-If you attempt to use a tag name that already exists,
-CVS will complain and not overwrite that tag. Use
-the <SAMP>`-F'</SAMP> option to force the new tag value.
-
-</P>
-
-
-
-<H3><A NAME="SEC127" HREF="cvs.html#TOC127">rtag options</A></H3>
-
-<P>
-These standard options are supported by <CODE>rtag</CODE>
-(see section <A HREF="cvs.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Tag the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
<VAR>tag</VAR>'</SAMP>
-flags. If no matching revision is found, use the most
-recent revision (instead of ignoring the file).
-
-<DT><CODE>-F</CODE>
-<DD>
-Overwrite an existing tag of the same name on a
-different revision. This option is new in CVS
-1.4. The old behavior is matched by <SAMP>`cvs tag -F'</SAMP>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any tag program that was specified with the
-<SAMP>`-t'</SAMP> flag inside the <TT>`modules'</TT> file.
-(see section <A HREF="cvs.html#SEC137">The modules file</A>).
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Only tag those files that contain <VAR>tag</VAR>. This can
-be used to rename a tag: tag only the files identified
-by the old tag, then delete the old tag, leaving the
-new tag on exactly the same files as the old tag.
-</DL>
-
-<P>
-In addition to the above common options, these options
-are available:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-a</CODE>
-<DD>
-Use the <SAMP>`-a'</SAMP> option to have <CODE>rtag</CODE> look in the
-<TT>`Attic'</TT> (see section <A HREF="cvs.html#SEC62">Removing files from a
module</A>) for removed files
-that contain the specified tag. The tag is removed from
-these files, which makes it convenient to re-use a
-symbolic tag as development continues (and files get
-removed from the up-coming distribution).
-
-<DT><CODE>-b</CODE>
-<DD>
-Make the tag a branch tag. See section <A HREF="cvs.html#SEC50">Branches</A>.
-
-<DT><CODE>-d</CODE>
-<DD>
-Delete the tag instead of creating it.
-
-In general, tags (often the symbolic names of software
-distributions) should not be removed, but the <SAMP>`-d'</SAMP>
-option is available as a means to remove completely
-obsolete symbolic names if necessary (as might be the
-case for an Alpha release, or if you mistagged a
-module).
-</DL>
-
-
-
-<H2><A NAME="SEC128" HREF="cvs.html#TOC128">status--Display status information
on checked out files</A></H2>
-<P>
-<A NAME="IDX353"></A>
-
-</P>
-
-
-<UL>
-<LI>
-
-status [-lR] [-v] [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-Display a brief report on the current status of files
-with respect to the source repository. For information
-on the basic output see section <A HREF="cvs.html#SEC38">File status</A>. For
-information on the <CODE>Sticky tag</CODE> and <CODE>Sticky
-date</CODE> output, see section <A HREF="cvs.html#SEC54">Sticky tags</A>. For
information
-on the <CODE>Sticky options</CODE> output, see the <SAMP>`-k'</SAMP>
-option in section <A HREF="cvs.html#SEC133">update options</A>.
-
-</P>
-<P>
-You can also use this command to determine the
-potential impact of a <SAMP>`cvs update'</SAMP> on your working
-source directory--but remember that things might
-change in the repository before you run <CODE>update</CODE>.
-
-</P>
-
-
-
-<H3><A NAME="SEC129" HREF="cvs.html#TOC129">status options</A></H3>
-
-<P>
-These standard options are supported by <CODE>status</CODE>
-(see section <A HREF="cvs.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-</DL>
-
-<P>
-There is one additional option:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-v</CODE>
-<DD>
-Verbose. In addition to the information normally
-displayed, print all symbolic tags, together with the
-numerical value of the revision or branch they refer
-to. For more information, see section <A HREF="cvs.html#SEC51">Tags--Symbolic
revisions</A>
-</DL>
-
-
-
-<H2><A NAME="SEC130" HREF="cvs.html#TOC130">tag--Add a symbolic tag to checked
out versions of files</A></H2>
-<P>
-<A NAME="IDX354"></A>
-
-</P>
-
-<UL>
-<LI>
-
-tag [-lR] [-b] [-c] [-d] symbolic_tag [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: freeze
-</UL>
-
-<P>
-Use this command to assign symbolic tags to the nearest
-repository versions to your working sources. The tags
-are applied immediately to the repository, as with
-<CODE>rtag</CODE>, but the versions are supplied implicitly by the
-CVS records of your working files' history rather than
-applied explicitly.
-
-</P>
-<P>
-One use for tags is to record a snapshot of the
-current sources when the software freeze date of a
-project arrives. As bugs are fixed after the freeze
-date, only those changed sources that are to be part of
-the release need be re-tagged.
-
-</P>
-<P>
-The symbolic tags are meant to permanently record which
-revisions of which files were used in creating a
-software distribution. The <CODE>checkout</CODE> and
-<CODE>update</CODE> commands allow you to extract an exact
-copy of a tagged release at any time in the future,
-regardless of whether files have been changed, added,
-or removed since the release was tagged.
-
-</P>
-<P>
-This command can also be used to delete a symbolic tag,
-or to create a branch. See the options section below.
-
-</P>
-<P>
-If you attempt to use a tag name that already exists,
-CVS will complain and not overwrite that tag. Use
-the <SAMP>`-F'</SAMP> option to force the new tag value.
-
-</P>
-
-
-
-<H3><A NAME="SEC131" HREF="cvs.html#TOC131">tag options</A></H3>
-
-<P>
-These standard options are supported by <CODE>tag</CODE>
-(see section <A HREF="cvs.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-F</CODE>
-<DD>
-Overwrite an existing tag of the same name on a
-different revision. This option is new in CVS
-1.4. The old behavior is matched by <SAMP>`cvs tag -F'</SAMP>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-</DL>
-
-<P>
-Two special options are available:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b</CODE>
-<DD>
-The -b option makes the tag a branch tag
-(see section <A HREF="cvs.html#SEC50">Branches</A>), allowing concurrent,
isolated
-development. This is most useful for creating a patch
-to a previously released software distribution.
-
-<DT><CODE>-c</CODE>
-<DD>
-The -c option checks that all files which are to be tagged are
-unmodified. This can be used to make sure that you can reconstruct the
-current file contents.
-
-<DT><CODE>-d</CODE>
-<DD>
-Delete a tag.
-
-If you use <SAMP>`cvs tag -d symbolic_tag'</SAMP>, the symbolic
-tag you specify is deleted instead of being added.
-Warning: Be very certain of your ground before you
-delete a tag; doing this permanently discards some
-historical information, which may later turn out to
-be valuable.
-</DL>
-
-
-
-<H2><A NAME="SEC132" HREF="cvs.html#TOC132">update--Bring work tree in sync
with repository</A></H2>
-<P>
-<A NAME="IDX355"></A>
-
-</P>
-
-<UL>
-<LI>
-
-update [-AdflPpR] [-d] [-r tag|-D date] files...
-<LI>
-
-Requires: repository, working directory.
-<LI>
-
-Changes: working directory.
-</UL>
-
-<P>
-After you've run checkout to create your private copy
-of source from the common repository, other developers
-will continue changing the central source. From time
-to time, when it is convenient in your development
-process, you can use the <CODE>update</CODE> command from
-within your working directory to reconcile your work
-with any revisions applied to the source repository
-since your last checkout or update.
-
-</P>
-
-
-
-<H3><A NAME="SEC133" HREF="cvs.html#TOC133">update options</A></H3>
-
-<P>
-These standard options are available with <CODE>update</CODE>
-(see section <A HREF="cvs.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D date</CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-This option is sticky, and implies <SAMP>`-P'</SAMP>.
-See section <A HREF="cvs.html#SEC54">Sticky tags</A>, for more information on
sticky tags/dates.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
-<VAR>tag</VAR>'</SAMP> flags. If no matching revision is found,
-retrieve the most recent revision (instead of ignoring
-the file).
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Process RCS keywords according to <VAR>kflag</VAR>. See
-co(1). This option is sticky; future updates of
-this file in this working directory will use the same
-<VAR>kflag</VAR>. The <CODE>status</CODE> command can be viewed
-to see the sticky options. See section <A
HREF="cvs.html#SEC128">status--Display status information on checked out
files</A>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory. See section <A
HREF="cvs.html#SEC60">Recursive behavior</A>.
-
-<DT><CODE>-P</CODE>
-<DD>
-Prune empty directories.
-
-<DT><CODE>-p</CODE>
-<DD>
-Pipe files to the standard output.
-
-<DT><CODE>-R</CODE>
-<DD>
-Operate recursively. This is on by default.
-See section <A HREF="cvs.html#SEC60">Recursive behavior</A>.
-
-<DT><CODE>-r tag</CODE>
-<DD>
-Retrieve revision <VAR>tag</VAR>. This option is sticky,
-and implies <SAMP>`-P'</SAMP>.
-See section <A HREF="cvs.html#SEC54">Sticky tags</A>, for more information on
sticky tags/dates.
-</DL>
-
-<P>
-These special options are also available with
-<CODE>update</CODE>.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-A</CODE>
-<DD>
-Reset any sticky tags, dates, or <SAMP>`-k'</SAMP> options.
-See section <A HREF="cvs.html#SEC54">Sticky tags</A>, for more information on
sticky tags/dates.
-
-<DT><CODE>-d</CODE>
-<DD>
-Create any directories that exist in the repository if
-they're missing from the working directory. Normally,
-<CODE>update</CODE> acts only on directories and files that
-were already enrolled in your working directory.
-
-This is useful for updating directories that were
-created in the repository since the initial checkout;
-but it has an unfortunate side effect. If you
-deliberately avoided certain directories in the
-repository when you created your working directory
-(either through use of a module name or by listing
-explicitly the files and directories you wanted on the
-command line), then updating with <SAMP>`-d'</SAMP> will create
-those directories, which may not be what you want.
-
-<DT><CODE>-I <VAR>name</VAR></CODE>
-<DD>
-Ignore files whose names match <VAR>name</VAR> (in your
-working directory) during the update. You can specify
-<SAMP>`-I'</SAMP> more than once on the command line to specify
-several files to ignore. Use <SAMP>`-I !'</SAMP> to avoid
-ignoring any files at all. See section <A HREF="cvs.html#SEC148">Ignoring
files via cvsignore</A>, for other
-ways to make CVS ignore some files.
-
-<DT><CODE>-W<VAR>spec</VAR></CODE>
-<DD>
-Specify file names that should be filtered during
-update. You can use this option repeatedly.
-
-<VAR>spec</VAR> can be a file name pattern of the same type
-that you can specify in the <TT>`.cvswrappers'</TT>
-file. See section <A HREF="cvs.html#SEC138">The cvswrappers file</A>.
-
-<DT><CODE>-j<VAR>revision</VAR></CODE>
-<DD>
-With two <SAMP>`-j'</SAMP> options, merge changes from the
-revision specified with the first <SAMP>`-j'</SAMP> option to
-the revision specified with the second <SAMP>`j'</SAMP> option,
-into the working directory.
-
-With one <SAMP>`-j'</SAMP> option, merge changes from the
-ancestor revision to the revision specified with the
-<SAMP>`-j'</SAMP> option, into the working directory. The
-ancestor revision is the common ancestor of the
-revision which the working directory is based on, and
-the revision specified in the <SAMP>`-j'</SAMP> option.
-
-In addition, each -j option can contain an optional
-date specification which, when used with branches, can
-limit the chosen revision to one within a specific
-date. An optional date is specified by adding a colon
-(:) to the tag:
-<SAMP>`-j<VAR>Symbolic_Tag</VAR>:<VAR>Date_Specifier</VAR>'</SAMP>.
-
-See section <A HREF="cvs.html#SEC55">Merging</A>.
-
-</DL>
-
-
-
-<H3><A NAME="SEC134" HREF="cvs.html#TOC134">update output</A></H3>
-
-<P>
-<CODE>update</CODE> and <CODE>checkout</CODE> keep you informed of
-its progress by printing a line for each file, preceded
-by one character indicating the status of the file:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>U <VAR>file</VAR></CODE>
-<DD>
-The file was brought up to date with respect to the
-repository. This is done for any file that exists in
-the repository but not in your source, and for files
-that you haven't changed but are not the most recent
-versions available in the repository.
-
-<DT><CODE>A <VAR>file</VAR></CODE>
-<DD>
-The file has been added to your private copy of the
-sources, and will be added to the source repository
-when you run <CODE>commit</CODE> on the file. This is a
-reminder to you that the file needs to be committed.
-
-<DT><CODE>R <VAR>file</VAR></CODE>
-<DD>
-The file has been removed from your private copy of the
-sources, and will be removed from the source repository
-when you run <CODE>commit</CODE> on the file. This is a
-reminder to you that the file needs to be committed.
-
-<DT><CODE>M <VAR>file</VAR></CODE>
-<DD>
-The file is modified in your working directory.
-
-<SAMP>`M'</SAMP> can indicate one of two states for a file
-you're working on: either there were no modifications
-to the same file in the repository, so that your file
-remains as you last saw it; or there were modifications
-in the repository as well as in your copy, but they
-were merged successfully, without conflict, in your
-working directory.
-
-CVS will print some messages if it merges your work,
-and a backup copy of your working file (as it looked
-before you ran <CODE>update</CODE>) will be made. The exact
-name of that file is printed while <CODE>update</CODE> runs.
-
-<DT><CODE>C <VAR>file</VAR></CODE>
-<DD>
-<A NAME="IDX356"></A>
-<A NAME="IDX357"></A>
-A conflict was detected while trying to merge your
-changes to <VAR>file</VAR> with changes from the source
-repository. <VAR>file</VAR> (the copy in your working
-directory) is now the output of the rcsmerge(1) command
-on the two revisions; an unmodified copy of your file
-is also in your working directory, with the name
-<TT>`.#<VAR>file</VAR>.<VAR>revision</VAR>'</TT> where <VAR>revision</VAR>
-is the RCS revision that your modified file started
-from. Resolve the conflict as described in
-section <A HREF="cvs.html#SEC40">Conflicts example</A>
-(Note that some systems automatically purge
-files that begin with <TT>`.#'</TT> if they have not been
-accessed for a few days. If you intend to keep a copy
-of your original file, it is a very good idea to rename
-it.) Under VMS, the file name starts with
-<TT>`__'</TT> rather than <TT>`.#'</TT>.
-
-<DT><CODE>? <VAR>file</VAR></CODE>
-<DD>
-<VAR>file</VAR> is in your working directory, but does not
-correspond to anything in the source repository, and is
-not in the list of files for CVS to ignore (see the
-description of the <SAMP>`-I'</SAMP> option, and
-see section <A HREF="cvs.html#SEC148">Ignoring files via cvsignore</A>).
-
-Note that no warning message like this is printed for
-spurious directories that CVS encounters. The
-directory, and all its contents, are silently ignored.
-</DL>
-
-
-
-<H3><A NAME="SEC135" HREF="cvs.html#TOC135">update examples</A></H3>
-
-<P>
-The following line will display all files which are not
-up-to-date without actually change anything in your
-working directory. It can be used to check what has
-been going on with the project.
-
-</P>
-
-<PRE>
-$ cvs -n -q update
-</PRE>
-
-
-
-<H1><A NAME="SEC136" HREF="cvs.html#TOC136">Reference manual for the
Administrative files</A></H1>
-<P>
-<A NAME="IDX358"></A>
-<A NAME="IDX359"></A>
-<A NAME="IDX360"></A>
-<A NAME="IDX361"></A>
-
-</P>
-<P>
-Inside the repository, in the directory
-<TT>`$CVSROOT/CVSROOT'</TT>, there are a number of
-supportive files for CVS. You can use CVS in a limited
-fashion without any of them, but if they are set up
-properly they can help make life easier. For a
-discussion of how to edit them, See section <A HREF="cvs.html#SEC20">The
administrative files</A>.
-
-</P>
-<P>
-The most important of these files is the <TT>`modules'</TT>
-file, which defines the modules inside the repository.
-
-</P>
-
-
-
-<H2><A NAME="SEC137" HREF="cvs.html#TOC137">The modules file</A></H2>
-<P>
-<A NAME="IDX362"></A>
-<A NAME="IDX363"></A>
-
-</P>
-<P>
-The <TT>`modules'</TT> file records your definitions of
-names for collections of source code. CVS will
-use these definitions if you use CVS to update the
-modules file (use normal commands like <CODE>add</CODE>,
-<CODE>commit</CODE>, etc).
-
-</P>
-<P>
-The <TT>`modules'</TT> file may contain blank lines and
-comments (lines beginning with <SAMP>`#'</SAMP>) as well as
-module definitions. Long lines can be continued on the
-next line by specifying a backslash (<SAMP>`\'</SAMP>) as the
-last character on the line.
-
-</P>
-<P>
-A module definition is a single line of the
-<TT>`modules'</TT> file, in either of two formats. In both
-cases, <VAR>mname</VAR> represents the symbolic module name,
-and the remainder of the line is its definition.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE><VAR>mname</VAR> -a <VAR>aliases</VAR>...</CODE>
-<DD>
-This represents the simplest way of defining a module
-<VAR>mname</VAR>. The <SAMP>`-a'</SAMP> flags the definition as a
-simple alias: CVS will treat any use of <VAR>mname</VAR> (as
-a command argument) as if the list of names
-<VAR>aliases</VAR> had been specified instead.
-<VAR>aliases</VAR> may contain either other module names or
-paths. When you use paths in aliases, <CODE>checkout</CODE>
-creates all intermediate directories in the working
-directory, just as if the path had been specified
-explicitly in the CVS arguments.
-
-<DT><CODE><VAR>mname</VAR> [ options ] <VAR>dir</VAR> [ <VAR>files</VAR>... ]
[ &<VAR>module</VAR>... ]</CODE>
-<DD>
-In the simplest case, this form of module definition
-reduces to <SAMP>`<VAR>mname</VAR> <VAR>dir</VAR>'</SAMP>. This defines
-all the files in directory <VAR>dir</VAR> as module mname.
-<VAR>dir</VAR> is a relative path (from <CODE>$CVSROOT</CODE>) to a
-directory of source in the source repository. In this
-case, on checkout, a single directory called
-<VAR>mname</VAR> is created as a working directory; no
-intermediate directory levels are used by default, even
-if <VAR>dir</VAR> was a path involving several directory
-levels.
-
-By explicitly specifying files in the module definition
-after <VAR>dir</VAR>, you can select particular files from
-directory <VAR>dir</VAR>. The sample definition for
-<SAMP>`modules'</SAMP> is an example of a module defined with a
-single file from a particular directory. Here is
-another example:
-
-
-<PRE>
-m4test unsupported/gnu/m4 foreach.m4 forloop.m4
-</PRE>
-
-With this definition, executing <SAMP>`cvs checkout
-m4test'</SAMP> will create a single working directory
-<TT>`m4test'</TT> containing the two files listed, which
-both come from a common directory several levels deep
-in the CVS source repository.
-
-A module definition can refer to other modules by
-including <SAMP>`&<VAR>module</VAR>'</SAMP> in its definition.
-<CODE>checkout</CODE> creates a subdirectory for each such
-module, in your working directory.
-
-<DL COMPACT>
-
-<DT><CODE>-d <VAR>name</VAR></CODE>
-<DD>
-Name the working directory something other than the
-module name.
-
-<A NAME="IDX364"></A>
-<DT><CODE>-e <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are exported. <VAR>prog</VAR> runs with a single
-argument, the module name.
-
-<A NAME="IDX365"></A>
-<DT><CODE>-i <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are committed. <VAR>prog</VAR> runs with a single
-argument, the full pathname of the affected directory
-in a source repository. The <TT>`commitinfo'</TT>,
-<TT>`loginfo'</TT>, and <TT>`editinfo'</TT> files provide other
-ways to call a program on commit.
-
-<A NAME="IDX366"></A>
-<DT><CODE>-o <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are checked out. <VAR>prog</VAR> runs with a single
-argument, the module name.
-
-<A NAME="IDX367"></A>
-<A NAME="IDX368"></A>
-<DT><CODE>-s <VAR>status</VAR></CODE>
-<DD>
-Assign a status to the module. When the module file is
-printed with <SAMP>`cvs checkout -s'</SAMP> the modules are
-sorted according to primarily module status, and
-secondarily according to the module name. This option
-has no other meaning. You can use this option for
-several things besides status: for instance, list the
-person that is responsible for this module.
-
-<A NAME="IDX369"></A>
-<DT><CODE>-t <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are tagged with <CODE>rtag</CODE>. <VAR>prog</VAR> runs
-with two arguments: the module name and the symbolic
-tag specified to <CODE>rtag</CODE>. There is no way to
-specify a program to run when <CODE>tag</CODE> is executed.
-
-<A NAME="IDX370"></A>
-<DT><CODE>-u <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever <SAMP>`cvs
-update'</SAMP> is executed from the top-level directory of the
-checked-out module. <VAR>prog</VAR> runs with a single
-argument, the full path to the source repository for
-this module.
-</DL>
-</DL>
-
-
-
-<H2><A NAME="SEC138" HREF="cvs.html#TOC138">The cvswrappers file</A></H2>
-<P>
-<A NAME="IDX371"></A>
-<A NAME="IDX372"></A>
-<A NAME="IDX373"></A>
-
-</P>
-
-<P>
-Wrappers allow you to set a hook which transforms files on
-their way in and out of CVS. Most or all of the
-wrappers features do not work with client/server CVS.
-
-</P>
-<P>
-The file <TT>`cvswrappers'</TT> defines the script that will be
-run on a file when its name matches a regular
-expresion. There are two scripts that can be run on a
-file or directory. One script is executed on the file/directory
-before being checked into the repository (this is denoted
-with the <CODE>-t</CODE> flag) and the other when the file is
-checked out of the repository (this is denoted with the
-<CODE>-f</CODE> flag)
-
-</P>
-<P>
-The <TT>`cvswrappers'</TT> also has a <SAMP>`-m'</SAMP> option to
-specify the merge methodology that should be used when
-the file is updated. <CODE>MERGE</CODE> means the usual
-CVS behavior: try to merge the files (this
-generally will not work for binary files). <CODE>COPY</CODE>
-means that <CODE>cvs update</CODE> will merely copy one
-version over the other, and require the user using
-mechanisms outside CVS, to insert any necessary
-changes.
-The <SAMP>`-m'</SAMP> wrapper option only affects behavior when
-merging is done on update; it does not affect how files
-are stored. See See section <A HREF="cvs.html#SEC83">Handling binary
files</A>, for more on
-binary files.
-
-</P>
-<P>
-The basic format of the file <TT>`cvswrappers'</TT> is:
-
-</P>
-
-<PRE>
-wildcard [option value][option value]...
-
-where option is one of
--f from cvs filter value: path to filter
--t to cvs filter value: path to filter
--m update methodology value: MERGE or COPY
--k keyword expansion value: expansion mode
-
-and value is a single-quote delimited value.
-</PRE>
-
-
-<PRE>
-*.nib -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
-*.c -t 'indent %s %s'
-</PRE>
-
-<P>
-The above example of a <TT>`cvswrappers'</TT> file
-states that all files/directories that end with a <CODE>.nib</CODE>
-should be filtered with the <TT>`wrap'</TT> program before
-checking the file into the repository. The file should
-be filtered though the <TT>`unwrap'</TT> program when the
-file is checked out of the repository. The
-<TT>`cvswrappers'</TT> file also states that a <CODE>COPY</CODE>
-methodology should be used when updating the files in
-the repository (that is no merging should be performed).
-
-</P>
-<P>
-The last example line says that all files that end with
-a <CODE>*.c</CODE> should be filtered with <TT>`indent'</TT>
-before being checked into the repository. Unlike the previous
-example no filtering of the <CODE>*.c</CODE> file is done when
-it is checked out of the repository.
-The <CODE>-t</CODE> filter is called with two arguments,
-the first is the name of the file/directory to filter
-and the second is the pathname to where the resulting
-filtered file should be placed.
-
-</P>
-<P>
-The <CODE>-f</CODE> filter is called with one argument,
-which is the name of the file to filter from. The end
-result of this filter will be a file in the users directory
-that they can work on as they normally would.
-
-</P>
-<P>
-For another example, the following command imports a
-directory, treating files whose name ends in
-<SAMP>`.exe'</SAMP> as binary:
-
-</P>
-
-<PRE>
-cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
-</PRE>
-
-
-
-<H2><A NAME="SEC139" HREF="cvs.html#TOC139">The commit support files</A></H2>
-<P>
-<A NAME="IDX374"></A>
-
-</P>
-<P>
-The <SAMP>`-i'</SAMP> flag in the <TT>`modules'</TT> file can be
-used to run a certain program whenever files are
-committed (see section <A HREF="cvs.html#SEC137">The modules file</A>). The
files described in
-this section provide other, more flexible, ways to run
-programs whenever something is committed.
-
-</P>
-<P>
-There are three kind of programs that can be run on
-commit. They are specified in files in the repository,
-as described below. The following table summarizes the
-file names and the purpose of the corresponding
-programs.
-
-</P>
-<DL COMPACT>
-
-<DT><TT>`commitinfo'</TT>
-<DD>
-The program is responsible for checking that the commit
-is allowed. If it exits with a non-zero exit status
-the commit will be aborted.
-
-<DT><TT>`editinfo'</TT>
-<DD>
-The specified program is used to edit the log message,
-and possibly verify that it contains all required
-fields. This is most useful in combination with the
-<TT>`rcsinfo'</TT> file, which can hold a log message
-template (see section <A HREF="cvs.html#SEC147">Rcsinfo</A>).
-
-<DT><TT>`loginfo'</TT>
-<DD>
-The specified program is called when the commit is
-complete. It receives the log message and some
-additional information and can store the log message in
-a file, or mail it to appropriate persons, or maybe
-post it to a local newsgroup, or... Your
-imagination is the limit!
-</DL>
-
-
-
-<H3><A NAME="SEC140" HREF="cvs.html#TOC140">The common syntax</A></H3>
-<P>
-<A NAME="IDX375"></A>
-<A NAME="IDX376"></A>
-<A NAME="IDX377"></A>
-
-</P>
-
-<P>
-The four files <TT>`commitinfo'</TT>, <TT>`loginfo'</TT>,
-<TT>`rcsinfo'</TT> and <TT>`editinfo'</TT> all have a common
-format. The purpose of the files are described later
-on. The common syntax is described here.
-
-</P>
-<P>
-Each line contains the following:
-
-<UL>
-<LI>
-
-A regular expression
-
-<LI>
-
-A whitespace separator--one or more spaces and/or tabs.
-
-<LI>
-
-A file name or command-line template.
-</UL>
-
-<P>
-Blank lines are ignored. Lines that start with the
-character <SAMP>`#'</SAMP> are treated as comments. Long lines
-unfortunately can <EM>not</EM> be broken in two parts in
-any way.
-
-</P>
-<P>
-The first regular expression that matches the current
-directory name in the repository is used. The rest of the line
-is used as a file name or command-line as appropriate.
-
-</P>
-
-
-<H2><A NAME="SEC141" HREF="cvs.html#TOC141">Commitinfo</A></H2>
-<P>
-<A NAME="IDX378"></A>
-<A NAME="IDX379"></A>
-<A NAME="IDX380"></A>
-
-</P>
-<P>
-The <TT>`commitinfo'</TT> file defines programs to execute
-whenever <SAMP>`cvs commit'</SAMP> is about to execute. These
-programs are used for pre-commit checking to verify
-that the modified, added and removed files are really
-ready to be committed. This could be used, for
-instance, to verify that the changed files conform to
-to your site's standards for coding practice.
-
-</P>
-<P>
-As mentioned earlier, each line in the
-<TT>`commitinfo'</TT> file consists of a regular expression
-and a command-line template. The template can include
-a program name and any number of arguments you wish to
-supply to it. The full path to the current source
-repository is appended to the template, followed by the
-file names of any files involved in the commit (added,
-removed, and modified files).
-
-</P>
-<P>
-The first line with a regular expression matching the
-relative path to the module will be used. If the
-command returns a non-zero exit status the commit will
-be aborted.
-
-</P>
-<P>
-<A NAME="IDX381"></A>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-<A NAME="IDX382"></A>
-All occurances of the name <SAMP>`ALL'</SAMP> appearing as a
-regular expression are used in addition to the first
-matching regular expression or the name <SAMP>`DEFAULT'</SAMP>.
-
-</P>
-<P>
-Note: when CVS is accessing a remote repository,
-<TT>`commitinfo'</TT> will be run on the <EM>remote</EM>
-(i.e., server) side, not the client side (see section <A
HREF="cvs.html#SEC24">Remote repositories</A>).
-
-</P>
-
-
-
-<H2><A NAME="SEC142" HREF="cvs.html#TOC142">Editinfo</A></H2>
-<P>
-<A NAME="IDX383"></A>
-<A NAME="IDX384"></A>
-<A NAME="IDX385"></A>
-<A NAME="IDX386"></A>
-
-</P>
-<P>
-If you want to make sure that all log messages look the
-same way, you can use the <TT>`editinfo'</TT> file to
-specify a program that is used to edit the log message.
-This program could be a custom-made editor that always
-enforces a certain style of the log message, or maybe a
-simple shell script that calls an editor, and checks
-that the entered message contains the required fields.
-
-</P>
-<P>
-If no matching line is found in the <TT>`editinfo'</TT>
-file, the editor specified in the environment variable
-<CODE>$CVSEDITOR</CODE> is used instead. If that variable is
-not set, then the environment variable <CODE>$EDITOR</CODE>
-is used instead. If that variable is not
-set a precompiled default, normally <CODE>vi</CODE>, will be
-used.
-
-</P>
-<P>
-The <TT>`editinfo'</TT> file is often most useful together
-with the <TT>`rcsinfo'</TT> file, which can be used to
-specify a log message template.
-
-</P>
-<P>
-Each line in the <TT>`editinfo'</TT> file consists of a
-regular expression and a command-line template. The
-template must include a program name, and can include
-any number of arguments. The full path to the current
-log message template file is appended to the template.
-
-</P>
-<P>
-One thing that should be noted is that the <SAMP>`ALL'</SAMP>
-keyword is not supported. If more than one matching
-line is found, the first one is used. This can be
-useful for specifying a default edit script in a
-module, and then overriding it in a subdirectory.
-
-</P>
-<P>
-<A NAME="IDX387"></A>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-If the edit script exits with a non-zero exit status,
-the commit is aborted.
-
-</P>
-<P>
-Note: when CVS is accessing a remote repository,
-or when the <SAMP>`-m'</SAMP> or <SAMP>`-F'</SAMP> options to <CODE>cvs
-commit</CODE> are used, <TT>`editinfo'</TT> will not be consulted.
-There is no good workaround for this.
-
-</P>
-
-
-
-<H3><A NAME="SEC143" HREF="cvs.html#TOC143">Editinfo example</A></H3>
-
-<P>
-The following is a little silly example of a
-<TT>`editinfo'</TT> file, together with the corresponding
-<TT>`rcsinfo'</TT> file, the log message template and an
-editor script. We begin with the log message template.
-We want to always record a bug-id number on the first
-line of the log message. The rest of log message is
-free text. The following template is found in the file
-<TT>`/usr/cvssupport/tc.template'</TT>.
-
-</P>
-
-<PRE>
-BugId:
-</PRE>
-
-<P>
-The script <TT>`/usr/cvssupport/bugid.edit'</TT> is used to
-edit the log message.
-
-</P>
-
-<PRE>
-#!/bin/sh
-#
-# bugid.edit filename
-#
-# Call $EDITOR on FILENAME, and verify that the
-# resulting file contains a valid bugid on the first
-# line.
-if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
-if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
-$CVSEDITOR $1
-until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
-do echo -n "No BugId found. Edit again? ([y]/n)"
- read ans
- case ${ans} in
- n*) exit 1;;
- esac
- $CVSEDITOR $1
-done
-</PRE>
-
-<P>
-The <TT>`editinfo'</TT> file contains this line:
-
-</P>
-
-<PRE>
-^tc /usr/cvssupport/bugid.edit
-</PRE>
-
-<P>
-The <TT>`rcsinfo'</TT> file contains this line:
-
-</P>
-
-<PRE>
-^tc /usr/cvssupport/tc.template
-</PRE>
-
-
-
-<H2><A NAME="SEC144" HREF="cvs.html#TOC144">Loginfo</A></H2>
-<P>
-<A NAME="IDX388"></A>
-<A NAME="IDX389"></A>
-<A NAME="IDX390"></A>
-<A NAME="IDX391"></A>
-<A NAME="IDX392"></A>
-
-</P>
-<P>
-The <TT>`loginfo'</TT> file is used to control where
-<SAMP>`cvs commit'</SAMP> log information is sent. The first
-entry on a line is a regular expression which is tested
-against the directory that the change is being made to,
-relative to the <CODE>$CVSROOT</CODE>. If a match is found, then
-the remainder of the line is a filter program that
-should expect log information on its standard input.
-
-</P>
-<P>
-The filter program may use one and only one % modifier
-(a la printf). If <SAMP>`%s'</SAMP> is specified in the filter
-program, a brief title is included (enclosed in single
-quotes) showing the modified file names.
-
-</P>
-<P>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-All occurances of the name <SAMP>`ALL'</SAMP> appearing as a
-regular expression are used in addition to the first
-matching regular expression or <SAMP>`DEFAULT'</SAMP>.
-
-</P>
-<P>
-The first matching regular expression is used.
-
-</P>
-<P>
-See section <A HREF="cvs.html#SEC139">The commit support files</A>, for a
description of the syntax of
-the <TT>`loginfo'</TT> file.
-
-</P>
-<P>
-Note: when CVS is accessing a remote repository,
-<TT>`loginfo'</TT> will be run on the <EM>remote</EM>
-(i.e., server) side, not the client side (see section <A
HREF="cvs.html#SEC24">Remote repositories</A>).
-
-</P>
-
-
-
-<H3><A NAME="SEC145" HREF="cvs.html#TOC145">Loginfo example</A></H3>
-
-<P>
-The following <TT>`loginfo'</TT> file, together with the
-tiny shell-script below, appends all log messages
-to the file <TT>`$CVSROOT/CVSROOT/commitlog'</TT>,
-and any commits to the administrative files (inside
-the <TT>`CVSROOT'</TT> directory) are also logged in
-<TT>`/usr/adm/cvsroot-log'</TT>.
-
-</P>
-
-<PRE>
-ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog
-^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log
-</PRE>
-
-<P>
-The shell-script <TT>`/usr/local/bin/cvs-log'</TT> looks
-like this:
-
-</P>
-
-<PRE>
-#!/bin/sh
-(echo "-----------------------------------------------------------------";
- echo -n $USER" ";
- date;
- echo;
- sed '1s+'${CVSROOT}'++') >> $1
-</PRE>
-
-
-
-<H3><A NAME="SEC146" HREF="cvs.html#TOC146">Keeping a checked out copy</A></H3>
-
-<P>
-<A NAME="IDX393"></A>
-<A NAME="IDX394"></A>
-
-</P>
-<P>
-It is often useful to maintain a directory tree which
-contains files which correspond to the latest version
-in the repository. For example, other developers might
-want to refer to the latest sources without having to
-check them out, or you might be maintaining a web site
-with CVS and want every checkin to cause the files
-used by the web server to be updated.
-
-</P>
-<P>
-The way to do this is by having loginfo invoke
-<CODE>cvs update</CODE>. Doing so in the naive way will
-cause a problem with locks, so the <CODE>cvs update</CODE>
-must be run in the background.
-Here is an example (this should all be on one line):
-
-</P>
-
-<PRE>
-^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs;
- cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
-</PRE>
-
-<P>
-This will cause checkins to repository directories
-starting with <CODE>cyclic-pages</CODE> to update the checked
-out tree in <TT>`/u/www/local-docs'</TT>.
-
-</P>
-
-
-<H2><A NAME="SEC147" HREF="cvs.html#TOC147">Rcsinfo</A></H2>
-<P>
-<A NAME="IDX395"></A>
-<A NAME="IDX396"></A>
-<A NAME="IDX397"></A>
-<A NAME="IDX398"></A>
-
-</P>
-<P>
-The <TT>`rcsinfo'</TT> file can be used to specify a form to
-edit when filling out the commit log. The
-<TT>`rcsinfo'</TT> file has a syntax similar to the
-<TT>`editinfo'</TT>, <TT>`commitinfo'</TT> and <TT>`loginfo'</TT>
-files. See section <A HREF="cvs.html#SEC140">The common syntax</A>. Unlike
the other files the second
-part is <EM>not</EM> a command-line template. Instead,
-the part after the regular expression should be a full pathname to
-a file containing the log message template.
-
-</P>
-<P>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-All occurances of the name <SAMP>`ALL'</SAMP> appearing as a
-regular expression are used in addition to the first
-matching regular expression or <SAMP>`DEFAULT'</SAMP>.
-
-</P>
-<P>
-The log message template will be used as a default log
-message. If you specify a log message with <SAMP>`cvs
-commit -m <VAR>message</VAR>'</SAMP> or <SAMP>`cvs commit -f
-<VAR>file</VAR>'</SAMP> that log message will override the
-template.
-
-</P>
-<P>
-See section <A HREF="cvs.html#SEC143">Editinfo example</A>, for an example
<TT>`rcsinfo'</TT>
-file.
-
-</P>
-<P>
-When CVS is accessing a remote repository,
-the contents of <TT>`rcsinfo'</TT> at the time a directory
-is first checked out will specify a template which does
-not then change. If you edit <TT>`rcsinfo'</TT> or its
-templates, you may need to check out a new working
-directory.
-
-</P>
-
-
-<H2><A NAME="SEC148" HREF="cvs.html#TOC148">Ignoring files via
cvsignore</A></H2>
-<P>
-<A NAME="IDX399"></A>
-<A NAME="IDX400"></A>
-<A NAME="IDX401"></A>
-
-</P>
-<P>
-There are certain file names that frequently occur
-inside your working copy, but that you don't want to
-put under CVS control. Examples are all the object
-files that you get while you compile your sources.
-Normally, when you run <SAMP>`cvs update'</SAMP>, it prints a
-line for each file it encounters that it doesn't know
-about (see section <A HREF="cvs.html#SEC134">update output</A>).
-
-</P>
-<P>
-CVS has a list of files (or sh(1) file name patterns)
-that it should ignore while running <CODE>update</CODE>,
-<CODE>import</CODE> and <CODE>release</CODE>.
-This list is constructed in the following way.
-
-</P>
-
-<UL>
-<LI>
-
-The list is initialized to include certain file name
-patterns: names associated with CVS
-administration, or with other common source control
-systems; common names for patch files, object files,
-archive files, and editor backup files; and other names
-that are usually artifacts of assorted utilities.
-Currently, the default list of ignored file name
-patterns is:
-
-<A NAME="IDX402"></A>
-<A NAME="IDX403"></A>
-
-<PRE>
- RCS SCCS CVS CVS.adm
- RCSLOG cvslog.*
- tags TAGS
- .make.state .nse_depinfo
- *~ #* .#* ,* _$* *$
- *.old *.bak *.BAK *.orig *.rej .del-*
- *.a *.olb *.o *.obj *.so *.exe
- *.Z *.elc *.ln
- core
-</PRE>
-
-<LI>
-
-The per-repository list in
-<TT>`$CVSROOT/CVSROOT/cvsignore'</TT> is appended to
-the list, if that file exists.
-
-<LI>
-
-The per-user list in <TT>`.cvsignore'</TT> in your home
-directory is appended to the list, if it exists.
-
-<LI>
-
-Any entries in the environment variable
-<CODE>$CVSIGNORE</CODE> is appended to the list.
-
-<LI>
-
-Any <SAMP>`-I'</SAMP> options given to CVS is appended.
-
-<LI>
-
-As CVS traverses through your directories, the contents
-of any <TT>`.cvsignore'</TT> will be appended to the list.
-The patterns found in <TT>`.cvsignore'</TT> are only valid
-for the directory that contains them, not for
-any sub-directories.
-</UL>
-
-<P>
-In any of the 5 places listed above, a single
-exclamation mark (<SAMP>`!'</SAMP>) clears the ignore list.
-This can be used if you want to store any file which
-normally is ignored by CVS.
-
-</P>
-
-
-<H2><A NAME="SEC149" HREF="cvs.html#TOC149">The history file</A></H2>
-<P>
-<A NAME="IDX404"></A>
-<A NAME="IDX405"></A>
-
-</P>
-<P>
-The file <TT>`$CVSROOT/CVSROOT/history'</TT> is used
-to log information for the <CODE>history</CODE> command
-(see section <A HREF="cvs.html#SEC110">history--Show status of files and
users</A>). This file must be created to turn
-on logging. This is done automatically if the
-<CODE>cvs init</CODE> command is used to set up the
-repository (see section <A HREF="cvs.html#SEC23">Creating a repository</A>).
-
-</P>
-<P>
-The file format of the <TT>`history'</TT> file is
-documented only in comments in the CVS source
-code, but generally programs should use the <CODE>cvs
-history</CODE> command to access it anyway, in case the
-format changes with future releases of CVS.
-
-</P>
-
-
-<H2><A NAME="SEC150" HREF="cvs.html#TOC150">Expansions in administrative
files</A></H2>
-
-<P>
-Sometimes in writing an administrative file, you might
-want the file to be able to know various things based
-on environment CVS is running in. There are
-several mechanisms to do that.
-
-</P>
-<P>
-To find the home directory of the user running CVS
-(from the <CODE>HOME</CODE> environment variable), use
-<SAMP>`~'</SAMP> followed by <SAMP>`/'</SAMP> or the end of the line.
-Likewise for the home directory of <VAR>user</VAR>, use
-<SAMP>`~<VAR>user</VAR>'</SAMP>. These variables are expanded on
-the server machine, and don't get any resonable
-expansion if pserver (see section <A HREF="cvs.html#SEC26">Direct connection
with password authentication</A>)
-is in used; therefore user variables (see below) may be
-a better choice to customize behavior based on the user
-running CVS.
-
-</P>
-<P>
-One may want to know about various pieces of
-information internal to CVS. A CVS internal
-variable has the syntax <CODE>${<VAR>variable</VAR>}</CODE>,
-where <VAR>variable</VAR> starts with a letter and consists
-of alphanumberic characters and <SAMP>`_'</SAMP>. If the
-character following <VAR>variable</VAR> is a
-non-alphanumeric character other than <SAMP>`_'</SAMP>, the
-<SAMP>`{'</SAMP> and <SAMP>`}'</SAMP> can be omitted. The CVS
-internal variables are:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>CVSROOT</CODE>
-<DD>
-This is the value of the CVS root in use.
-See section <A HREF="cvs.html#SEC15">The Repository</A>, for a description of
the various
-ways to specify this.
-
-<DT><CODE>RCSBIN</CODE>
-<DD>
-This is the value CVS is using for where to find
-RCS binaries. See section <A HREF="cvs.html#SEC89">Global options</A>, for a
-description of how to specify this.
-
-<DT><CODE>CVSEDITOR</CODE>
-<DD>
-<DT><CODE>VISUAL</CODE>
-<DD>
-<DT><CODE>EDITOR</CODE>
-<DD>
-These all expand to the same value, which is the editor
-that CVS is using. See section <A HREF="cvs.html#SEC89">Global options</A>,
for how
-to specify this.
-
-<DT><CODE>USER</CODE>
-<DD>
-Username of the user running CVS (on the CVS
-server machine).
-</DL>
-
-<P>
-If you want to pass a value to the administrative files
-which the user that is running CVS can specify,
-use a user variable. To expand a user variable, the
-administrative file contains
-<CODE>${=<VAR>variable</VAR>}</CODE>. To set a user variable,
-specify the global option <SAMP>`-s'</SAMP> to CVS, with
-argument <CODE><VAR>variable</VAR>=<VAR>value</VAR></CODE>. It may be
-particularly useful to specify this option via
-<TT>`.cvsrc'</TT> (see section <A HREF="cvs.html#SEC88">Default options and
the ~/.cvsrc file</A>).
-
-</P>
-<P>
-For example, if you want the administrative file to
-refer to a test directory you might create a user
-variable <CODE>TESTDIR</CODE>. Then if CVS is invoked
-as <CODE>cvs -s TESTDIR=/work/local/tests</CODE>, and the
-administrative file contains <CODE>sh
-${=TESTDIR}/runtests</CODE>, then that string is expanded
-to <CODE>sh /work/local/tests/runtests</CODE>.
-
-</P>
-<P>
-All other strings containing <SAMP>`$'</SAMP> are reserved;
-there is no way to quote a <SAMP>`$'</SAMP> character so that
-<SAMP>`$'</SAMP> represents itself.
-
-</P>
-
-
-<H1><A NAME="SEC151" HREF="cvs.html#TOC151">All environment variables which
affect CVS</A></H1>
-<P>
-<A NAME="IDX406"></A>
-<A NAME="IDX407"></A>
-
-</P>
-<P>
-This is a complete list of all environment variables
-that affect CVS.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>$CVSIGNORE</CODE>
-<DD>
-<A NAME="IDX408"></A>
-
-A whitespace-separated list of file name patterns that
-CVS should ignore. See section <A HREF="cvs.html#SEC148">Ignoring files via
cvsignore</A>.
-
-<A NAME="IDX409"></A>
-<DT><CODE>$CVSWRAPPERS</CODE>
-<DD>
-A whitespace-separated list of file name patterns that
-CVS should treat as wrappers. See section <A HREF="cvs.html#SEC138">The
cvswrappers file</A>.
-
-<A NAME="IDX410"></A>
-<A NAME="IDX411"></A>
-<DT><CODE>$CVSREAD</CODE>
-<DD>
-If this is set, <CODE>checkout</CODE> and <CODE>update</CODE> will
-try hard to make the files in your working directory
-read-only. When this is not set, the default behavior
-is to permit modification of your working files.
-
-<A NAME="IDX412"></A>
-<DT><CODE>$CVSROOT</CODE>
-<DD>
-Should contain the full pathname to the root of the CVS
-source repository (where the RCS history files are
-kept). This information must be available to CVS for
-most commands to execute; if <CODE>$CVSROOT</CODE> is not set,
-or if you wish to override it for one invocation, you
-can supply it on the command line: <SAMP>`cvs -d cvsroot
-cvs_command...'</SAMP> Once you have checked out a working
-directory, CVS stores the appropriate root (in
-the file <TT>`CVS/Root'</TT>), so normally you only need to
-worry about this when initially checking out a working
-directory.
-
-<A NAME="IDX413"></A>
-<A NAME="IDX414"></A>
-<DT><CODE>$EDITOR</CODE>
-<DD>
-<DT><CODE>$CVSEDITOR</CODE>
-<DD>
-Specifies the program to use for recording log messages
-during commit. If not set, the default is
-<SAMP>`/usr/ucb/vi'</SAMP>. <CODE>$CVSEDITOR</CODE> overrides
-<CODE>$EDITOR</CODE>. <CODE>$CVSEDITOR</CODE> does not exist in
-CVS 1.3, but the next release will probably
-include it.
-
-<A NAME="IDX415"></A>
-<DT><CODE>$PATH</CODE>
-<DD>
-If <CODE>$RCSBIN</CODE> is not set, and no path is compiled
-into CVS, it will use <CODE>$PATH</CODE> to try to find all
-programs it uses.
-
-<A NAME="IDX416"></A>
-<DT><CODE>$RCSBIN</CODE>
-<DD>
-This is the value CVS is using for where to find
-RCS binaries. See section <A HREF="cvs.html#SEC89">Global options</A>, for a
-description of how to specify this. If not set, a
-compiled-in value is used, or your <CODE>$PATH</CODE> is searched.
-
-<A NAME="IDX417"></A>
-<DT><CODE>$HOME</CODE>
-<DD>
-<A NAME="IDX418"></A>
-<DT><CODE>$HOMEPATH</CODE>
-<DD>
-Used to locate the directory where the <TT>`.cvsrc'</TT>
-file is searched (<CODE>$HOMEPATH</CODE> is used for Windows-NT).
-see section <A HREF="cvs.html#SEC88">Default options and the ~/.cvsrc file</A>
-
-<A NAME="IDX419"></A>
-<DT><CODE>$CVS_RSH</CODE>
-<DD>
-Specifies the external program which CVS connects with,
-when <CODE>:ext:</CODE> access method is specified.
-see section <A HREF="cvs.html#SEC25">Connecting with rsh</A>.
-
-<DT><CODE>$CVS_SERVER</CODE>
-<DD>
-Used in client-server mode when accessing a remote
-repository using RSH. It specifies the name of
-the program to start on the server side when accessing
-a remote repository using RSH. The default value
-is <CODE>cvs</CODE>. see section <A HREF="cvs.html#SEC25">Connecting with
rsh</A>
-
-<DT><CODE>$CVS_PASSFILE</CODE>
-<DD>
-Used in client-server mode when accessing the <CODE>cvs
-login server</CODE>. Default value is <TT>`$HOME/.cvspass'</TT>.
-see section <A HREF="cvs.html#SEC28">Using the client with password
authentication</A>
-
-<DT><CODE>$CVS_PASSWORD</CODE>
-<DD>
-Used in client-server mode when accessing the <CODE>cvs
-login server</CODE>.
-see section <A HREF="cvs.html#SEC28">Using the client with password
authentication</A>
-
-<DT><CODE>$CVS_CLIENT_PORT</CODE>
-<DD>
-Used in client-server mode when accessing the server
-via Kerberos.
-see section <A HREF="cvs.html#SEC30">Direct connection with kerberos</A>
-
-<A NAME="IDX420"></A>
-<DT><CODE>$CVS_RCMD_PORT</CODE>
-<DD>
-Used in client-server mode. If set, specifies the port
-number to be used when accessing the RCMD demon on
-the server side. (Currently not used for Unix clients).
-
-<A NAME="IDX421"></A>
-<DT><CODE>$CVS_CLIENT_LOG</CODE>
-<DD>
-Used for debugging only in client-server
-mode. If set, everything send to the server is logged
-into <TT>`<CODE>$CVS_CLIENT_LOG</CODE>.in'</TT> and everything
-send from the server is logged into
-<TT>`<CODE>$CVS_CLIENT_LOG</CODE>.out'</TT>.
-
-<A NAME="IDX422"></A>
-<DT><CODE>$CVS_SERVER_SLEEP</CODE>
-<DD>
-Used only for debugging the server side in
-client-server mode. If set, delays the start of the
-server child process the the specified amount of
-seconds so that you can attach to it with a debugger.
-
-<A NAME="IDX423"></A>
-<DT><CODE>$CVS_IGNORE_REMOTE_ROOT</CODE>
-<DD>
-(What is the purpose of this variable?)
-
-<A NAME="IDX424"></A>
-<DT><CODE>$COMSPEC</CODE>
-<DD>
-Used under OS/2 only. It specifies the name of the
-command interpreter and defaults to CMD.EXE.
-
-<A NAME="IDX425"></A>
-<DT><CODE>$TMPDIR</CODE>
-<DD>
-<A NAME="IDX426"></A>
-<DT><CODE>$TMP</CODE>
-<DD>
-<A NAME="IDX427"></A>
-<DT><CODE>$TEMP</CODE>
-<DD>
-<A NAME="IDX428"></A>
-Directory in which temporary files are located. Those
-parts of CVS which are implemented using RCS
-inspect the above variables in the order they appear
-above and the first value found is taken; if none of
-them are set, a host-dependent default is used,
-typically <TT>`/tmp'</TT>. The CVS server uses
-<CODE>TMPDIR</CODE>. See section <A HREF="cvs.html#SEC89">Global options</A>,
for a
-description of how to specify this.
-Some parts of CVS will always use <TT>`/tmp'</TT> (via
-the <CODE>tmpnam</CODE> function provided by the system).
-
-On Windows NT, <CODE>TMP</CODE> is used (via the <CODE>_tempnam</CODE>
-function provided by the system).
-
-The <CODE>patch</CODE> program which is used by the CVS
-client uses <CODE>TMPDIR</CODE>, and if it is not set, uses
-<TT>`/tmp'</TT> (at least with GNU patch 2.1).
-</DL>
-
-<P>
-CVS invokes RCS to perform certain
-operations. The following environment
-variables affect RCS. Note that if you are using
-the client/server CVS, these variables need to be
-set on the server side (which may or not may be
-possible depending on how you are connecting). There
-is probably not any need to set any of them, however.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>$LOGNAME</CODE>
-<DD>
-<A NAME="IDX429"></A>
-
-<A NAME="IDX430"></A>
-<DT><CODE>$USER</CODE>
-<DD>
-If set, they affect who RCS thinks you are. If you
-have trouble checking in files it might be because your
-login name differs from the setting of e.g.
-<CODE>$LOGNAME</CODE>.
-
-<A NAME="IDX431"></A>
-<DT><CODE>$RCSINIT</CODE>
-<DD>
-Options prepended to the argument list, separated by
-spaces. A backslash escapes spaces within an option.
-The <CODE>$RCSINIT</CODE> options are prepended to the
-argument lists of most RCS commands.
-</DL>
-
-
-
-<H1><A NAME="SEC152" HREF="cvs.html#TOC152">Troubleshooting</A></H1>
-
-
-
-<H2><A NAME="SEC153" HREF="cvs.html#TOC153">Magic branch numbers</A></H2>
-
-<P>
-Externally, branch numbers consist of an odd number of
-dot-separated decimal integers. See section <A HREF="cvs.html#SEC8">Revision
numbers</A>. That is not the whole truth, however. For
-efficiency reasons CVS sometimes inserts an extra 0
-in the second rightmost position (1.2.3 becomes
-1.2.0.3, 8.9.10.11.12 becomes 8.9.10.11.0.12 and so
-on).
-
-</P>
-<P>
-CVS does a pretty good job at hiding these so
-called magic branches, but in a few places the hiding
-is incomplete:
-
-</P>
-
-<UL>
-<LI>
-
-The magic branch number appears in the output from
-<CODE>cvs log</CODE>.
-
-<LI>
-
-You cannot specify a symbolic branch name to <CODE>cvs
-admin</CODE>.
-
-</UL>
-
-<P>
-You can use the <CODE>admin</CODE> command to reassign a
-symbolic name to a branch the way RCS expects it
-to be. If <CODE>R4patches</CODE> is assigned to the branch
-1.4.2 (magic branch number 1.4.0.2) in file
-<TT>`numbers.c'</TT> you can do this:
-
-</P>
-
-<PRE>
-$ cvs admin -NR4patches:1.4.2 numbers.c
-</PRE>
-
-<P>
-It only works if at least one revision is already
-committed on the branch. Be very careful so that you
-do not assign the tag to the wrong number. (There is
-no way to see how the tag was assigned yesterday).
-
-</P>
-
-
-<H1><A NAME="SEC154" HREF="cvs.html#TOC154">GNU GENERAL PUBLIC LICENSE</A></H1>
-
-
-
-<H1><A NAME="SEC155" HREF="cvs.html#TOC155">Index</A></H1>
-<P>
-<A NAME="IDX432"></A>
-
-</P>
-<P>
-Jump to:
-<A HREF="#cindex_-">-</A>
--
-<A HREF="#cindex_.">.</A>
--
-<A HREF="#cindex_/">/</A>
--
-<A HREF="#cindex_:">:</A>
--
-<A HREF="#cindex_<"><</A>
--
-<A HREF="#cindex_=">=</A>
--
-<A HREF="#cindex_>">></A>
--
-<A HREF="#cindex__">_</A>
--
-<A HREF="#cindex_a">a</A>
--
-<A HREF="#cindex_b">b</A>
--
-<A HREF="#cindex_c">c</A>
--
-<A HREF="#cindex_d">d</A>
--
-<A HREF="#cindex_e">e</A>
--
-<A HREF="#cindex_f">f</A>
--
-<A HREF="#cindex_g">g</A>
--
-<A HREF="#cindex_h">h</A>
--
-<A HREF="#cindex_i">i</A>
--
-<A HREF="#cindex_j">j</A>
--
-<A HREF="#cindex_k">k</A>
--
-<A HREF="#cindex_l">l</A>
--
-<A HREF="#cindex_m">m</A>
--
-<A HREF="#cindex_n">n</A>
--
-<A HREF="#cindex_o">o</A>
--
-<A HREF="#cindex_p">p</A>
--
-<A HREF="#cindex_r">r</A>
--
-<A HREF="#cindex_s">s</A>
--
-<A HREF="#cindex_t">t</A>
--
-<A HREF="#cindex_u">u</A>
--
-<A HREF="#cindex_v">v</A>
--
-<A HREF="#cindex_w">w</A>
--
-<A HREF="#cindex_z">z</A>
-<P>
-<H2><A NAME="cindex_-">-</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX229">-j (merging branches)</A>
-<LI><A HREF="cvs.html#IDX286">-k (RCS kflags)</A>
-</DIR>
-<H2><A NAME="cindex_.">.</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX356">.# files</A>
-<LI><A HREF="cvs.html#IDX66">.bashrc, setting CVSROOT in</A>
-<LI><A HREF="cvs.html#IDX64">.cshrc, setting CVSROOT in</A>
-<LI><A HREF="cvs.html#IDX300">.cvsrc file</A>
-<LI><A HREF="cvs.html#IDX63">.profile, setting CVSROOT in</A>
-<LI><A HREF="cvs.html#IDX65">.tcshrc, setting CVSROOT in</A>
-</DIR>
-<H2><A NAME="cindex_/">/</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX60">/usr/local/cvsroot, as example repository</A>
-</DIR>
-<H2><A NAME="cindex_:">:</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX101">:ext:</A>
-<LI><A HREF="cvs.html#IDX114">:kserver:</A>
-<LI><A HREF="cvs.html#IDX62">:local:</A>
-<LI><A HREF="cvs.html#IDX110">:pserver:</A>
-<LI><A HREF="cvs.html#IDX100">:server:</A>
-</DIR>
-<H2><A NAME="cindex_<"><</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX157"><<<<<<<</A>
-</DIR>
-<H2><A NAME="cindex_=">=</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX159">=======</A>
-</DIR>
-<H2><A NAME="cindex_>">></A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX158">>>>>>>></A>
-</DIR>
-<H2><A NAME="cindex__">_</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX357">__ files (VMS)</A>
-</DIR>
-<H2><A NAME="cindex_a">a</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX35">A sample session</A>
-<LI><A HREF="cvs.html#IDX185">abandoning work</A>
-<LI><A HREF="cvs.html#IDX2">About this manual</A>
-<LI><A HREF="cvs.html#IDX244">add (subcommand)</A>
-<LI><A HREF="cvs.html#IDX203">Adding a tag</A>
-<LI><A HREF="cvs.html#IDX243">Adding files</A>
-<LI><A HREF="cvs.html#IDX328">Admin (subcommand)</A>
-<LI><A HREF="cvs.html#IDX79">Administrative files (intro)</A>
-<LI><A HREF="cvs.html#IDX358">Administrative files (reference)</A>
-<LI><A HREF="cvs.html#IDX84">Administrative files, editing them</A>
-<LI><A HREF="cvs.html#IDX382">ALL in commitinfo</A>
-<LI><A HREF="cvs.html#IDX267">annotate (subcommand)</A>
-<LI><A HREF="cvs.html#IDX167">Atomic transactions, lack of</A>
-<LI><A HREF="cvs.html#IDX109">authenticated client, using</A>
-<LI><A HREF="cvs.html#IDX104">authenticating server, setting up</A>
-<LI><A HREF="cvs.html#IDX273">Author keyword</A>
-<LI><A HREF="cvs.html#IDX403">Automatically ignored files</A>
-<LI><A HREF="cvs.html#IDX327">Avoiding editor invocation</A>
-</DIR>
-<H2><A NAME="cindex_b">b</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX288">Binary files</A>
-<LI><A HREF="cvs.html#IDX231">Branch merge example</A>
-<LI><A HREF="cvs.html#IDX30">Branch number</A>
-<LI><A HREF="cvs.html#IDX213">Branch numbers</A>
-<LI><A HREF="cvs.html#IDX211">Branch, creating a</A>
-<LI><A HREF="cvs.html#IDX254">Branch, vendor-</A>
-<LI><A HREF="cvs.html#IDX194">Branches</A>
-<LI><A HREF="cvs.html#IDX207">Branches motivation</A>
-<LI><A HREF="cvs.html#IDX225">Branches, copying changes between</A>
-<LI><A HREF="cvs.html#IDX216">Branches, sticky</A>
-<LI><A HREF="cvs.html#IDX146">Bringing a file up to date</A>
-<LI><A HREF="cvs.html#IDX7">Bugs, known in this manual</A>
-<LI><A HREF="cvs.html#IDX10">Bugs, reporting (manual)</A>
-</DIR>
-<H2><A NAME="cindex_c">c</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX226">Changes, copying between branches</A>
-<LI><A HREF="cvs.html#IDX329">Changing a log message</A>
-<LI><A HREF="cvs.html#IDX394">checked out copy, keeping</A>
-<LI><A HREF="cvs.html#IDX365">Checkin program</A>
-<LI><A HREF="cvs.html#IDX379">Checking commits</A>
-<LI><A HREF="cvs.html#IDX42">Checking out source</A>
-<LI><A HREF="cvs.html#IDX340">Checkout (subcommand)</A>
-<LI><A HREF="cvs.html#IDX366">Checkout program</A>
-<LI><A HREF="cvs.html#IDX181">checkout, as term for getting ready to edit</A>
-<LI><A HREF="cvs.html#IDX45">Checkout, example</A>
-<LI><A HREF="cvs.html#IDX193">choosing, reserved or unreserved checkouts</A>
-<LI><A HREF="cvs.html#IDX50">Cleaning up</A>
-<LI><A HREF="cvs.html#IDX97">Client/Server Operation</A>
-<LI><A HREF="cvs.html#IDX341">Co (subcommand)</A>
-<LI><A HREF="cvs.html#IDX293">Command reference</A>
-<LI><A HREF="cvs.html#IDX298">Command structure</A>
-<LI><A HREF="cvs.html#IDX337">Comment leader</A>
-<LI><A HREF="cvs.html#IDX342">Commit (subcommand)</A>
-<LI><A HREF="cvs.html#IDX374">Commit files</A>
-<LI><A HREF="cvs.html#IDX291">Commit, when to</A>
-<LI><A HREF="cvs.html#IDX378">Commitinfo</A>
-<LI><A HREF="cvs.html#IDX46">Committing changes</A>
-<LI><A HREF="cvs.html#IDX318">Common options</A>
-<LI><A HREF="cvs.html#IDX377">Common syntax of info files</A>
-<LI><A HREF="cvs.html#IDX424">COMSPEC</A>
-<LI><A HREF="cvs.html#IDX156">Conflict markers</A>
-<LI><A HREF="cvs.html#IDX161">Conflict resolution</A>
-<LI><A HREF="cvs.html#IDX154">Conflicts (merge example)</A>
-<LI><A HREF="cvs.html#IDX18">Contributors (CVS program)</A>
-<LI><A HREF="cvs.html#IDX5">Contributors (manual)</A>
-<LI><A HREF="cvs.html#IDX224">Copying changes</A>
-<LI><A HREF="cvs.html#IDX331">Correcting a log message</A>
-<LI><A HREF="cvs.html#IDX210">Creating a branch</A>
-<LI><A HREF="cvs.html#IDX118">Creating a project</A>
-<LI><A HREF="cvs.html#IDX92">Creating a repository</A>
-<LI><A HREF="cvs.html#IDX17">Credits (CVS program)</A>
-<LI><A HREF="cvs.html#IDX6">Credits (manual)</A>
-<LI><A HREF="cvs.html#IDX192">CVS 1.6, and watches</A>
-<LI><A HREF="cvs.html#IDX297">CVS command structure</A>
-<LI><A HREF="cvs.html#IDX105">CVS passwd file</A>
-<LI><A HREF="cvs.html#IDX16">CVS, history of</A>
-<LI><A HREF="cvs.html#IDX14">CVS, introduction to</A>
-<LI><A HREF="cvs.html#IDX421">CVS_CLIENT_LOG</A>
-<LI><A HREF="cvs.html#IDX115">CVS_CLIENT_PORT</A>
-<LI><A HREF="cvs.html#IDX423">CVS_IGNORE_REMOTE_ROOT</A>
-<LI><A HREF="cvs.html#IDX111">CVS_PASSFILE, environment variable</A>
-<LI><A HREF="cvs.html#IDX112">CVS_PASSWORD, environment variable</A>
-<LI><A HREF="cvs.html#IDX420">CVS_RCMD_PORT</A>
-<LI><A HREF="cvs.html#IDX419">CVS_RSH</A>
-<LI><A HREF="cvs.html#IDX99">CVS_SERVER</A>
-<LI><A HREF="cvs.html#IDX422">CVS_SERVER_SLEEP</A>
-<LI><A HREF="cvs.html#IDX414">CVSEDITOR</A>
-<LI><A HREF="cvs.html#IDX48">CVSEDITOR, environment variable</A>
-<LI><A HREF="cvs.html#IDX408">CVSIGNORE</A>
-<LI><A HREF="cvs.html#IDX399">cvsignore (admin file), global</A>
-<LI><A HREF="cvs.html#IDX410">CVSREAD</A>
-<LI><A HREF="cvs.html#IDX316">CVSREAD, overriding</A>
-<LI><A HREF="cvs.html#IDX412">CVSROOT</A>
-<LI><A HREF="cvs.html#IDX61">cvsroot</A>
-<LI><A HREF="cvs.html#IDX361">CVSROOT (file)</A>
-<LI><A HREF="cvs.html#IDX67">CVSROOT, environment variable</A>
-<LI><A HREF="cvs.html#IDX81">CVSROOT, module name</A>
-<LI><A HREF="cvs.html#IDX90">CVSROOT, multiple repositories</A>
-<LI><A HREF="cvs.html#IDX309">CVSROOT, overriding</A>
-<LI><A HREF="cvs.html#IDX75">CVSUMASK</A>
-<LI><A HREF="cvs.html#IDX409">CVSWRAPPERS</A>
-<LI><A HREF="cvs.html#IDX371">cvswrappers (admin file)</A>
-<LI><A HREF="cvs.html#IDX372">CVSWRAPPERS, environment variable</A>
-</DIR>
-<H2><A NAME="cindex_d">d</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX274">Date keyword</A>
-<LI><A HREF="cvs.html#IDX320">Dates</A>
-<LI><A HREF="cvs.html#IDX28">Decimal revision number</A>
-<LI><A HREF="cvs.html#IDX381">DEFAULT in commitinfo</A>
-<LI><A HREF="cvs.html#IDX387">DEFAULT in editinfo</A>
-<LI><A HREF="cvs.html#IDX123">Defining a module</A>
-<LI><A HREF="cvs.html#IDX82">Defining modules (intro)</A>
-<LI><A HREF="cvs.html#IDX363">Defining modules (reference manual)</A>
-<LI><A HREF="cvs.html#IDX247">Deleting files</A>
-<LI><A HREF="cvs.html#IDX334">Deleting revisions</A>
-<LI><A HREF="cvs.html#IDX219">Deleting sticky tags</A>
-<LI><A HREF="cvs.html#IDX241">Descending directories</A>
-<LI><A HREF="cvs.html#IDX55">Diff</A>
-<LI><A HREF="cvs.html#IDX343">Diff (subcommand)</A>
-<LI><A HREF="cvs.html#IDX236">Differences, merging</A>
-<LI><A HREF="cvs.html#IDX262">Directories, moving</A>
-<LI><A HREF="cvs.html#IDX240">Directory, descending</A>
-<LI><A HREF="cvs.html#IDX89">Disjoint repositories</A>
-<LI><A HREF="cvs.html#IDX391">Distributing log messages</A>
-<LI><A HREF="cvs.html#IDX153">driver.c (merge example)</A>
-</DIR>
-<H2><A NAME="cindex_e">e</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX182">edit (subcommand)</A>
-<LI><A HREF="cvs.html#IDX383">editinfo (admin file)</A>
-<LI><A HREF="cvs.html#IDX83">Editing administrative files</A>
-<LI><A HREF="cvs.html#IDX124">Editing the modules file</A>
-<LI><A HREF="cvs.html#IDX413">EDITOR</A>
-<LI><A HREF="cvs.html#IDX326">Editor, avoiding invocation of</A>
-<LI><A HREF="cvs.html#IDX49">EDITOR, environment variable</A>
-<LI><A HREF="cvs.html#IDX311">EDITOR, overriding</A>
-<LI><A HREF="cvs.html#IDX384">Editor, specifying per module</A>
-<LI><A HREF="cvs.html#IDX190">editors (subcommand)</A>
-<LI><A HREF="cvs.html#IDX162">emerge</A>
-<LI><A HREF="cvs.html#IDX406">Environment variables</A>
-<LI><A HREF="cvs.html#IDX11">Errors, reporting (manual)</A>
-<LI><A HREF="cvs.html#IDX36">Example of a work-session</A>
-<LI><A HREF="cvs.html#IDX152">Example of merge</A>
-<LI><A HREF="cvs.html#IDX232">Example, branch merge</A>
-<LI><A HREF="cvs.html#IDX344">Export (subcommand)</A>
-<LI><A HREF="cvs.html#IDX364">Export program</A>
-</DIR>
-<H2><A NAME="cindex_f">f</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX43">Fetching source</A>
-<LI><A HREF="cvs.html#IDX129">File locking</A>
-<LI><A HREF="cvs.html#IDX72">File permissions</A>
-<LI><A HREF="cvs.html#IDX135">File status</A>
-<LI><A HREF="cvs.html#IDX259">Files, moving</A>
-<LI><A HREF="cvs.html#IDX359">Files, reference manual</A>
-<LI><A HREF="cvs.html#IDX332">Fixing a log message</A>
-<LI><A HREF="cvs.html#IDX325">Forcing a tag match</A>
-<LI><A HREF="cvs.html#IDX396">Form for log message</A>
-<LI><A HREF="cvs.html#IDX299">Format of CVS commands</A>
-</DIR>
-<H2><A NAME="cindex_g">g</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX37">Getting started</A>
-<LI><A HREF="cvs.html#IDX41">Getting the source</A>
-<LI><A HREF="cvs.html#IDX400">Global cvsignore</A>
-<LI><A HREF="cvs.html#IDX303">Global options</A>
-<LI><A HREF="cvs.html#IDX73">Group</A>
-</DIR>
-<H2><A NAME="cindex_h">h</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX275">Header keyword</A>
-<LI><A HREF="cvs.html#IDX345">History (subcommand)</A>
-<LI><A HREF="cvs.html#IDX263">History browsing</A>
-<LI><A HREF="cvs.html#IDX404">History file</A>
-<LI><A HREF="cvs.html#IDX69">History files</A>
-<LI><A HREF="cvs.html#IDX15">History of CVS</A>
-<LI><A HREF="cvs.html#IDX417">HOME</A>
-<LI><A HREF="cvs.html#IDX418">HOMEPATH</A>
-</DIR>
-<H2><A NAME="cindex_i">i</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX276">Id keyword</A>
-<LI><A HREF="cvs.html#IDX284">Ident (shell command)</A>
-<LI><A HREF="cvs.html#IDX271">Identifying files</A>
-<LI><A HREF="cvs.html#IDX402">Ignored files</A>
-<LI><A HREF="cvs.html#IDX401">Ignoring files</A>
-<LI><A HREF="cvs.html#IDX346">Import (subcommand)</A>
-<LI><A HREF="cvs.html#IDX119">Importing files</A>
-<LI><A HREF="cvs.html#IDX120">Importing files, from other version control
systesm</A>
-<LI><A HREF="cvs.html#IDX255">Importing modules</A>
-<LI><A HREF="cvs.html#IDX432">Index</A>
-<LI><A HREF="cvs.html#IDX375">Info files (syntax)</A>
-<LI><A HREF="cvs.html#IDX163">Informing others</A>
-<LI><A HREF="cvs.html#IDX94">init (subcommand)</A>
-<LI><A HREF="cvs.html#IDX13">Introduction to CVS</A>
-<LI><A HREF="cvs.html#IDX295">Invoking CVS</A>
-<LI><A HREF="cvs.html#IDX265">Isolation</A>
-</DIR>
-<H2><A NAME="cindex_j">j</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX230">Join</A>
-</DIR>
-<H2><A NAME="cindex_k">k</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX393">keeping a checked out copy</A>
-<LI><A HREF="cvs.html#IDX113">kerberos</A>
-<LI><A HREF="cvs.html#IDX270">Keyword expansion</A>
-<LI><A HREF="cvs.html#IDX269">Keyword substitution</A>
-<LI><A HREF="cvs.html#IDX287">Kflag</A>
-<LI><A HREF="cvs.html#IDX116">kinit</A>
-<LI><A HREF="cvs.html#IDX8">Known bugs in this manual</A>
-</DIR>
-<H2><A NAME="cindex_l">l</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX58">Layout of repository</A>
-<LI><A HREF="cvs.html#IDX304">Left-hand options</A>
-<LI><A HREF="cvs.html#IDX26">Linear development</A>
-<LI><A HREF="cvs.html#IDX21">List, mailing list</A>
-<LI><A HREF="cvs.html#IDX139">Locally Added</A>
-<LI><A HREF="cvs.html#IDX138">Locally Modified</A>
-<LI><A HREF="cvs.html#IDX140">Locally Removed</A>
-<LI><A HREF="cvs.html#IDX278">Locker keyword</A>
-<LI><A HREF="cvs.html#IDX130">Locking files</A>
-<LI><A HREF="cvs.html#IDX166">locks, cvs</A>
-<LI><A HREF="cvs.html#IDX347">Log (subcommand)</A>
-<LI><A HREF="cvs.html#IDX405">Log information, saving</A>
-<LI><A HREF="cvs.html#IDX279">Log keyword</A>
-<LI><A HREF="cvs.html#IDX338">Log keyword, selecting comment leader</A>
-<LI><A HREF="cvs.html#IDX47">Log message entry</A>
-<LI><A HREF="cvs.html#IDX397">Log message template</A>
-<LI><A HREF="cvs.html#IDX333">Log message, correcting</A>
-<LI><A HREF="cvs.html#IDX392">Log messages</A>
-<LI><A HREF="cvs.html#IDX386">Log messages, editing</A>
-<LI><A HREF="cvs.html#IDX107">Login (subcommand)</A>
-<LI><A HREF="cvs.html#IDX388">loginfo (admin file)</A>
-<LI><A HREF="cvs.html#IDX429">LOGNAME</A>
-</DIR>
-<H2><A NAME="cindex_m">m</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX165">Mail, automatic mail on commit</A>
-<LI><A HREF="cvs.html#IDX20">Mailing list</A>
-<LI><A HREF="cvs.html#IDX390">Mailing log messages</A>
-<LI><A HREF="cvs.html#IDX29">Main trunk (intro)</A>
-<LI><A HREF="cvs.html#IDX195">Main trunk and branches</A>
-<LI><A HREF="cvs.html#IDX87">Many repositories</A>
-<LI><A HREF="cvs.html#IDX155">Markers, conflict</A>
-<LI><A HREF="cvs.html#IDX151">Merge, an example</A>
-<LI><A HREF="cvs.html#IDX233">Merge, branch example</A>
-<LI><A HREF="cvs.html#IDX223">Merging</A>
-<LI><A HREF="cvs.html#IDX228">Merging a branch</A>
-<LI><A HREF="cvs.html#IDX148">Merging a file</A>
-<LI><A HREF="cvs.html#IDX234">Merging two revisions</A>
-<LI><A HREF="cvs.html#IDX227">Modifications, copying between branches</A>
-<LI><A HREF="cvs.html#IDX368">Module status</A>
-<LI><A HREF="cvs.html#IDX125">Module, defining</A>
-<LI><A HREF="cvs.html#IDX362">Modules (admin file)</A>
-<LI><A HREF="cvs.html#IDX23">Modules (intro)</A>
-<LI><A HREF="cvs.html#IDX80">Modules file</A>
-<LI><A HREF="cvs.html#IDX126">Modules file, changing</A>
-<LI><A HREF="cvs.html#IDX209">Motivation for branches</A>
-<LI><A HREF="cvs.html#IDX260">Moving directories</A>
-<LI><A HREF="cvs.html#IDX257">Moving files</A>
-<LI><A HREF="cvs.html#IDX127">Multiple developers</A>
-<LI><A HREF="cvs.html#IDX85">Multiple repositories</A>
-</DIR>
-<H2><A NAME="cindex_n">n</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX277">Name keyword</A>
-<LI><A HREF="cvs.html#IDX202">Name, symbolic (tag)</A>
-<LI><A HREF="cvs.html#IDX141">Needs Checkout</A>
-<LI><A HREF="cvs.html#IDX143">Needs Merge</A>
-<LI><A HREF="cvs.html#IDX142">Needs Patch</A>
-<LI><A HREF="cvs.html#IDX22">Newsgroups</A>
-<LI><A HREF="cvs.html#IDX179">notify (admin file)</A>
-<LI><A HREF="cvs.html#IDX339">Nroff (selecting comment leader)</A>
-<LI><A HREF="cvs.html#IDX31">Number, branch</A>
-<LI><A HREF="cvs.html#IDX27">Number, revision-</A>
-</DIR>
-<H2><A NAME="cindex_o">o</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX301">option defaults</A>
-<LI><A HREF="cvs.html#IDX302">Options, global</A>
-<LI><A HREF="cvs.html#IDX335">Outdating revisions</A>
-<LI><A HREF="cvs.html#IDX150">Overlap</A>
-<LI><A HREF="cvs.html#IDX317">Overriding CVSREAD</A>
-<LI><A HREF="cvs.html#IDX310">Overriding CVSROOT</A>
-<LI><A HREF="cvs.html#IDX312">Overriding EDITOR</A>
-<LI><A HREF="cvs.html#IDX306">Overriding RCSBIN</A>
-<LI><A HREF="cvs.html#IDX308">Overriding TMPDIR</A>
-</DIR>
-<H2><A NAME="cindex_p">p</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX88">Parallel repositories</A>
-<LI><A HREF="cvs.html#IDX106">passwd (admin file)</A>
-<LI><A HREF="cvs.html#IDX108">password client, using</A>
-<LI><A HREF="cvs.html#IDX103">password server, setting up</A>
-<LI><A HREF="cvs.html#IDX415">PATH</A>
-<LI><A HREF="cvs.html#IDX385">Per-module editor</A>
-<LI><A HREF="cvs.html#IDX292">Policy</A>
-<LI><A HREF="cvs.html#IDX380">Precommit checking</A>
-<LI><A HREF="cvs.html#IDX1">Preface</A>
-<LI><A HREF="cvs.html#IDX102">Pserver (subcommand)</A>
-</DIR>
-<H2><A NAME="cindex_r">r</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX70">RCS history files</A>
-<LI><A HREF="cvs.html#IDX272">RCS keywords</A>
-<LI><A HREF="cvs.html#IDX198">RCS revision numbers</A>
-<LI><A HREF="cvs.html#IDX121">RCS, importing files from</A>
-<LI><A HREF="cvs.html#IDX134">RCS-style locking</A>
-<LI><A HREF="cvs.html#IDX416">RCSBIN</A>
-<LI><A HREF="cvs.html#IDX305">RCSBIN, overriding</A>
-<LI><A HREF="cvs.html#IDX280">RCSfile keyword</A>
-<LI><A HREF="cvs.html#IDX395">rcsinfo (admin file)</A>
-<LI><A HREF="cvs.html#IDX431">RCSINIT</A>
-<LI><A HREF="cvs.html#IDX350">Rdiff (subcommand)</A>
-<LI><A HREF="cvs.html#IDX314">read-only files, and -r</A>
-<LI><A HREF="cvs.html#IDX411">read-only files, and CVSREAD</A>
-<LI><A HREF="cvs.html#IDX172">read-only files, and watches</A>
-<LI><A HREF="cvs.html#IDX74">read-only files, in repository</A>
-<LI><A HREF="cvs.html#IDX313">Read-only mode</A>
-<LI><A HREF="cvs.html#IDX239">Recursive (directory descending)</A>
-<LI><A HREF="cvs.html#IDX360">Reference manual (files)</A>
-<LI><A HREF="cvs.html#IDX407">Reference manual for variables</A>
-<LI><A HREF="cvs.html#IDX294">Reference, commands</A>
-<LI><A HREF="cvs.html#IDX351">Release (subcommand)</A>
-<LI><A HREF="cvs.html#IDX34">Releases, revisions and versions</A>
-<LI><A HREF="cvs.html#IDX53">Releasing your working copy</A>
-<LI><A HREF="cvs.html#IDX96">Remote repositories</A>
-<LI><A HREF="cvs.html#IDX248">Remove (subcommand)</A>
-<LI><A HREF="cvs.html#IDX238">Removing a change</A>
-<LI><A HREF="cvs.html#IDX246">Removing files</A>
-<LI><A HREF="cvs.html#IDX52">Removing your working copy</A>
-<LI><A HREF="cvs.html#IDX261">Renaming directories</A>
-<LI><A HREF="cvs.html#IDX258">Renaming files</A>
-<LI><A HREF="cvs.html#IDX330">Replacing a log message</A>
-<LI><A HREF="cvs.html#IDX9">Reporting bugs (manual)</A>
-<LI><A HREF="cvs.html#IDX86">Repositories, multiple</A>
-<LI><A HREF="cvs.html#IDX95">Repositories, remote</A>
-<LI><A HREF="cvs.html#IDX56">Repository (intro)</A>
-<LI><A HREF="cvs.html#IDX57">Repository, example</A>
-<LI><A HREF="cvs.html#IDX68">Repository, how data is stored</A>
-<LI><A HREF="cvs.html#IDX91">Repository, setting up</A>
-<LI><A HREF="cvs.html#IDX132">reserved checkouts</A>
-<LI><A HREF="cvs.html#IDX217">Resetting sticky tags</A>
-<LI><A HREF="cvs.html#IDX160">Resolving a conflict</A>
-<LI><A HREF="cvs.html#IDX221">Restoring old version of removed file</A>
-<LI><A HREF="cvs.html#IDX222">Resurrecting old version of dead file</A>
-<LI><A HREF="cvs.html#IDX205">Retrieving an old revision using tags</A>
-<LI><A HREF="cvs.html#IDX186">reverting to repository version</A>
-<LI><A HREF="cvs.html#IDX281">Revision keyword</A>
-<LI><A HREF="cvs.html#IDX289">Revision management</A>
-<LI><A HREF="cvs.html#IDX24">Revision numbers</A>
-<LI><A HREF="cvs.html#IDX25">Revision tree</A>
-<LI><A HREF="cvs.html#IDX196">Revision tree, making branches</A>
-<LI><A HREF="cvs.html#IDX235">Revisions, merging differences between</A>
-<LI><A HREF="cvs.html#IDX32">Revisions, versions and releases</A>
-<LI><A HREF="cvs.html#IDX319">Right-hand options</A>
-<LI><A HREF="cvs.html#IDX98">rsh</A>
-<LI><A HREF="cvs.html#IDX352">Rtag (subcommand)</A>
-<LI><A HREF="cvs.html#IDX212">rtag, creating a branch using</A>
-</DIR>
-<H2><A NAME="cindex_s">s</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX336">Saving space</A>
-<LI><A HREF="cvs.html#IDX122">SCCS, importing files from</A>
-<LI><A HREF="cvs.html#IDX71">Security</A>
-<LI><A HREF="cvs.html#IDX78">setgid</A>
-<LI><A HREF="cvs.html#IDX93">Setting up a repository</A>
-<LI><A HREF="cvs.html#IDX77">setuid</A>
-<LI><A HREF="cvs.html#IDX3">Signum Support</A>
-<LI><A HREF="cvs.html#IDX282">Source keyword</A>
-<LI><A HREF="cvs.html#IDX19">Source, getting CVS source</A>
-<LI><A HREF="cvs.html#IDX44">Source, getting from CVS</A>
-<LI><A HREF="cvs.html#IDX322">Specifying dates</A>
-<LI><A HREF="cvs.html#IDX164">Spreading information</A>
-<LI><A HREF="cvs.html#IDX117">Starting a project with CVS</A>
-<LI><A HREF="cvs.html#IDX283">State keyword</A>
-<LI><A HREF="cvs.html#IDX353">Status (subcommand)</A>
-<LI><A HREF="cvs.html#IDX136">Status of a file</A>
-<LI><A HREF="cvs.html#IDX367">Status of a module</A>
-<LI><A HREF="cvs.html#IDX220">sticky date</A>
-<LI><A HREF="cvs.html#IDX214">Sticky tags</A>
-<LI><A HREF="cvs.html#IDX218">Sticky tags, resetting</A>
-<LI><A HREF="cvs.html#IDX389">Storing log messages</A>
-<LI><A HREF="cvs.html#IDX296">Structure</A>
-<LI><A HREF="cvs.html#IDX242">Subdirectories</A>
-<LI><A HREF="cvs.html#IDX4">Support, getting CVS support</A>
-<LI><A HREF="cvs.html#IDX201">Symbolic name (tag)</A>
-<LI><A HREF="cvs.html#IDX376">Syntax of info files</A>
-</DIR>
-<H2><A NAME="cindex_t">t</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX354">Tag (subcommand)</A>
-<LI><A HREF="cvs.html#IDX369">Tag program</A>
-<LI><A HREF="cvs.html#IDX199">tag, command, introduction</A>
-<LI><A HREF="cvs.html#IDX204">tag, example</A>
-<LI><A HREF="cvs.html#IDX206">Tag, retrieving old revisions</A>
-<LI><A HREF="cvs.html#IDX200">Tag, symbolic name</A>
-<LI><A HREF="cvs.html#IDX266">taginfo</A>
-<LI><A HREF="cvs.html#IDX197">Tags</A>
-<LI><A HREF="cvs.html#IDX215">Tags, sticky</A>
-<LI><A HREF="cvs.html#IDX39">tc, Trivial Compiler (example)</A>
-<LI><A HREF="cvs.html#IDX128">Team of developers</A>
-<LI><A HREF="cvs.html#IDX427">TEMP</A>
-<LI><A HREF="cvs.html#IDX398">Template for log message</A>
-<LI><A HREF="cvs.html#IDX428">temporary files, location of</A>
-<LI><A HREF="cvs.html#IDX250">Third-party sources</A>
-<LI><A HREF="cvs.html#IDX321">Time</A>
-<LI><A HREF="cvs.html#IDX323">timezone, in input</A>
-<LI><A HREF="cvs.html#IDX348">timezone, in output</A>
-<LI><A HREF="cvs.html#IDX426">TMP</A>
-<LI><A HREF="cvs.html#IDX425">TMPDIR</A>
-<LI><A HREF="cvs.html#IDX307">TMPDIR, overriding</A>
-<LI><A HREF="cvs.html#IDX315">Trace</A>
-<LI><A HREF="cvs.html#IDX264">Traceability</A>
-<LI><A HREF="cvs.html#IDX251">Tracking sources</A>
-<LI><A HREF="cvs.html#IDX168">Transactions, atomic, lack of</A>
-<LI><A HREF="cvs.html#IDX40">Trivial Compiler (example)</A>
-<LI><A HREF="cvs.html#IDX59">Typical repository</A>
-</DIR>
-<H2><A NAME="cindex_u">u</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX76">umask, for repository files</A>
-<LI><A HREF="cvs.html#IDX237">Undoing a change</A>
-<LI><A HREF="cvs.html#IDX184">unedit (subcommand)</A>
-<LI><A HREF="cvs.html#IDX145">Unknown</A>
-<LI><A HREF="cvs.html#IDX133">unreserved checkouts</A>
-<LI><A HREF="cvs.html#IDX144">Unresolved Conflict</A>
-<LI><A HREF="cvs.html#IDX137">Up-to-date</A>
-<LI><A HREF="cvs.html#IDX355">Update (subcommand)</A>
-<LI><A HREF="cvs.html#IDX370">Update program</A>
-<LI><A HREF="cvs.html#IDX149">update, introduction</A>
-<LI><A HREF="cvs.html#IDX147">Updating a file</A>
-<LI><A HREF="cvs.html#IDX430">USER</A>
-<LI><A HREF="cvs.html#IDX180">users (admin file)</A>
-</DIR>
-<H2><A NAME="cindex_v">v</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX252">Vendor</A>
-<LI><A HREF="cvs.html#IDX253">Vendor branch</A>
-<LI><A HREF="cvs.html#IDX33">Versions, revisions and releases</A>
-<LI><A HREF="cvs.html#IDX54">Viewing differences</A>
-</DIR>
-<H2><A NAME="cindex_w">w</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX175">watch add (subcommand)</A>
-<LI><A HREF="cvs.html#IDX173">watch off (subcommand)</A>
-<LI><A HREF="cvs.html#IDX170">watch on (subcommand)</A>
-<LI><A HREF="cvs.html#IDX177">watch remove (subcommand)</A>
-<LI><A HREF="cvs.html#IDX188">watchers (subcommand)</A>
-<LI><A HREF="cvs.html#IDX169">Watches</A>
-<LI><A HREF="cvs.html#IDX256">Wdiff (import example)</A>
-<LI><A HREF="cvs.html#IDX285">What (shell command)</A>
-<LI><A HREF="cvs.html#IDX208">What branches are good for</A>
-<LI><A HREF="cvs.html#IDX12">What is CVS?</A>
-<LI><A HREF="cvs.html#IDX290">When to commit</A>
-<LI><A HREF="cvs.html#IDX38">Work-session, example of</A>
-<LI><A HREF="cvs.html#IDX131">Working copy</A>
-<LI><A HREF="cvs.html#IDX51">Working copy, removing</A>
-<LI><A HREF="cvs.html#IDX373">Wrappers</A>
-</DIR>
-<H2><A NAME="cindex_z">z</A></H2>
-<DIR>
-<LI><A HREF="cvs.html#IDX324">zone, time, in input</A>
-<LI><A HREF="cvs.html#IDX349">zone, time, in output</A>
-</DIR>
-
-</P>
-
-<P><HR><P>
-This document was generated on 7 November 1998 using the
-<A HREF="http://wwwinfo.cern.ch/dis/texi2html/";>texi2html</A>
-translator version 1.52.</P>
-</BODY>
-</HTML>
Index: manual/html_node/cvs_1.html
===================================================================
RCS file: manual/html_node/cvs_1.html
diff -N manual/html_node/cvs_1.html
--- manual/html_node/cvs_1.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,137 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Preface</TITLE>
-</HEAD>
-<BODY>
-Go to the first, previous, <A HREF="cvs_2.html">next</A>, <A
HREF="cvs_148.html">last</A> section, <A HREF="cvs_toc.html">table of
contents</A>.
-<P><HR><P>
-
-<P>
-Version Management
-<P>
-with
-<P>
-CVS
-<P>
-for CVS 1.9
-<P>
-Per Cederqvist et al
-
-</P>
-<P>
-Copyright (C) 1992, 1993 Signum Support AB
-
-</P>
-<P>
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
-
-</P>
-<P>
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided also that the
-section entitled "GNU General Public License" is included exactly as
-in the original, and provided that the entire resulting derived work is
-distributed under the terms of a permission notice identical to this one.
-
-</P>
-<P>
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions,
-except that the section entitled "GNU General Public License" and
-this permission notice may be included in translations approved by the
-Free Software Foundation instead of in the original English.
-
-</P>
-
-
-
-<H1><A NAME="SEC1" HREF="cvs_toc.html#TOC1">About this manual</A></H1>
-<P>
-<A NAME="IDX1"></A>
-<A NAME="IDX2"></A>
-
-</P>
-<P>
-Up to this point, one of the weakest parts of CVS
-has been the documentation. CVS is a complex
-program. Previous versions of the manual were written
-in the manual page format, which is not really well
-suited for such a complex program.
-
-</P>
-<P>
-When writing this manual, I had several goals in mind:
-
-</P>
-
-<UL>
-<LI>
-
-No knowledge of RCS should be necessary.
-
-<LI>
-
-No previous knowledge of revision control software
-should be necessary. All terms, such as <EM>revision
-numbers</EM>, <EM>revision trees</EM> and <EM>merging</EM> are
-explained as they are introduced.
-
-<LI>
-
-The manual should concentrate on the things CVS users
-want to do, instead of what the CVS commands can do.
-The first part of this manual leads you through things
-you might want to do while doing development, and
-introduces the relevant CVS commands as they are
-needed.
-
-<LI>
-
-Information should be easy to find. In the reference
-manual in the appendices almost all information about
-every CVS command is gathered together. There is also
-an extensive index, and a lot of cross references.
-</UL>
-
-<P>
-<A NAME="IDX3"></A>
-<A NAME="IDX4"></A>
-This manual was contributed by Signum Support AB in
-Sweden. Signum is yet another in the growing list of
-companies that support free software. You are free to
-copy both this manual and the CVS program.
-See section <A HREF="cvs_147.html#SEC154">GNU GENERAL PUBLIC LICENSE</A>, for
the details. Signum Support offers
-support contracts and binary distribution for many
-programs, such as CVS, GNU Emacs, the
-GNU C compiler and others. Write to us for
-more information.
-
-</P>
-
-<PRE>
-Signum Support AB
-Box 2044
-S-580 02 Linkoping
-Sweden
-
-Email: address@hidden
-Phone: +46 (0)13 - 21 46 00
-Fax: +46 (0)13 - 21 47 00
-</PRE>
-
-<P>
-Another company selling support for CVS is Cyclic
-Software, web: <CODE>http://www.cyclic.com/</CODE>, email:
-<CODE>address@hidden</CODE>.
-
-</P>
-
-<P><HR><P>
-Go to the first, previous, <A HREF="cvs_2.html">next</A>, <A
HREF="cvs_148.html">last</A> section, <A HREF="cvs_toc.html">table of
contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_10.html
===================================================================
RCS file: manual/html_node/cvs_10.html
diff -N manual/html_node/cvs_10.html
--- manual/html_node/cvs_10.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,60 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Getting the source</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_9.html">previous</A>,
<A HREF="cvs_11.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC11" HREF="cvs_toc.html#TOC11">Getting the source</A></H2>
-<P>
-<A NAME="IDX41"></A>
-<A NAME="IDX42"></A>
-<A NAME="IDX43"></A>
-<A NAME="IDX44"></A>
-<A NAME="IDX45"></A>
-
-</P>
-<P>
-The first thing you must do is to get your own working copy of the
-source for <SAMP>`tc'</SAMP>. For this, you use the <CODE>checkout</CODE>
command:
-
-</P>
-
-<PRE>
-$ cvs checkout tc
-</PRE>
-
-<P>
-This will create a new directory called <TT>`tc'</TT> and populate it with
-the source files.
-
-</P>
-
-<PRE>
-$ cd tc
-$ ls
-CVS Makefile backend.c driver.c frontend.c parser.c
-</PRE>
-
-<P>
-The <TT>`CVS'</TT> directory is used internally by
-CVS. Normally, you should not modify or remove
-any of the files in it.
-
-</P>
-<P>
-You start your favorite editor, hack away at <TT>`backend.c'</TT>, and a couple
-of hours later you have added an optimization pass to the compiler.
-A note to RCS and SCCS users: There is no need to lock the files that
-you want to edit. See section <A HREF="cvs_35.html#SEC37">Multiple
developers</A> for an explanation.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_9.html">previous</A>,
<A HREF="cvs_11.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_100.html
===================================================================
RCS file: manual/html_node/cvs_100.html
diff -N manual/html_node/cvs_100.html
--- manual/html_node/cvs_100.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,64 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - diff examples</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_99.html">previous</A>,
<A HREF="cvs_101.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC107" HREF="cvs_toc.html#TOC107">diff examples</A></H3>
-
-<P>
-The following line produces a Unidiff (<SAMP>`-u'</SAMP> flag)
-between revision 1.14 and 1.19 of
-<TT>`backend.c'</TT>. Due to the <SAMP>`-kk'</SAMP> flag no
-keywords are substituted, so differences that only depend
-on keyword substitution are ignored.
-
-</P>
-
-<PRE>
-$ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
-</PRE>
-
-<P>
-Suppose the experimental branch EXPR1 was based on a
-set of files tagged RELEASE_1_0. To see what has
-happened on that branch, the following can be used:
-
-</P>
-
-<PRE>
-$ cvs diff -r RELEASE_1_0 -r EXPR1
-</PRE>
-
-<P>
-A command like this can be used to produce a context
-diff between two releases:
-
-</P>
-
-<PRE>
-$ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
-</PRE>
-
-<P>
-If you are maintaining ChangeLogs, a command like the following
-just before you commit your changes may help you write
-the ChangeLog entry. All local modifications that have
-not yet been committed will be printed.
-
-</P>
-
-<PRE>
-$ cvs diff -u | less
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_99.html">previous</A>,
<A HREF="cvs_101.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_101.html
===================================================================
RCS file: manual/html_node/cvs_101.html
diff -N manual/html_node/cvs_101.html
--- manual/html_node/cvs_101.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,59 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - export</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_100.html">previous</A>,
<A HREF="cvs_102.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC108" HREF="cvs_toc.html#TOC108">export--Export sources from
CVS, similar to checkout</A></H2>
-<P>
-<A NAME="IDX344"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: export [-flNn] [-r rev|-D date] [-k subst] [-d dir] module...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: current directory.
-</UL>
-
-<P>
-This command is a variant of <CODE>checkout</CODE>; use it
-when you want a copy of the source for module without
-the CVS administrative directories. For example, you
-might use <CODE>export</CODE> to prepare source for shipment
-off-site. This command requires that you specify a
-date or tag (with <SAMP>`-D'</SAMP> or <SAMP>`-r'</SAMP>), so that you
-can count on reproducing the source you ship to others.
-
-</P>
-<P>
-One often would like to use <SAMP>`-kv'</SAMP> with <CODE>cvs
-export</CODE>. This causes any RCS keywords to be
-expanded such that an import done at some other site
-will not lose the keyword revision information. But be
-aware that doesn't handle an export containing binary
-files correctly. Also be aware that after having used
-<SAMP>`-kv'</SAMP>, one can no longer use the <CODE>ident</CODE>
-command (which is part of the RCS suite--see
-ident(1)) which looks for RCS keyword strings. If
-you want to be able to use <CODE>ident</CODE> you must not
-use <SAMP>`-kv'</SAMP>.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_100.html">previous</A>,
<A HREF="cvs_102.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_102.html
===================================================================
RCS file: manual/html_node/cvs_102.html
diff -N manual/html_node/cvs_102.html
--- manual/html_node/cvs_102.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,79 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - export options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_101.html">previous</A>,
<A HREF="cvs_103.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC109" HREF="cvs_toc.html#TOC109">export options</A></H3>
-
-<P>
-These standard options are supported by <CODE>export</CODE>
-(see section <A HREF="cvs_88.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-If no matching revision is found, retrieve the most
-recent revision (instead of ignoring the file).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any checkout program.
-
-<DT><CODE>-R</CODE>
-<DD>
-Export directories recursively. This is on by default.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use revision <VAR>tag</VAR>.
-</DL>
-
-<P>
-In addition, these options (that are common to
-<CODE>checkout</CODE> and <CODE>export</CODE>) are also supported:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-d <VAR>dir</VAR></CODE>
-<DD>
-Create a directory called <VAR>dir</VAR> for the working
-files, instead of using the module name. Unless you
-also use <SAMP>`-N'</SAMP>, the paths created under <VAR>dir</VAR>
-will be as short as possible.
-
-<DT><CODE>-k <VAR>subst</VAR></CODE>
-<DD>
-Set keyword expansion mode (see section <A
HREF="cvs_79.html#SEC81">Substitution modes</A>).
-
-<DT><CODE>-N</CODE>
-<DD>
-Only useful together with <SAMP>`-d <VAR>dir</VAR>'</SAMP>. With this
-option, CVS will not shorten module paths in your
-working directory. (Normally, CVS shortens paths as
-much as possible when you specify an explicit target
-directory.)
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_101.html">previous</A>,
<A HREF="cvs_103.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_103.html
===================================================================
RCS file: manual/html_node/cvs_103.html
diff -N manual/html_node/cvs_103.html
--- manual/html_node/cvs_103.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,54 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - history</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_102.html">previous</A>,
<A HREF="cvs_104.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC110" HREF="cvs_toc.html#TOC110">history--Show status of files
and users</A></H2>
-<P>
-<A NAME="IDX345"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: history [-report] [-flags] [-options args] [files...]
-<LI>
-
-Requires: the file <TT>`$CVSROOT/CVSROOT/history'</TT>
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-CVS can keep a history file that tracks each use of the
-<CODE>checkout</CODE>, <CODE>commit</CODE>, <CODE>rtag</CODE>,
-<CODE>update</CODE>, and <CODE>release</CODE> commands. You can
-use <CODE>history</CODE> to display this information in
-various formats.
-
-</P>
-<P>
-Logging must be enabled by creating the file
-<TT>`$CVSROOT/CVSROOT/history'</TT>.
-
-</P>
-<P>
-<STRONG>Warning:</STRONG> <CODE>history</CODE> uses <SAMP>`-f'</SAMP>,
<SAMP>`-l'</SAMP>,
-<SAMP>`-n'</SAMP>, and <SAMP>`-p'</SAMP> in ways that conflict with the
-normal use inside CVS (see section <A HREF="cvs_88.html#SEC90">Common command
options</A>).
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_102.html">previous</A>,
<A HREF="cvs_104.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_104.html
===================================================================
RCS file: manual/html_node/cvs_104.html
diff -N manual/html_node/cvs_104.html
--- manual/html_node/cvs_104.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,172 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - history options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_103.html">previous</A>,
<A HREF="cvs_105.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC111" HREF="cvs_toc.html#TOC111">history options</A></H3>
-
-<P>
-Several options (shown above as <SAMP>`-report'</SAMP>) control what
-kind of report is generated:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-c</CODE>
-<DD>
-Report on each time commit was used (i.e., each time
-the repository was modified).
-
-<DT><CODE>-e</CODE>
-<DD>
-Everything (all record types); equivalent to specifying
-<SAMP>`-xMACFROGWUT'</SAMP>.
-
-<DT><CODE>-m <VAR>module</VAR></CODE>
-<DD>
-Report on a particular module. (You can meaningfully
-use <SAMP>`-m'</SAMP> more than once on the command line.)
-
-<DT><CODE>-o</CODE>
-<DD>
-Report on checked-out modules.
-
-<DT><CODE>-T</CODE>
-<DD>
-Report on all tags.
-
-<DT><CODE>-x <VAR>type</VAR></CODE>
-<DD>
-Extract a particular set of record types <VAR>type</VAR> from the CVS
-history. The types are indicated by single letters,
-which you may specify in combination.
-
-Certain commands have a single record type:
-
-<DL COMPACT>
-
-<DT><CODE>F</CODE>
-<DD>
-release
-<DT><CODE>O</CODE>
-<DD>
-checkout
-<DT><CODE>T</CODE>
-<DD>
-rtag
-</DL>
-
-One of four record types may result from an update:
-
-<DL COMPACT>
-
-<DT><CODE>C</CODE>
-<DD>
-A merge was necessary but collisions were
-detected (requiring manual merging).
-<DT><CODE>G</CODE>
-<DD>
-A merge was necessary and it succeeded.
-<DT><CODE>U</CODE>
-<DD>
-A working file was copied from the repository.
-<DT><CODE>W</CODE>
-<DD>
-The working copy of a file was deleted during
-update (because it was gone from the repository).
-</DL>
-
-One of three record types results from commit:
-
-<DL COMPACT>
-
-<DT><CODE>A</CODE>
-<DD>
-A file was added for the first time.
-<DT><CODE>M</CODE>
-<DD>
-A file was modified.
-<DT><CODE>R</CODE>
-<DD>
-A file was removed.
-</DL>
-</DL>
-
-<P>
-The options shown as <SAMP>`-flags'</SAMP> constrain or expand
-the report without requiring option arguments:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-a</CODE>
-<DD>
-Show data for all users (the default is to show data
-only for the user executing <CODE>history</CODE>).
-
-<DT><CODE>-l</CODE>
-<DD>
-Show last modification only.
-
-<DT><CODE>-w</CODE>
-<DD>
-Show only the records for modifications done from the
-same working directory where <CODE>history</CODE> is
-executing.
-</DL>
-
-<P>
-The options shown as <SAMP>`-options <VAR>args</VAR>'</SAMP> constrain the
report
-based on an argument:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b <VAR>str</VAR></CODE>
-<DD>
-Show data back to a record containing the string
-<VAR>str</VAR> in either the module name, the file name, or
-the repository path.
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Show data since <VAR>date</VAR>. This is slightly different
-from the normal use of <SAMP>`-D <VAR>date</VAR>'</SAMP>, which
-selects the newest revision older than <VAR>date</VAR>.
-
-<DT><CODE>-p <VAR>repository</VAR></CODE>
-<DD>
-Show data for a particular source repository (you
-can specify several <SAMP>`-p'</SAMP> options on the same command
-line).
-
-<DT><CODE>-r <VAR>rev</VAR></CODE>
-<DD>
-Show records referring to revisions since the revision
-or tag named <VAR>rev</VAR> appears in individual RCS
-files. Each RCS file is searched for the revision or
-tag.
-
-<DT><CODE>-t <VAR>tag</VAR></CODE>
-<DD>
-Show records since tag <VAR>tag</VAR> was last added to the the
-history file. This differs from the <SAMP>`-r'</SAMP> flag
-above in that it reads only the history file, not the
-RCS files, and is much faster.
-
-<DT><CODE>-u <VAR>name</VAR></CODE>
-<DD>
-Show records for user <VAR>name</VAR>.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_103.html">previous</A>,
<A HREF="cvs_105.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_105.html
===================================================================
RCS file: manual/html_node/cvs_105.html
diff -N manual/html_node/cvs_105.html
--- manual/html_node/cvs_105.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,94 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - import</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_104.html">previous</A>,
<A HREF="cvs_106.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC112" HREF="cvs_toc.html#TOC112">import--Import sources into
CVS, using vendor branches</A></H2>
-<P>
-<A NAME="IDX346"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: import [-options] repository vendortag releasetag...
-<LI>
-
-Requires: Repository, source distribution directory.
-<LI>
-
-Changes: repository.
-</UL>
-
-<P>
-Use <CODE>import</CODE> to incorporate an entire source
-distribution from an outside source (e.g., a source
-vendor) into your source repository directory. You can
-use this command both for initial creation of a
-repository, and for wholesale updates to the module
-from the outside source. See section <A HREF="cvs_61.html#SEC63">Tracking
third-party sources</A>, for
-a discussion on this subject.
-
-</P>
-<P>
-The <VAR>repository</VAR> argument gives a directory name
-(or a path to a directory) under the CVS root directory
-for repositories; if the directory did not exist,
-import creates it.
-
-</P>
-<P>
-When you use import for updates to source that has been
-modified in your source repository (since a prior
-import), it will notify you of any files that conflict
-in the two branches of development; use <SAMP>`checkout
--j'</SAMP> to reconcile the differences, as import instructs
-you to do.
-
-</P>
-<P>
-If CVS decides a file should be ignored
-(see section <A HREF="cvs_141.html#SEC148">Ignoring files via cvsignore</A>),
it does not import it and prints
-<SAMP>`I '</SAMP> followed by the filename (see section <A
HREF="cvs_107.html#SEC114">import output</A>, for a
-complete description of the output).
-
-</P>
-<P>
-If the file <TT>`$CVSROOT/CVSROOT/cvswrappers'</TT> exists,
-any file whose names match the specifications in that
-file will be treated as packages and the appropriate
-filtering will be performed on the file/directory
-before being imported, See section <A HREF="cvs_131.html#SEC138">The
cvswrappers file</A>.
-
-</P>
-<P>
-The outside source is saved in a first-level RCS
-branch, by default 1.1.1. Updates are leaves of this
-branch; for example, files from the first imported
-collection of source will be revision 1.1.1.1, then
-files from the first imported update will be revision
-1.1.1.2, and so on.
-
-</P>
-<P>
-At least three arguments are required.
-<VAR>repository</VAR> is needed to identify the collection
-of source. <VAR>vendortag</VAR> is a tag for the entire
-branch (e.g., for 1.1.1). You must also specify at
-least one <VAR>releasetag</VAR> to identify the files at
-the leaves created each time you execute <CODE>import</CODE>.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_104.html">previous</A>,
<A HREF="cvs_106.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_106.html
===================================================================
RCS file: manual/html_node/cvs_106.html
diff -N manual/html_node/cvs_106.html
--- manual/html_node/cvs_106.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,76 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - import options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_105.html">previous</A>,
<A HREF="cvs_107.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC113" HREF="cvs_toc.html#TOC113">import options</A></H3>
-
-<P>
-This standard option is supported by <CODE>import</CODE>
-(see section <A HREF="cvs_88.html#SEC90">Common command options</A>, for a
complete description):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-m <VAR>message</VAR></CODE>
-<DD>
-Use <VAR>message</VAR> as log information, instead of
-invoking an editor.
-</DL>
-
-<P>
-There are three additional special options.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b <VAR>branch</VAR></CODE>
-<DD>
-Specify a first-level branch other than 1.1.1. Unless
-the <SAMP>`-b <VAR>branch</VAR>'</SAMP> flag is given, revisions will
-<EM>always</EM> be made to the branch 1.1.1--even if a
-<VAR>vendortag</VAR> that matches another branch is given!
-What happens in that case, is that the tag will be
-reset to 1.1.1. Warning: This behavior might change
-in the future.
-
-<DT><CODE>-k <VAR>subst</VAR></CODE>
-<DD>
-Indicate the RCS keyword expansion mode desired. This
-setting will apply to all files created during the
-import, but not to any files that previously existed in
-the repository. See section <A HREF="cvs_79.html#SEC81">Substitution
modes</A> for a
-list of valid <SAMP>`-k'</SAMP> settings.
-
-<DT><CODE>-I <VAR>name</VAR></CODE>
-<DD>
-Specify file names that should be ignored during
-import. You can use this option repeatedly. To avoid
-ignoring any files at all (even those ignored by
-default), specify `-I !'.
-
-<VAR>name</VAR> can be a file name pattern of the same type
-that you can specify in the <TT>`.cvsignore'</TT> file.
-See section <A HREF="cvs_141.html#SEC148">Ignoring files via cvsignore</A>.
-
-<DT><CODE>-W <VAR>spec</VAR></CODE>
-<DD>
-Specify file names that should be filtered during
-import. You can use this option repeatedly.
-
-<VAR>spec</VAR> can be a file name pattern of the same type
-that you can specify in the <TT>`.cvswrappers'</TT>
-file. See section <A HREF="cvs_131.html#SEC138">The cvswrappers file</A>.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_105.html">previous</A>,
<A HREF="cvs_107.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_107.html
===================================================================
RCS file: manual/html_node/cvs_107.html
diff -N manual/html_node/cvs_107.html
--- manual/html_node/cvs_107.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,52 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - import output</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_106.html">previous</A>,
<A HREF="cvs_108.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC114" HREF="cvs_toc.html#TOC114">import output</A></H3>
-
-<P>
-<CODE>import</CODE> keeps you informed of its progress by printing a line
-for each file, preceded by one character indicating the status of the file:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>U <VAR>file</VAR></CODE>
-<DD>
-The file already exists in the repository and has not been locally
-modified; a new revision has been created (if necessary).
-
-<DT><CODE>N <VAR>file</VAR></CODE>
-<DD>
-The file is a new file which has been added to the repository.
-
-<DT><CODE>C <VAR>file</VAR></CODE>
-<DD>
-The file already exists in the repository but has been locally modified;
-you will have to merge the changes.
-
-<DT><CODE>I <VAR>file</VAR></CODE>
-<DD>
-The file is being ignored (see section <A HREF="cvs_141.html#SEC148">Ignoring
files via cvsignore</A>).
-
-<DT><CODE>L <VAR>file</VAR></CODE>
-<DD>
-The file is a symbolic link; at the moment (and for the forseeable
-future), symbolic links are ignored.
-(Various options in the <TT>`modules'</TT> file can be used
-to recreate symbolic links on checkout, update, etc.;
-see section <A HREF="cvs_130.html#SEC137">The modules file</A>.)
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_106.html">previous</A>,
<A HREF="cvs_108.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_108.html
===================================================================
RCS file: manual/html_node/cvs_108.html
diff -N manual/html_node/cvs_108.html
--- manual/html_node/cvs_108.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,22 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - import examples</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_107.html">previous</A>,
<A HREF="cvs_109.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC115" HREF="cvs_toc.html#TOC115">import examples</A></H3>
-
-<P>
-See section <A HREF="cvs_61.html#SEC63">Tracking third-party sources</A>, and
See section <A HREF="cvs_31.html#SEC33">Creating a directory tree from a number
of files</A>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_107.html">previous</A>,
<A HREF="cvs_109.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_109.html
===================================================================
RCS file: manual/html_node/cvs_109.html
diff -N manual/html_node/cvs_109.html
--- manual/html_node/cvs_109.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,57 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - log</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_108.html">previous</A>,
<A HREF="cvs_110.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC116" HREF="cvs_toc.html#TOC116">log--Print out log information
for files</A></H2>
-<P>
-<A NAME="IDX347"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: log [options] [files...]
-<LI>
-
-Requires: repository, working directory.
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-Display log information for files. <CODE>log</CODE> used to
-call the RCS utility <CODE>rlog</CODE>. Although this
-is no longer true in the current sources, this history
-determines the format of the output and the options,
-which are not quite in the style of the other CVS
-commands.
-
-</P>
-<P>
-<A NAME="IDX348"></A>
-<A NAME="IDX349"></A>
-The output includes the location of the RCS file,
-the <EM>head</EM> revision (the latest revision on the
-trunk), all symbolic names (tags) and some other
-things. For each revision, the revision number, the
-author, the number of lines added/deleted and the log
-message are printed. All times are displayed in
-Coordinated Universal Time (UTC). (Other parts of
-CVS print times in the local timezone).
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_108.html">previous</A>,
<A HREF="cvs_110.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_11.html
===================================================================
RCS file: manual/html_node/cvs_11.html
diff -N manual/html_node/cvs_11.html
--- manual/html_node/cvs_11.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,57 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Committing your changes</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_10.html">previous</A>,
<A HREF="cvs_12.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC12" HREF="cvs_toc.html#TOC12">Committing your changes</A></H2>
-<P>
-<A NAME="IDX46"></A>
-<A NAME="IDX47"></A>
-<A NAME="IDX48"></A>
-<A NAME="IDX49"></A>
-
-</P>
-<P>
-When you have checked that the compiler is still compilable you decide
-to make a new version of <TT>`backend.c'</TT>.
-
-</P>
-
-<PRE>
-$ cvs commit backend.c
-</PRE>
-
-<P>
-CVS starts an editor, to allow you to enter a log
-message. You type in "Added an optimization pass.",
-save the temporary file, and exit the editor.
-
-</P>
-<P>
-The environment variable <CODE>$CVSEDITOR</CODE> determines
-which editor is started. If <CODE>$CVSEDITOR</CODE> is not
-set, then if the environment variable <CODE>$EDITOR</CODE> is
-set, it will be used. If both <CODE>$CVSEDITOR</CODE> and
-<CODE>$EDITOR</CODE> are not set then the editor defaults to
-<CODE>vi</CODE>. If you want to avoid the overhead of
-starting an editor you can specify the log message on
-the command line using the <SAMP>`-m'</SAMP> flag instead, like
-this:
-
-</P>
-
-<PRE>
-$ cvs commit -m "Added an optimization pass" backend.c
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_10.html">previous</A>,
<A HREF="cvs_12.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_110.html
===================================================================
RCS file: manual/html_node/cvs_110.html
diff -N manual/html_node/cvs_110.html
--- manual/html_node/cvs_110.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,165 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - log options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_109.html">previous</A>,
<A HREF="cvs_111.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC117" HREF="cvs_toc.html#TOC117">log options</A></H3>
-
-<P>
-By default, <CODE>log</CODE> prints all information that is
-available. All other options restrict the output.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b</CODE>
-<DD>
-Print information about the revisions on the default
-branch, normally the highest branch on the trunk.
-
-<DT><CODE>-d <VAR>dates</VAR></CODE>
-<DD>
-Print information about revisions with a checkin
-date/time in the range given by the
-semicolon-separated list of dates. The date formats
-accepted are those accepted by the <SAMP>`-D'</SAMP> option to
-many other CVS commands (see section <A HREF="cvs_88.html#SEC90">Common
command options</A>).
-Dates can be combined into ranges as follows:
-
-<DL COMPACT>
-
-<DT><CODE><VAR>d1</VAR><<VAR>d2</VAR></CODE>
-<DD>
-<DT><CODE><VAR>d2</VAR>><VAR>d1</VAR></CODE>
-<DD>
-Select the revisions that were deposited between
-<VAR>d1</VAR> and <VAR>d2</VAR>.
-
-<DT><CODE><<VAR>d</VAR></CODE>
-<DD>
-<DT><CODE><VAR>d</VAR>></CODE>
-<DD>
-Select all revisions dated <VAR>d</VAR> or earlier.
-
-<DT><CODE><VAR>d</VAR><</CODE>
-<DD>
-<DT><CODE>><VAR>d</VAR></CODE>
-<DD>
-Select all revisions dated <VAR>d</VAR> or later.
-
-<DT><CODE><VAR>d</VAR></CODE>
-<DD>
-Select the single, latest revision dated <VAR>d</VAR> or
-earlier.
-</DL>
-
-The <SAMP>`>'</SAMP> or <SAMP>`<'</SAMP> characters may be followed by
-<SAMP>`='</SAMP> to indicate an inclusive range rather than an
-exclusive one.
-
-Note that the separator is a semicolon (;).
-
-<DT><CODE>-h</CODE>
-<DD>
-Print only the RCS pathname, working pathname, head,
-default branch, access list, locks, symbolic names, and
-suffix.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory. (Default
-is to run recursively).
-
-<DT><CODE>-N</CODE>
-<DD>
-Do not print the list of tags for this file. This
-option can be very useful when your site uses a lot of
-tags, so rather than "more"'ing over 3 pages of tag
-information, the log information is presented without
-tags at all.
-
-<DT><CODE>-R</CODE>
-<DD>
-Print only the name of the RCS history file.
-
-<DT><CODE>-r<VAR>revisions</VAR></CODE>
-<DD>
-Print information about revisions given in the
-comma-separated list <VAR>revisions</VAR> of revisions and
-ranges. The following table explains the available
-range formats:
-
-<DL COMPACT>
-
-<DT><CODE><VAR>rev1</VAR>:<VAR>rev2</VAR></CODE>
-<DD>
-Revisions <VAR>rev1</VAR> to <VAR>rev2</VAR> (which must be on
-the same branch).
-
-<DT><CODE>:<VAR>rev</VAR></CODE>
-<DD>
-Revisions from the beginning of the branch up to
-and including <VAR>rev</VAR>.
-
-<DT><CODE><VAR>rev</VAR>:</CODE>
-<DD>
-Revisions starting with <VAR>rev</VAR> to the end of the
-branch containing <VAR>rev</VAR>.
-
-<DT><CODE><VAR>branch</VAR></CODE>
-<DD>
-An argument that is a branch means all revisions on
-that branch.
-
-<DT><CODE><VAR>branch1</VAR>:<VAR>branch2</VAR></CODE>
-<DD>
-A range of branches means all revisions
-on the branches in that range.
-
-<DT><CODE><VAR>branch</VAR>.</CODE>
-<DD>
-The latest revision in <VAR>branch</VAR>.
-</DL>
-
-A bare <SAMP>`-r'</SAMP> with no revisions means the latest
-revision on the default branch, normally the trunk.
-There can be no space between the <SAMP>`-r'</SAMP> option and
-its argument.
-
-<DT><CODE>-s <VAR>states</VAR></CODE>
-<DD>
-Print information about revisions whose state
-attributes match one of the states given in the
-comma-separated list <VAR>states</VAR>.
-
-<DT><CODE>-t</CODE>
-<DD>
-Print the same as <SAMP>`-h'</SAMP>, plus the descriptive text.
-
-<DT><CODE>-w<VAR>logins</VAR></CODE>
-<DD>
-Print information about revisions checked in by users
-with login names appearing in the comma-separated list
-<VAR>logins</VAR>. If <VAR>logins</VAR> is omitted, the user's
-login is assumed. There can be no space between the
-<SAMP>`-w'</SAMP> option and its argument.
-</DL>
-
-<P>
-<CODE>log</CODE> prints the intersection of the revisions
-selected with the options <SAMP>`-d'</SAMP>, <SAMP>`-s'</SAMP>, and
-<SAMP>`-w'</SAMP>, intersected with the union of the revisions
-selected by <SAMP>`-b'</SAMP> and <SAMP>`-r'</SAMP>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_109.html">previous</A>,
<A HREF="cvs_111.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_111.html
===================================================================
RCS file: manual/html_node/cvs_111.html
diff -N manual/html_node/cvs_111.html
--- manual/html_node/cvs_111.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,22 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - log examples</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_110.html">previous</A>,
<A HREF="cvs_112.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC118" HREF="cvs_toc.html#TOC118">log examples</A></H3>
-
-<P>
-Contributed examples are gratefully accepted.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_110.html">previous</A>,
<A HREF="cvs_112.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_112.html
===================================================================
RCS file: manual/html_node/cvs_112.html
diff -N manual/html_node/cvs_112.html
--- manual/html_node/cvs_112.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,65 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - rdiff</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_111.html">previous</A>,
<A HREF="cvs_113.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC119" HREF="cvs_toc.html#TOC119">rdiff---'patch' format diffs
between releases</A></H2>
-<P>
-<A NAME="IDX350"></A>
-
-</P>
-
-<UL>
-<LI>
-
-rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: nothing.
-<LI>
-
-Synonym: patch
-</UL>
-
-<P>
-Builds a Larry Wall format patch(1) file between two
-releases, that can be fed directly into the patch
-program to bring an old release up-to-date with the new
-release. (This is one of the few CVS commands that
-operates directly from the repository, and doesn't
-require a prior checkout.) The diff output is sent to
-the standard output device.
-
-</P>
-<P>
-You can specify (using the standard <SAMP>`-r'</SAMP> and
-<SAMP>`-D'</SAMP> options) any combination of one or two
-revisions or dates. If only one revision or date is
-specified, the patch file reflects differences between
-that revision or date and the current head revisions in
-the RCS file.
-
-</P>
-<P>
-Note that if the software release affected is contained
-in more than one directory, then it may be necessary to
-specify the <SAMP>`-p'</SAMP> option to the patch command when
-patching the old sources, so that patch is able to find
-the files that are located in other directories.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_111.html">previous</A>,
<A HREF="cvs_113.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_113.html
===================================================================
RCS file: manual/html_node/cvs_113.html
diff -N manual/html_node/cvs_113.html
--- manual/html_node/cvs_113.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,85 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - rdiff options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_112.html">previous</A>,
<A HREF="cvs_114.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC120" HREF="cvs_toc.html#TOC120">rdiff options</A></H3>
-
-<P>
-These standard options are supported by <CODE>rdiff</CODE>
-(see section <A HREF="cvs_88.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-If no matching revision is found, retrieve the most
-recent revision (instead of ignoring the file).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; don't descend subdirectories.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use revision <VAR>tag</VAR>.
-</DL>
-
-<P>
-In addition to the above, these options are available:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-c</CODE>
-<DD>
-Use the context diff format. This is the default format.
-
-<DT><CODE>-s</CODE>
-<DD>
-Create a summary change report instead of a patch. The
-summary includes information about files that were
-changed or added between the releases. It is sent to
-the standard output device. This is useful for finding
-out, for example, which files have changed between two
-dates or revisions.
-
-<DT><CODE>-t</CODE>
-<DD>
-A diff of the top two revisions is sent to the standard
-output device. This is most useful for seeing what the
-last change to a file was.
-
-<DT><CODE>-u</CODE>
-<DD>
-Use the unidiff format for the context diffs.
-This option is not available if your diff does not
-support the unidiff format. Remember that old versions
-of the <CODE>patch</CODE> program can't handle the unidiff
-format, so if you plan to post this patch to the net
-you should probably not use <SAMP>`-u'</SAMP>.
-
-<DT><CODE>-V <VAR>vn</VAR></CODE>
-<DD>
-Expand RCS keywords according to the rules current in
-RCS version <VAR>vn</VAR> (the expansion format changed with
-RCS version 5).
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_112.html">previous</A>,
<A HREF="cvs_114.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_114.html
===================================================================
RCS file: manual/html_node/cvs_114.html
diff -N manual/html_node/cvs_114.html
--- manual/html_node/cvs_114.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,48 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - rdiff examples</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_113.html">previous</A>,
<A HREF="cvs_115.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC121" HREF="cvs_toc.html#TOC121">rdiff examples</A></H3>
-
-<P>
-Suppose you receive mail from <TT>address@hidden</TT> asking for an
-update from release 1.2 to 1.4 of the tc compiler. You
-have no such patches on hand, but with CVS that can
-easily be fixed with a command such as this:
-
-</P>
-
-<PRE>
-$ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
-$$ Mail -s 'The patches you asked for' address@hidden
-</PRE>
-
-<P>
-Suppose you have made release 1.3, and forked a branch
-called <SAMP>`R_1_3fix'</SAMP> for bugfixes. <SAMP>`R_1_3_1'</SAMP>
-corresponds to release 1.3.1, which was made some time
-ago. Now, you want to see how much development has been
-done on the branch. This command can be used:
-
-</P>
-
-<PRE>
-$ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name
-cvs rdiff: Diffing module-name
-File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6
-File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4
-File bar.h,v changed from revision 1.29.2.1 to 1.2
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_113.html">previous</A>,
<A HREF="cvs_115.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_115.html
===================================================================
RCS file: manual/html_node/cvs_115.html
diff -N manual/html_node/cvs_115.html
--- manual/html_node/cvs_115.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,62 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - release</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_114.html">previous</A>,
<A HREF="cvs_116.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC122" HREF="cvs_toc.html#TOC122">release--Indicate that a
Module is no longer in use</A></H2>
-<P>
-<A NAME="IDX351"></A>
-
-</P>
-
-<UL>
-<LI>
-
-release [-d] directories...
-<LI>
-
-Requires: Working directory.
-<LI>
-
-Changes: Working directory, history log.
-</UL>
-
-<P>
-This command is meant to safely cancel the effect of
-<SAMP>`cvs checkout'</SAMP>. Since CVS doesn't lock files, it
-isn't strictly necessary to use this command. You can
-always simply delete your working directory, if you
-like; but you risk losing changes you may have
-forgotten, and you leave no trace in the CVS history
-file (see section <A HREF="cvs_142.html#SEC149">The history file</A>) that
you've abandoned your
-checkout.
-
-</P>
-<P>
-Use <SAMP>`cvs release'</SAMP> to avoid these problems. This
-command checks that no uncommitted changes are
-present; that you are executing it from immediately
-above a CVS working directory; and that the repository
-recorded for your files is the same as the repository
-defined in the module database.
-
-</P>
-<P>
-If all these conditions are true, <SAMP>`cvs release'</SAMP>
-leaves a record of its execution (attesting to your
-intentionally abandoning your checkout) in the CVS
-history log.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_114.html">previous</A>,
<A HREF="cvs_116.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_116.html
===================================================================
RCS file: manual/html_node/cvs_116.html
diff -N manual/html_node/cvs_116.html
--- manual/html_node/cvs_116.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,39 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - release options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_115.html">previous</A>,
<A HREF="cvs_117.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC123" HREF="cvs_toc.html#TOC123">release options</A></H3>
-
-<P>
-The <CODE>release</CODE> command supports one command option:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-d</CODE>
-<DD>
-Delete your working copy of the file if the release
-succeeds. If this flag is not given your files will
-remain in your working directory.
-
-<STRONG>Warning:</STRONG> The <CODE>release</CODE> command deletes
-all directories and files recursively. This
-has the very serious side-effect that any directory
-that you have created inside your checked-out sources,
-and not added to the repository (using the <CODE>add</CODE>
-command; see section <A HREF="cvs_59.html#SEC61">Adding files to a
directory</A>) will be silently deleted--even
-if it is non-empty!
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_115.html">previous</A>,
<A HREF="cvs_117.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_117.html
===================================================================
RCS file: manual/html_node/cvs_117.html
diff -N manual/html_node/cvs_117.html
--- manual/html_node/cvs_117.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,74 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - release output</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_116.html">previous</A>,
<A HREF="cvs_118.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC124" HREF="cvs_toc.html#TOC124">release output</A></H3>
-
-<P>
-Before <CODE>release</CODE> releases your sources it will
-print a one-line message for any file that is not
-up-to-date.
-
-</P>
-<P>
-<STRONG>Warning:</STRONG> Any new directories that you have
-created, but not added to the CVS directory hierarchy
-with the <CODE>add</CODE> command (see section <A
HREF="cvs_59.html#SEC61">Adding files to a directory</A>) will be
-silently ignored (and deleted, if <SAMP>`-d'</SAMP> is
-specified), even if they contain files.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>U <VAR>file</VAR></CODE>
-<DD>
-There exists a newer revision of this file in the
-repository, and you have not modified your local copy
-of the file.
-
-<DT><CODE>A <VAR>file</VAR></CODE>
-<DD>
-The file has been added to your private copy of the
-sources, but has not yet been committed to the
-repository. If you delete your copy of the sources
-this file will be lost.
-
-<DT><CODE>R <VAR>file</VAR></CODE>
-<DD>
-The file has been removed from your private copy of the
-sources, but has not yet been removed from the
-repository, since you have not yet committed the
-removal. See section <A HREF="cvs_95.html#SEC99">commit--Check files into the
repository</A>.
-
-<DT><CODE>M <VAR>file</VAR></CODE>
-<DD>
-The file is modified in your working directory. There
-might also be a newer revision inside the repository.
-
-<DT><CODE>? <VAR>file</VAR></CODE>
-<DD>
-<VAR>file</VAR> is in your working directory, but does not
-correspond to anything in the source repository, and is
-not in the list of files for CVS to ignore (see the
-description of the <SAMP>`-I'</SAMP> option, and
-see section <A HREF="cvs_141.html#SEC148">Ignoring files via cvsignore</A>).
If you remove your working
-sources, this file will be lost.
-
-Note that no warning message like this is printed for
-spurious directories that CVS encounters. The
-directory, and all its contents, are silently ignored.
-
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_116.html">previous</A>,
<A HREF="cvs_118.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_118.html
===================================================================
RCS file: manual/html_node/cvs_118.html
diff -N manual/html_node/cvs_118.html
--- manual/html_node/cvs_118.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,33 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - release examples</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_117.html">previous</A>,
<A HREF="cvs_119.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC125" HREF="cvs_toc.html#TOC125">release examples</A></H3>
-
-<P>
-Release the module, and delete your local working copy
-of the files.
-
-</P>
-
-<PRE>
-$ cd .. # You must stand immediately above the
- # sources when you issue <SAMP>`cvs release'</SAMP>.
-$ cvs release -d tc
-You have [0] altered files in this repository.
-Are you sure you want to release (and delete) module `tc': y
-$
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_117.html">previous</A>,
<A HREF="cvs_119.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_119.html
===================================================================
RCS file: manual/html_node/cvs_119.html
diff -N manual/html_node/cvs_119.html
--- manual/html_node/cvs_119.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,54 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - rtag</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_118.html">previous</A>,
<A HREF="cvs_120.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC126" HREF="cvs_toc.html#TOC126">rtag--Add a symbolic tag to a
module</A></H2>
-<P>
-<A NAME="IDX352"></A>
-
-</P>
-
-<UL>
-<LI>
-
-rtag [-falnR] [-b] [-d] [-r tag | -Ddate] symbolic_tag modules...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: rfreeze
-</UL>
-
-<P>
-You can use this command to assign symbolic tags to
-particular, explicitly specified source revisions in
-the repository. <CODE>rtag</CODE> works directly on the
-repository contents (and requires no prior checkout).
-Use <CODE>tag</CODE> instead (see section <A
HREF="cvs_123.html#SEC130">tag--Add a symbolic tag to checked out versions of
files</A>), to base the
-selection of revisions on the contents of your
-working directory.
-
-</P>
-<P>
-If you attempt to use a tag name that already exists,
-CVS will complain and not overwrite that tag. Use
-the <SAMP>`-F'</SAMP> option to force the new tag value.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_118.html">previous</A>,
<A HREF="cvs_120.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_12.html
===================================================================
RCS file: manual/html_node/cvs_12.html
diff -N manual/html_node/cvs_12.html
--- manual/html_node/cvs_12.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,90 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Cleaning up</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_11.html">previous</A>,
<A HREF="cvs_13.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC13" HREF="cvs_toc.html#TOC13">Cleaning up</A></H2>
-<P>
-<A NAME="IDX50"></A>
-<A NAME="IDX51"></A>
-<A NAME="IDX52"></A>
-<A NAME="IDX53"></A>
-
-</P>
-<P>
-Before you turn to other tasks you decide to remove your working copy of
-tc. One acceptable way to do that is of course
-
-</P>
-
-<PRE>
-$ cd ..
-$ rm -r tc
-</PRE>
-
-<P>
-but a better way is to use the <CODE>release</CODE> command (see section <A
HREF="cvs_115.html#SEC122">release--Indicate that a Module is no longer in
use</A>):
-
-</P>
-
-<PRE>
-$ cd ..
-$ cvs release -d tc
-M driver.c
-? tc
-You have [1] altered files in this repository.
-Are you sure you want to release (and delete) module `tc': n
-** `release' aborted by user choice.
-</PRE>
-
-<P>
-The <CODE>release</CODE> command checks that all your modifications have been
-committed. If history logging is enabled it also makes a note in the
-history file. See section <A HREF="cvs_142.html#SEC149">The history file</A>.
-
-</P>
-<P>
-When you use the <SAMP>`-d'</SAMP> flag with <CODE>release</CODE>, it
-also removes your working copy.
-
-</P>
-<P>
-In the example above, the <CODE>release</CODE> command wrote a couple of lines
-of output. <SAMP>`? tc'</SAMP> means that the file <TT>`tc'</TT> is unknown
to CVS.
-That is nothing to worry about: <TT>`tc'</TT> is the executable compiler,
-and it should not be stored in the repository. See section <A
HREF="cvs_141.html#SEC148">Ignoring files via cvsignore</A>,
-for information about how to make that warning go away.
-See section <A HREF="cvs_117.html#SEC124">release output</A>, for a complete
explanation of
-all possible output from <CODE>release</CODE>.
-
-</P>
-<P>
-<SAMP>`M driver.c'</SAMP> is more serious. It means that the
-file <TT>`driver.c'</TT> has been modified since it was
-checked out.
-
-</P>
-<P>
-The <CODE>release</CODE> command always finishes by telling
-you how many modified files you have in your working
-copy of the sources, and then asks you for confirmation
-before deleting any files or making any note in the
-history file.
-
-</P>
-<P>
-You decide to play it safe and answer <KBD>n <KBD>RET</KBD></KBD>
-when <CODE>release</CODE> asks for confirmation.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_11.html">previous</A>,
<A HREF="cvs_13.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_120.html
===================================================================
RCS file: manual/html_node/cvs_120.html
diff -N manual/html_node/cvs_120.html
--- manual/html_node/cvs_120.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,96 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - rtag options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_119.html">previous</A>,
<A HREF="cvs_121.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC127" HREF="cvs_toc.html#TOC127">rtag options</A></H3>
-
-<P>
-These standard options are supported by <CODE>rtag</CODE>
-(see section <A HREF="cvs_88.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Tag the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
<VAR>tag</VAR>'</SAMP>
-flags. If no matching revision is found, use the most
-recent revision (instead of ignoring the file).
-
-<DT><CODE>-F</CODE>
-<DD>
-Overwrite an existing tag of the same name on a
-different revision. This option is new in CVS
-1.4. The old behavior is matched by <SAMP>`cvs tag -F'</SAMP>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any tag program that was specified with the
-<SAMP>`-t'</SAMP> flag inside the <TT>`modules'</TT> file.
-(see section <A HREF="cvs_130.html#SEC137">The modules file</A>).
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Only tag those files that contain <VAR>tag</VAR>. This can
-be used to rename a tag: tag only the files identified
-by the old tag, then delete the old tag, leaving the
-new tag on exactly the same files as the old tag.
-</DL>
-
-<P>
-In addition to the above common options, these options
-are available:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-a</CODE>
-<DD>
-Use the <SAMP>`-a'</SAMP> option to have <CODE>rtag</CODE> look in the
-<TT>`Attic'</TT> (see section <A HREF="cvs_60.html#SEC62">Removing files from
a module</A>) for removed files
-that contain the specified tag. The tag is removed from
-these files, which makes it convenient to re-use a
-symbolic tag as development continues (and files get
-removed from the up-coming distribution).
-
-<DT><CODE>-b</CODE>
-<DD>
-Make the tag a branch tag. See section <A
HREF="cvs_48.html#SEC50">Branches</A>.
-
-<DT><CODE>-d</CODE>
-<DD>
-Delete the tag instead of creating it.
-
-In general, tags (often the symbolic names of software
-distributions) should not be removed, but the <SAMP>`-d'</SAMP>
-option is available as a means to remove completely
-obsolete symbolic names if necessary (as might be the
-case for an Alpha release, or if you mistagged a
-module).
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_119.html">previous</A>,
<A HREF="cvs_121.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_121.html
===================================================================
RCS file: manual/html_node/cvs_121.html
diff -N manual/html_node/cvs_121.html
--- manual/html_node/cvs_121.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,53 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - status</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_120.html">previous</A>,
<A HREF="cvs_122.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC128" HREF="cvs_toc.html#TOC128">status--Display status
information on checked out files</A></H2>
-<P>
-<A NAME="IDX353"></A>
-
-</P>
-
-
-<UL>
-<LI>
-
-status [-lR] [-v] [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-Display a brief report on the current status of files
-with respect to the source repository. For information
-on the basic output see section <A HREF="cvs_36.html#SEC38">File status</A>.
For
-information on the <CODE>Sticky tag</CODE> and <CODE>Sticky
-date</CODE> output, see section <A HREF="cvs_52.html#SEC54">Sticky tags</A>.
For information
-on the <CODE>Sticky options</CODE> output, see the <SAMP>`-k'</SAMP>
-option in section <A HREF="cvs_126.html#SEC133">update options</A>.
-
-</P>
-<P>
-You can also use this command to determine the
-potential impact of a <SAMP>`cvs update'</SAMP> on your working
-source directory--but remember that things might
-change in the repository before you run <CODE>update</CODE>.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_120.html">previous</A>,
<A HREF="cvs_122.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_122.html
===================================================================
RCS file: manual/html_node/cvs_122.html
diff -N manual/html_node/cvs_122.html
--- manual/html_node/cvs_122.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,49 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - status options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_121.html">previous</A>,
<A HREF="cvs_123.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC129" HREF="cvs_toc.html#TOC129">status options</A></H3>
-
-<P>
-These standard options are supported by <CODE>status</CODE>
-(see section <A HREF="cvs_88.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-</DL>
-
-<P>
-There is one additional option:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-v</CODE>
-<DD>
-Verbose. In addition to the information normally
-displayed, print all symbolic tags, together with the
-numerical value of the revision or branch they refer
-to. For more information, see section <A
HREF="cvs_49.html#SEC51">Tags--Symbolic revisions</A>
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_121.html">previous</A>,
<A HREF="cvs_123.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_123.html
===================================================================
RCS file: manual/html_node/cvs_123.html
diff -N manual/html_node/cvs_123.html
--- manual/html_node/cvs_123.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,76 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - tag</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_122.html">previous</A>,
<A HREF="cvs_124.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC130" HREF="cvs_toc.html#TOC130">tag--Add a symbolic tag to
checked out versions of files</A></H2>
-<P>
-<A NAME="IDX354"></A>
-
-</P>
-
-<UL>
-<LI>
-
-tag [-lR] [-b] [-c] [-d] symbolic_tag [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: freeze
-</UL>
-
-<P>
-Use this command to assign symbolic tags to the nearest
-repository versions to your working sources. The tags
-are applied immediately to the repository, as with
-<CODE>rtag</CODE>, but the versions are supplied implicitly by the
-CVS records of your working files' history rather than
-applied explicitly.
-
-</P>
-<P>
-One use for tags is to record a snapshot of the
-current sources when the software freeze date of a
-project arrives. As bugs are fixed after the freeze
-date, only those changed sources that are to be part of
-the release need be re-tagged.
-
-</P>
-<P>
-The symbolic tags are meant to permanently record which
-revisions of which files were used in creating a
-software distribution. The <CODE>checkout</CODE> and
-<CODE>update</CODE> commands allow you to extract an exact
-copy of a tagged release at any time in the future,
-regardless of whether files have been changed, added,
-or removed since the release was tagged.
-
-</P>
-<P>
-This command can also be used to delete a symbolic tag,
-or to create a branch. See the options section below.
-
-</P>
-<P>
-If you attempt to use a tag name that already exists,
-CVS will complain and not overwrite that tag. Use
-the <SAMP>`-F'</SAMP> option to force the new tag value.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_122.html">previous</A>,
<A HREF="cvs_124.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_124.html
===================================================================
RCS file: manual/html_node/cvs_124.html
diff -N manual/html_node/cvs_124.html
--- manual/html_node/cvs_124.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,72 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - tag options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_123.html">previous</A>,
<A HREF="cvs_125.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC131" HREF="cvs_toc.html#TOC131">tag options</A></H3>
-
-<P>
-These standard options are supported by <CODE>tag</CODE>
-(see section <A HREF="cvs_88.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-F</CODE>
-<DD>
-Overwrite an existing tag of the same name on a
-different revision. This option is new in CVS
-1.4. The old behavior is matched by <SAMP>`cvs tag -F'</SAMP>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-</DL>
-
-<P>
-Two special options are available:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b</CODE>
-<DD>
-The -b option makes the tag a branch tag
-(see section <A HREF="cvs_48.html#SEC50">Branches</A>), allowing concurrent,
isolated
-development. This is most useful for creating a patch
-to a previously released software distribution.
-
-<DT><CODE>-c</CODE>
-<DD>
-The -c option checks that all files which are to be tagged are
-unmodified. This can be used to make sure that you can reconstruct the
-current file contents.
-
-<DT><CODE>-d</CODE>
-<DD>
-Delete a tag.
-
-If you use <SAMP>`cvs tag -d symbolic_tag'</SAMP>, the symbolic
-tag you specify is deleted instead of being added.
-Warning: Be very certain of your ground before you
-delete a tag; doing this permanently discards some
-historical information, which may later turn out to
-be valuable.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_123.html">previous</A>,
<A HREF="cvs_125.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_125.html
===================================================================
RCS file: manual/html_node/cvs_125.html
diff -N manual/html_node/cvs_125.html
--- manual/html_node/cvs_125.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,46 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - update</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_124.html">previous</A>,
<A HREF="cvs_126.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC132" HREF="cvs_toc.html#TOC132">update--Bring work tree in
sync with repository</A></H2>
-<P>
-<A NAME="IDX355"></A>
-
-</P>
-
-<UL>
-<LI>
-
-update [-AdflPpR] [-d] [-r tag|-D date] files...
-<LI>
-
-Requires: repository, working directory.
-<LI>
-
-Changes: working directory.
-</UL>
-
-<P>
-After you've run checkout to create your private copy
-of source from the common repository, other developers
-will continue changing the central source. From time
-to time, when it is convenient in your development
-process, you can use the <CODE>update</CODE> command from
-within your working directory to reconcile your work
-with any revisions applied to the source repository
-since your last checkout or update.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_124.html">previous</A>,
<A HREF="cvs_126.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_126.html
===================================================================
RCS file: manual/html_node/cvs_126.html
diff -N manual/html_node/cvs_126.html
--- manual/html_node/cvs_126.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,143 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - update options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_125.html">previous</A>,
<A HREF="cvs_127.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC133" HREF="cvs_toc.html#TOC133">update options</A></H3>
-
-<P>
-These standard options are available with <CODE>update</CODE>
-(see section <A HREF="cvs_88.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D date</CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-This option is sticky, and implies <SAMP>`-P'</SAMP>.
-See section <A HREF="cvs_52.html#SEC54">Sticky tags</A>, for more information
on sticky tags/dates.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
-<VAR>tag</VAR>'</SAMP> flags. If no matching revision is found,
-retrieve the most recent revision (instead of ignoring
-the file).
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Process RCS keywords according to <VAR>kflag</VAR>. See
-co(1). This option is sticky; future updates of
-this file in this working directory will use the same
-<VAR>kflag</VAR>. The <CODE>status</CODE> command can be viewed
-to see the sticky options. See section <A
HREF="cvs_121.html#SEC128">status--Display status information on checked out
files</A>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory. See section <A
HREF="cvs_58.html#SEC60">Recursive behavior</A>.
-
-<DT><CODE>-P</CODE>
-<DD>
-Prune empty directories.
-
-<DT><CODE>-p</CODE>
-<DD>
-Pipe files to the standard output.
-
-<DT><CODE>-R</CODE>
-<DD>
-Operate recursively. This is on by default.
-See section <A HREF="cvs_58.html#SEC60">Recursive behavior</A>.
-
-<DT><CODE>-r tag</CODE>
-<DD>
-Retrieve revision <VAR>tag</VAR>. This option is sticky,
-and implies <SAMP>`-P'</SAMP>.
-See section <A HREF="cvs_52.html#SEC54">Sticky tags</A>, for more information
on sticky tags/dates.
-</DL>
-
-<P>
-These special options are also available with
-<CODE>update</CODE>.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-A</CODE>
-<DD>
-Reset any sticky tags, dates, or <SAMP>`-k'</SAMP> options.
-See section <A HREF="cvs_52.html#SEC54">Sticky tags</A>, for more information
on sticky tags/dates.
-
-<DT><CODE>-d</CODE>
-<DD>
-Create any directories that exist in the repository if
-they're missing from the working directory. Normally,
-<CODE>update</CODE> acts only on directories and files that
-were already enrolled in your working directory.
-
-This is useful for updating directories that were
-created in the repository since the initial checkout;
-but it has an unfortunate side effect. If you
-deliberately avoided certain directories in the
-repository when you created your working directory
-(either through use of a module name or by listing
-explicitly the files and directories you wanted on the
-command line), then updating with <SAMP>`-d'</SAMP> will create
-those directories, which may not be what you want.
-
-<DT><CODE>-I <VAR>name</VAR></CODE>
-<DD>
-Ignore files whose names match <VAR>name</VAR> (in your
-working directory) during the update. You can specify
-<SAMP>`-I'</SAMP> more than once on the command line to specify
-several files to ignore. Use <SAMP>`-I !'</SAMP> to avoid
-ignoring any files at all. See section <A HREF="cvs_141.html#SEC148">Ignoring
files via cvsignore</A>, for other
-ways to make CVS ignore some files.
-
-<DT><CODE>-W<VAR>spec</VAR></CODE>
-<DD>
-Specify file names that should be filtered during
-update. You can use this option repeatedly.
-
-<VAR>spec</VAR> can be a file name pattern of the same type
-that you can specify in the <TT>`.cvswrappers'</TT>
-file. See section <A HREF="cvs_131.html#SEC138">The cvswrappers file</A>.
-
-<DT><CODE>-j<VAR>revision</VAR></CODE>
-<DD>
-With two <SAMP>`-j'</SAMP> options, merge changes from the
-revision specified with the first <SAMP>`-j'</SAMP> option to
-the revision specified with the second <SAMP>`j'</SAMP> option,
-into the working directory.
-
-With one <SAMP>`-j'</SAMP> option, merge changes from the
-ancestor revision to the revision specified with the
-<SAMP>`-j'</SAMP> option, into the working directory. The
-ancestor revision is the common ancestor of the
-revision which the working directory is based on, and
-the revision specified in the <SAMP>`-j'</SAMP> option.
-
-In addition, each -j option can contain an optional
-date specification which, when used with branches, can
-limit the chosen revision to one within a specific
-date. An optional date is specified by adding a colon
-(:) to the tag:
-<SAMP>`-j<VAR>Symbolic_Tag</VAR>:<VAR>Date_Specifier</VAR>'</SAMP>.
-
-See section <A HREF="cvs_53.html#SEC55">Merging</A>.
-
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_125.html">previous</A>,
<A HREF="cvs_127.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_127.html
===================================================================
RCS file: manual/html_node/cvs_127.html
diff -N manual/html_node/cvs_127.html
--- manual/html_node/cvs_127.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,99 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - update output</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_126.html">previous</A>,
<A HREF="cvs_128.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC134" HREF="cvs_toc.html#TOC134">update output</A></H3>
-
-<P>
-<CODE>update</CODE> and <CODE>checkout</CODE> keep you informed of
-its progress by printing a line for each file, preceded
-by one character indicating the status of the file:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>U <VAR>file</VAR></CODE>
-<DD>
-The file was brought up to date with respect to the
-repository. This is done for any file that exists in
-the repository but not in your source, and for files
-that you haven't changed but are not the most recent
-versions available in the repository.
-
-<DT><CODE>A <VAR>file</VAR></CODE>
-<DD>
-The file has been added to your private copy of the
-sources, and will be added to the source repository
-when you run <CODE>commit</CODE> on the file. This is a
-reminder to you that the file needs to be committed.
-
-<DT><CODE>R <VAR>file</VAR></CODE>
-<DD>
-The file has been removed from your private copy of the
-sources, and will be removed from the source repository
-when you run <CODE>commit</CODE> on the file. This is a
-reminder to you that the file needs to be committed.
-
-<DT><CODE>M <VAR>file</VAR></CODE>
-<DD>
-The file is modified in your working directory.
-
-<SAMP>`M'</SAMP> can indicate one of two states for a file
-you're working on: either there were no modifications
-to the same file in the repository, so that your file
-remains as you last saw it; or there were modifications
-in the repository as well as in your copy, but they
-were merged successfully, without conflict, in your
-working directory.
-
-CVS will print some messages if it merges your work,
-and a backup copy of your working file (as it looked
-before you ran <CODE>update</CODE>) will be made. The exact
-name of that file is printed while <CODE>update</CODE> runs.
-
-<DT><CODE>C <VAR>file</VAR></CODE>
-<DD>
-<A NAME="IDX356"></A>
-<A NAME="IDX357"></A>
-A conflict was detected while trying to merge your
-changes to <VAR>file</VAR> with changes from the source
-repository. <VAR>file</VAR> (the copy in your working
-directory) is now the output of the rcsmerge(1) command
-on the two revisions; an unmodified copy of your file
-is also in your working directory, with the name
-<TT>`.#<VAR>file</VAR>.<VAR>revision</VAR>'</TT> where <VAR>revision</VAR>
-is the RCS revision that your modified file started
-from. Resolve the conflict as described in
-section <A HREF="cvs_38.html#SEC40">Conflicts example</A>
-(Note that some systems automatically purge
-files that begin with <TT>`.#'</TT> if they have not been
-accessed for a few days. If you intend to keep a copy
-of your original file, it is a very good idea to rename
-it.) Under VMS, the file name starts with
-<TT>`__'</TT> rather than <TT>`.#'</TT>.
-
-<DT><CODE>? <VAR>file</VAR></CODE>
-<DD>
-<VAR>file</VAR> is in your working directory, but does not
-correspond to anything in the source repository, and is
-not in the list of files for CVS to ignore (see the
-description of the <SAMP>`-I'</SAMP> option, and
-see section <A HREF="cvs_141.html#SEC148">Ignoring files via cvsignore</A>).
-
-Note that no warning message like this is printed for
-spurious directories that CVS encounters. The
-directory, and all its contents, are silently ignored.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_126.html">previous</A>,
<A HREF="cvs_128.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_128.html
===================================================================
RCS file: manual/html_node/cvs_128.html
diff -N manual/html_node/cvs_128.html
--- manual/html_node/cvs_128.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,30 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - update examples</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_127.html">previous</A>,
<A HREF="cvs_129.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC135" HREF="cvs_toc.html#TOC135">update examples</A></H3>
-
-<P>
-The following line will display all files which are not
-up-to-date without actually change anything in your
-working directory. It can be used to check what has
-been going on with the project.
-
-</P>
-
-<PRE>
-$ cvs -n -q update
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_127.html">previous</A>,
<A HREF="cvs_129.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_129.html
===================================================================
RCS file: manual/html_node/cvs_129.html
diff -N manual/html_node/cvs_129.html
--- manual/html_node/cvs_129.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,39 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Administrative files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_128.html">previous</A>,
<A HREF="cvs_130.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC136" HREF="cvs_toc.html#TOC136">Reference manual for the
Administrative files</A></H1>
-<P>
-<A NAME="IDX358"></A>
-<A NAME="IDX359"></A>
-<A NAME="IDX360"></A>
-<A NAME="IDX361"></A>
-
-</P>
-<P>
-Inside the repository, in the directory
-<TT>`$CVSROOT/CVSROOT'</TT>, there are a number of
-supportive files for CVS. You can use CVS in a limited
-fashion without any of them, but if they are set up
-properly they can help make life easier. For a
-discussion of how to edit them, See section <A HREF="cvs_19.html#SEC20">The
administrative files</A>.
-
-</P>
-<P>
-The most important of these files is the <TT>`modules'</TT>
-file, which defines the modules inside the repository.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_128.html">previous</A>,
<A HREF="cvs_130.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_13.html
===================================================================
RCS file: manual/html_node/cvs_13.html
diff -N manual/html_node/cvs_13.html
--- manual/html_node/cvs_13.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,54 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Viewing differences</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_12.html">previous</A>,
<A HREF="cvs_14.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC14" HREF="cvs_toc.html#TOC14">Viewing differences</A></H2>
-<P>
-<A NAME="IDX54"></A>
-<A NAME="IDX55"></A>
-
-</P>
-<P>
-You do not remember modifying <TT>`driver.c'</TT>, so you want to see what
-has happened to that file.
-
-</P>
-
-<PRE>
-$ cd tc
-$ cvs diff driver.c
-</PRE>
-
-<P>
-This command runs <CODE>diff</CODE> to compare the version of
<TT>`driver.c'</TT>
-that you checked out with your working copy. When you see the output
-you remember that you added a command line option that enabled the
-optimization pass. You check it in, and release the module.
-
-</P>
-
-<PRE>
-$ cvs commit -m "Added an optimization pass" driver.c
-Checking in driver.c;
-/usr/local/cvsroot/tc/driver.c,v <-- driver.c
-new revision: 1.2; previous revision: 1.1
-done
-$ cd ..
-$ cvs release -d tc
-? tc
-You have [0] altered files in this repository.
-Are you sure you want to release (and delete) module `tc': y
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_12.html">previous</A>,
<A HREF="cvs_14.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_130.html
===================================================================
RCS file: manual/html_node/cvs_130.html
diff -N manual/html_node/cvs_130.html
--- manual/html_node/cvs_130.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,159 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - modules</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_129.html">previous</A>,
<A HREF="cvs_131.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC137" HREF="cvs_toc.html#TOC137">The modules file</A></H2>
-<P>
-<A NAME="IDX362"></A>
-<A NAME="IDX363"></A>
-
-</P>
-<P>
-The <TT>`modules'</TT> file records your definitions of
-names for collections of source code. CVS will
-use these definitions if you use CVS to update the
-modules file (use normal commands like <CODE>add</CODE>,
-<CODE>commit</CODE>, etc).
-
-</P>
-<P>
-The <TT>`modules'</TT> file may contain blank lines and
-comments (lines beginning with <SAMP>`#'</SAMP>) as well as
-module definitions. Long lines can be continued on the
-next line by specifying a backslash (<SAMP>`\'</SAMP>) as the
-last character on the line.
-
-</P>
-<P>
-A module definition is a single line of the
-<TT>`modules'</TT> file, in either of two formats. In both
-cases, <VAR>mname</VAR> represents the symbolic module name,
-and the remainder of the line is its definition.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE><VAR>mname</VAR> -a <VAR>aliases</VAR>...</CODE>
-<DD>
-This represents the simplest way of defining a module
-<VAR>mname</VAR>. The <SAMP>`-a'</SAMP> flags the definition as a
-simple alias: CVS will treat any use of <VAR>mname</VAR> (as
-a command argument) as if the list of names
-<VAR>aliases</VAR> had been specified instead.
-<VAR>aliases</VAR> may contain either other module names or
-paths. When you use paths in aliases, <CODE>checkout</CODE>
-creates all intermediate directories in the working
-directory, just as if the path had been specified
-explicitly in the CVS arguments.
-
-<DT><CODE><VAR>mname</VAR> [ options ] <VAR>dir</VAR> [ <VAR>files</VAR>... ]
[ &<VAR>module</VAR>... ]</CODE>
-<DD>
-In the simplest case, this form of module definition
-reduces to <SAMP>`<VAR>mname</VAR> <VAR>dir</VAR>'</SAMP>. This defines
-all the files in directory <VAR>dir</VAR> as module mname.
-<VAR>dir</VAR> is a relative path (from <CODE>$CVSROOT</CODE>) to a
-directory of source in the source repository. In this
-case, on checkout, a single directory called
-<VAR>mname</VAR> is created as a working directory; no
-intermediate directory levels are used by default, even
-if <VAR>dir</VAR> was a path involving several directory
-levels.
-
-By explicitly specifying files in the module definition
-after <VAR>dir</VAR>, you can select particular files from
-directory <VAR>dir</VAR>. The sample definition for
-<SAMP>`modules'</SAMP> is an example of a module defined with a
-single file from a particular directory. Here is
-another example:
-
-
-<PRE>
-m4test unsupported/gnu/m4 foreach.m4 forloop.m4
-</PRE>
-
-With this definition, executing <SAMP>`cvs checkout
-m4test'</SAMP> will create a single working directory
-<TT>`m4test'</TT> containing the two files listed, which
-both come from a common directory several levels deep
-in the CVS source repository.
-
-A module definition can refer to other modules by
-including <SAMP>`&<VAR>module</VAR>'</SAMP> in its definition.
-<CODE>checkout</CODE> creates a subdirectory for each such
-module, in your working directory.
-
-<DL COMPACT>
-
-<DT><CODE>-d <VAR>name</VAR></CODE>
-<DD>
-Name the working directory something other than the
-module name.
-
-<A NAME="IDX364"></A>
-<DT><CODE>-e <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are exported. <VAR>prog</VAR> runs with a single
-argument, the module name.
-
-<A NAME="IDX365"></A>
-<DT><CODE>-i <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are committed. <VAR>prog</VAR> runs with a single
-argument, the full pathname of the affected directory
-in a source repository. The <TT>`commitinfo'</TT>,
-<TT>`loginfo'</TT>, and <TT>`editinfo'</TT> files provide other
-ways to call a program on commit.
-
-<A NAME="IDX366"></A>
-<DT><CODE>-o <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are checked out. <VAR>prog</VAR> runs with a single
-argument, the module name.
-
-<A NAME="IDX367"></A>
-<A NAME="IDX368"></A>
-<DT><CODE>-s <VAR>status</VAR></CODE>
-<DD>
-Assign a status to the module. When the module file is
-printed with <SAMP>`cvs checkout -s'</SAMP> the modules are
-sorted according to primarily module status, and
-secondarily according to the module name. This option
-has no other meaning. You can use this option for
-several things besides status: for instance, list the
-person that is responsible for this module.
-
-<A NAME="IDX369"></A>
-<DT><CODE>-t <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever files in a
-module are tagged with <CODE>rtag</CODE>. <VAR>prog</VAR> runs
-with two arguments: the module name and the symbolic
-tag specified to <CODE>rtag</CODE>. There is no way to
-specify a program to run when <CODE>tag</CODE> is executed.
-
-<A NAME="IDX370"></A>
-<DT><CODE>-u <VAR>prog</VAR></CODE>
-<DD>
-Specify a program <VAR>prog</VAR> to run whenever <SAMP>`cvs
-update'</SAMP> is executed from the top-level directory of the
-checked-out module. <VAR>prog</VAR> runs with a single
-argument, the full path to the source repository for
-this module.
-</DL>
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_129.html">previous</A>,
<A HREF="cvs_131.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_131.html
===================================================================
RCS file: manual/html_node/cvs_131.html
diff -N manual/html_node/cvs_131.html
--- manual/html_node/cvs_131.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,122 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Wrappers</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_130.html">previous</A>,
<A HREF="cvs_132.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC138" HREF="cvs_toc.html#TOC138">The cvswrappers file</A></H2>
-<P>
-<A NAME="IDX371"></A>
-<A NAME="IDX372"></A>
-<A NAME="IDX373"></A>
-
-</P>
-
-<P>
-Wrappers allow you to set a hook which transforms files on
-their way in and out of CVS. Most or all of the
-wrappers features do not work with client/server CVS.
-
-</P>
-<P>
-The file <TT>`cvswrappers'</TT> defines the script that will be
-run on a file when its name matches a regular
-expresion. There are two scripts that can be run on a
-file or directory. One script is executed on the file/directory
-before being checked into the repository (this is denoted
-with the <CODE>-t</CODE> flag) and the other when the file is
-checked out of the repository (this is denoted with the
-<CODE>-f</CODE> flag)
-
-</P>
-<P>
-The <TT>`cvswrappers'</TT> also has a <SAMP>`-m'</SAMP> option to
-specify the merge methodology that should be used when
-the file is updated. <CODE>MERGE</CODE> means the usual
-CVS behavior: try to merge the files (this
-generally will not work for binary files). <CODE>COPY</CODE>
-means that <CODE>cvs update</CODE> will merely copy one
-version over the other, and require the user using
-mechanisms outside CVS, to insert any necessary
-changes.
-The <SAMP>`-m'</SAMP> wrapper option only affects behavior when
-merging is done on update; it does not affect how files
-are stored. See See section <A HREF="cvs_81.html#SEC83">Handling binary
files</A>, for more on
-binary files.
-
-</P>
-<P>
-The basic format of the file <TT>`cvswrappers'</TT> is:
-
-</P>
-
-<PRE>
-wildcard [option value][option value]...
-
-where option is one of
--f from cvs filter value: path to filter
--t to cvs filter value: path to filter
--m update methodology value: MERGE or COPY
--k keyword expansion value: expansion mode
-
-and value is a single-quote delimited value.
-</PRE>
-
-
-<PRE>
-*.nib -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
-*.c -t 'indent %s %s'
-</PRE>
-
-<P>
-The above example of a <TT>`cvswrappers'</TT> file
-states that all files/directories that end with a <CODE>.nib</CODE>
-should be filtered with the <TT>`wrap'</TT> program before
-checking the file into the repository. The file should
-be filtered though the <TT>`unwrap'</TT> program when the
-file is checked out of the repository. The
-<TT>`cvswrappers'</TT> file also states that a <CODE>COPY</CODE>
-methodology should be used when updating the files in
-the repository (that is no merging should be performed).
-
-</P>
-<P>
-The last example line says that all files that end with
-a <CODE>*.c</CODE> should be filtered with <TT>`indent'</TT>
-before being checked into the repository. Unlike the previous
-example no filtering of the <CODE>*.c</CODE> file is done when
-it is checked out of the repository.
-The <CODE>-t</CODE> filter is called with two arguments,
-the first is the name of the file/directory to filter
-and the second is the pathname to where the resulting
-filtered file should be placed.
-
-</P>
-<P>
-The <CODE>-f</CODE> filter is called with one argument,
-which is the name of the file to filter from. The end
-result of this filter will be a file in the users directory
-that they can work on as they normally would.
-
-</P>
-<P>
-For another example, the following command imports a
-directory, treating files whose name ends in
-<SAMP>`.exe'</SAMP> as binary:
-
-</P>
-
-<PRE>
-cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_130.html">previous</A>,
<A HREF="cvs_132.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_132.html
===================================================================
RCS file: manual/html_node/cvs_132.html
diff -N manual/html_node/cvs_132.html
--- manual/html_node/cvs_132.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,63 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - commit files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_131.html">previous</A>,
<A HREF="cvs_133.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC139" HREF="cvs_toc.html#TOC139">The commit support
files</A></H2>
-<P>
-<A NAME="IDX374"></A>
-
-</P>
-<P>
-The <SAMP>`-i'</SAMP> flag in the <TT>`modules'</TT> file can be
-used to run a certain program whenever files are
-committed (see section <A HREF="cvs_130.html#SEC137">The modules file</A>).
The files described in
-this section provide other, more flexible, ways to run
-programs whenever something is committed.
-
-</P>
-<P>
-There are three kind of programs that can be run on
-commit. They are specified in files in the repository,
-as described below. The following table summarizes the
-file names and the purpose of the corresponding
-programs.
-
-</P>
-<DL COMPACT>
-
-<DT><TT>`commitinfo'</TT>
-<DD>
-The program is responsible for checking that the commit
-is allowed. If it exits with a non-zero exit status
-the commit will be aborted.
-
-<DT><TT>`editinfo'</TT>
-<DD>
-The specified program is used to edit the log message,
-and possibly verify that it contains all required
-fields. This is most useful in combination with the
-<TT>`rcsinfo'</TT> file, which can hold a log message
-template (see section <A HREF="cvs_140.html#SEC147">Rcsinfo</A>).
-
-<DT><TT>`loginfo'</TT>
-<DD>
-The specified program is called when the commit is
-complete. It receives the log message and some
-additional information and can store the log message in
-a file, or mail it to appropriate persons, or maybe
-post it to a local newsgroup, or... Your
-imagination is the limit!
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_131.html">previous</A>,
<A HREF="cvs_133.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_133.html
===================================================================
RCS file: manual/html_node/cvs_133.html
diff -N manual/html_node/cvs_133.html
--- manual/html_node/cvs_133.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,61 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - syntax</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_132.html">previous</A>,
<A HREF="cvs_134.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC140" HREF="cvs_toc.html#TOC140">The common syntax</A></H3>
-<P>
-<A NAME="IDX375"></A>
-<A NAME="IDX376"></A>
-<A NAME="IDX377"></A>
-
-</P>
-
-<P>
-The four files <TT>`commitinfo'</TT>, <TT>`loginfo'</TT>,
-<TT>`rcsinfo'</TT> and <TT>`editinfo'</TT> all have a common
-format. The purpose of the files are described later
-on. The common syntax is described here.
-
-</P>
-<P>
-Each line contains the following:
-
-<UL>
-<LI>
-
-A regular expression
-
-<LI>
-
-A whitespace separator--one or more spaces and/or tabs.
-
-<LI>
-
-A file name or command-line template.
-</UL>
-
-<P>
-Blank lines are ignored. Lines that start with the
-character <SAMP>`#'</SAMP> are treated as comments. Long lines
-unfortunately can <EM>not</EM> be broken in two parts in
-any way.
-
-</P>
-<P>
-The first regular expression that matches the current
-directory name in the repository is used. The rest of the line
-is used as a file name or command-line as appropriate.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_132.html">previous</A>,
<A HREF="cvs_134.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_134.html
===================================================================
RCS file: manual/html_node/cvs_134.html
diff -N manual/html_node/cvs_134.html
--- manual/html_node/cvs_134.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,72 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - commitinfo</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_133.html">previous</A>,
<A HREF="cvs_135.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC141" HREF="cvs_toc.html#TOC141">Commitinfo</A></H2>
-<P>
-<A NAME="IDX378"></A>
-<A NAME="IDX379"></A>
-<A NAME="IDX380"></A>
-
-</P>
-<P>
-The <TT>`commitinfo'</TT> file defines programs to execute
-whenever <SAMP>`cvs commit'</SAMP> is about to execute. These
-programs are used for pre-commit checking to verify
-that the modified, added and removed files are really
-ready to be committed. This could be used, for
-instance, to verify that the changed files conform to
-to your site's standards for coding practice.
-
-</P>
-<P>
-As mentioned earlier, each line in the
-<TT>`commitinfo'</TT> file consists of a regular expression
-and a command-line template. The template can include
-a program name and any number of arguments you wish to
-supply to it. The full path to the current source
-repository is appended to the template, followed by the
-file names of any files involved in the commit (added,
-removed, and modified files).
-
-</P>
-<P>
-The first line with a regular expression matching the
-relative path to the module will be used. If the
-command returns a non-zero exit status the commit will
-be aborted.
-
-</P>
-<P>
-<A NAME="IDX381"></A>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-<A NAME="IDX382"></A>
-All occurances of the name <SAMP>`ALL'</SAMP> appearing as a
-regular expression are used in addition to the first
-matching regular expression or the name <SAMP>`DEFAULT'</SAMP>.
-
-</P>
-<P>
-Note: when CVS is accessing a remote repository,
-<TT>`commitinfo'</TT> will be run on the <EM>remote</EM>
-(i.e., server) side, not the client side (see section <A
HREF="cvs_22.html#SEC24">Remote repositories</A>).
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_133.html">previous</A>,
<A HREF="cvs_135.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_135.html
===================================================================
RCS file: manual/html_node/cvs_135.html
diff -N manual/html_node/cvs_135.html
--- manual/html_node/cvs_135.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,86 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - editinfo</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_134.html">previous</A>,
<A HREF="cvs_136.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC142" HREF="cvs_toc.html#TOC142">Editinfo</A></H2>
-<P>
-<A NAME="IDX383"></A>
-<A NAME="IDX384"></A>
-<A NAME="IDX385"></A>
-<A NAME="IDX386"></A>
-
-</P>
-<P>
-If you want to make sure that all log messages look the
-same way, you can use the <TT>`editinfo'</TT> file to
-specify a program that is used to edit the log message.
-This program could be a custom-made editor that always
-enforces a certain style of the log message, or maybe a
-simple shell script that calls an editor, and checks
-that the entered message contains the required fields.
-
-</P>
-<P>
-If no matching line is found in the <TT>`editinfo'</TT>
-file, the editor specified in the environment variable
-<CODE>$CVSEDITOR</CODE> is used instead. If that variable is
-not set, then the environment variable <CODE>$EDITOR</CODE>
-is used instead. If that variable is not
-set a precompiled default, normally <CODE>vi</CODE>, will be
-used.
-
-</P>
-<P>
-The <TT>`editinfo'</TT> file is often most useful together
-with the <TT>`rcsinfo'</TT> file, which can be used to
-specify a log message template.
-
-</P>
-<P>
-Each line in the <TT>`editinfo'</TT> file consists of a
-regular expression and a command-line template. The
-template must include a program name, and can include
-any number of arguments. The full path to the current
-log message template file is appended to the template.
-
-</P>
-<P>
-One thing that should be noted is that the <SAMP>`ALL'</SAMP>
-keyword is not supported. If more than one matching
-line is found, the first one is used. This can be
-useful for specifying a default edit script in a
-module, and then overriding it in a subdirectory.
-
-</P>
-<P>
-<A NAME="IDX387"></A>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-If the edit script exits with a non-zero exit status,
-the commit is aborted.
-
-</P>
-<P>
-Note: when CVS is accessing a remote repository,
-or when the <SAMP>`-m'</SAMP> or <SAMP>`-F'</SAMP> options to <CODE>cvs
-commit</CODE> are used, <TT>`editinfo'</TT> will not be consulted.
-There is no good workaround for this.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_134.html">previous</A>,
<A HREF="cvs_136.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_136.html
===================================================================
RCS file: manual/html_node/cvs_136.html
diff -N manual/html_node/cvs_136.html
--- manual/html_node/cvs_136.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,79 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - editinfo example</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_135.html">previous</A>,
<A HREF="cvs_137.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC143" HREF="cvs_toc.html#TOC143">Editinfo example</A></H3>
-
-<P>
-The following is a little silly example of a
-<TT>`editinfo'</TT> file, together with the corresponding
-<TT>`rcsinfo'</TT> file, the log message template and an
-editor script. We begin with the log message template.
-We want to always record a bug-id number on the first
-line of the log message. The rest of log message is
-free text. The following template is found in the file
-<TT>`/usr/cvssupport/tc.template'</TT>.
-
-</P>
-
-<PRE>
-BugId:
-</PRE>
-
-<P>
-The script <TT>`/usr/cvssupport/bugid.edit'</TT> is used to
-edit the log message.
-
-</P>
-
-<PRE>
-#!/bin/sh
-#
-# bugid.edit filename
-#
-# Call $EDITOR on FILENAME, and verify that the
-# resulting file contains a valid bugid on the first
-# line.
-if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
-if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
-$CVSEDITOR $1
-until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
-do echo -n "No BugId found. Edit again? ([y]/n)"
- read ans
- case ${ans} in
- n*) exit 1;;
- esac
- $CVSEDITOR $1
-done
-</PRE>
-
-<P>
-The <TT>`editinfo'</TT> file contains this line:
-
-</P>
-
-<PRE>
-^tc /usr/cvssupport/bugid.edit
-</PRE>
-
-<P>
-The <TT>`rcsinfo'</TT> file contains this line:
-
-</P>
-
-<PRE>
-^tc /usr/cvssupport/tc.template
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_135.html">previous</A>,
<A HREF="cvs_137.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_137.html
===================================================================
RCS file: manual/html_node/cvs_137.html
diff -N manual/html_node/cvs_137.html
--- manual/html_node/cvs_137.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,70 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - loginfo</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_136.html">previous</A>,
<A HREF="cvs_138.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC144" HREF="cvs_toc.html#TOC144">Loginfo</A></H2>
-<P>
-<A NAME="IDX388"></A>
-<A NAME="IDX389"></A>
-<A NAME="IDX390"></A>
-<A NAME="IDX391"></A>
-<A NAME="IDX392"></A>
-
-</P>
-<P>
-The <TT>`loginfo'</TT> file is used to control where
-<SAMP>`cvs commit'</SAMP> log information is sent. The first
-entry on a line is a regular expression which is tested
-against the directory that the change is being made to,
-relative to the <CODE>$CVSROOT</CODE>. If a match is found, then
-the remainder of the line is a filter program that
-should expect log information on its standard input.
-
-</P>
-<P>
-The filter program may use one and only one % modifier
-(a la printf). If <SAMP>`%s'</SAMP> is specified in the filter
-program, a brief title is included (enclosed in single
-quotes) showing the modified file names.
-
-</P>
-<P>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-All occurances of the name <SAMP>`ALL'</SAMP> appearing as a
-regular expression are used in addition to the first
-matching regular expression or <SAMP>`DEFAULT'</SAMP>.
-
-</P>
-<P>
-The first matching regular expression is used.
-
-</P>
-<P>
-See section <A HREF="cvs_132.html#SEC139">The commit support files</A>, for a
description of the syntax of
-the <TT>`loginfo'</TT> file.
-
-</P>
-<P>
-Note: when CVS is accessing a remote repository,
-<TT>`loginfo'</TT> will be run on the <EM>remote</EM>
-(i.e., server) side, not the client side (see section <A
HREF="cvs_22.html#SEC24">Remote repositories</A>).
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_136.html">previous</A>,
<A HREF="cvs_138.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_138.html
===================================================================
RCS file: manual/html_node/cvs_138.html
diff -N manual/html_node/cvs_138.html
--- manual/html_node/cvs_138.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,48 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - loginfo example</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_137.html">previous</A>,
<A HREF="cvs_139.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC145" HREF="cvs_toc.html#TOC145">Loginfo example</A></H3>
-
-<P>
-The following <TT>`loginfo'</TT> file, together with the
-tiny shell-script below, appends all log messages
-to the file <TT>`$CVSROOT/CVSROOT/commitlog'</TT>,
-and any commits to the administrative files (inside
-the <TT>`CVSROOT'</TT> directory) are also logged in
-<TT>`/usr/adm/cvsroot-log'</TT>.
-
-</P>
-
-<PRE>
-ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog
-^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log
-</PRE>
-
-<P>
-The shell-script <TT>`/usr/local/bin/cvs-log'</TT> looks
-like this:
-
-</P>
-
-<PRE>
-#!/bin/sh
-(echo "-----------------------------------------------------------------";
- echo -n $USER" ";
- date;
- echo;
- sed '1s+'${CVSROOT}'++') >> $1
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_137.html">previous</A>,
<A HREF="cvs_139.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_139.html
===================================================================
RCS file: manual/html_node/cvs_139.html
diff -N manual/html_node/cvs_139.html
--- manual/html_node/cvs_139.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,53 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Keeping a checked out copy</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_138.html">previous</A>,
<A HREF="cvs_140.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC146" HREF="cvs_toc.html#TOC146">Keeping a checked out
copy</A></H3>
-
-<P>
-<A NAME="IDX393"></A>
-<A NAME="IDX394"></A>
-
-</P>
-<P>
-It is often useful to maintain a directory tree which
-contains files which correspond to the latest version
-in the repository. For example, other developers might
-want to refer to the latest sources without having to
-check them out, or you might be maintaining a web site
-with CVS and want every checkin to cause the files
-used by the web server to be updated.
-
-</P>
-<P>
-The way to do this is by having loginfo invoke
-<CODE>cvs update</CODE>. Doing so in the naive way will
-cause a problem with locks, so the <CODE>cvs update</CODE>
-must be run in the background.
-Here is an example (this should all be on one line):
-
-</P>
-
-<PRE>
-^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs;
- cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
-</PRE>
-
-<P>
-This will cause checkins to repository directories
-starting with <CODE>cyclic-pages</CODE> to update the checked
-out tree in <TT>`/u/www/local-docs'</TT>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_138.html">previous</A>,
<A HREF="cvs_140.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_14.html
===================================================================
RCS file: manual/html_node/cvs_14.html
diff -N manual/html_node/cvs_14.html
--- manual/html_node/cvs_14.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,80 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Repository</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_13.html">previous</A>,
<A HREF="cvs_15.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC15" HREF="cvs_toc.html#TOC15">The Repository</A></H1>
-<P>
-<A NAME="IDX56"></A>
-<A NAME="IDX57"></A>
-<A NAME="IDX58"></A>
-<A NAME="IDX59"></A>
-<A NAME="IDX60"></A>
-<A NAME="IDX61"></A>
-
-</P>
-<P>
-The CVS <EM>repository</EM> stores a complete copy of
-all the files and directories which are under version
-control.
-
-</P>
-<P>
-Normally, you never access any of the files in the
-repository directly. Instead, you use CVS
-commands to get your own copy of the files, and then
-work on that copy. When you've finished a set of
-changes, you check (or <EM>commit</EM>) them back into the
-repository. The repository then contains the changes
-which you have made, as well as recording exactly what
-you changed, when you changed it, and other such
-information.
-
-</P>
-<P>
-<A NAME="IDX62"></A>
-CVS can access a repository by a variety of
-means. It might be on the local computer, or it might
-be on a computer across the room or across the world.
-To distinguish various ways to access a repository, the
-repository name can start with an <EM>access method</EM>.
-For example, the access method <CODE>:local:</CODE> means to
-access a repository directory, so the repository
-<CODE>:local:/usr/local/cvsroot</CODE> means that the
-repository is in <TT>`/usr/local/cvsroot'</TT> on the
-computer running CVS. For information on other
-access methods, see section <A HREF="cvs_22.html#SEC24">Remote
repositories</A>.
-
-</P>
-<P>
-If the access method is omitted, then if the repository
-does not contain <SAMP>`:'</SAMP>, then <CODE>:local:</CODE> is
-assumed. If it does contain <SAMP>`:'</SAMP> than either
-<CODE>:ext:</CODE> or <CODE>:server:</CODE> is assumed. For
-example, if you have a local repository in
-<TT>`/usr/local/cvsroot'</TT>, you can use
-<CODE>/usr/local/cvsroot</CODE> instead of
-<CODE>:local:/usr/local/cvsroot</CODE>. But if (under
-Windows NT, for example) your local repository is
-<TT>`c:\src\cvsroot'</TT>, then you must specify the access
-method, as in <CODE>:local:c:\src\cvsroot</CODE>.
-
-</P>
-<P>
-The repository is split in two parts. <TT>`$CVSROOT/CVSROOT'</TT> contains
-administrative files for CVS. The other directories contain the actual
-user-defined modules.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_13.html">previous</A>,
<A HREF="cvs_15.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_140.html
===================================================================
RCS file: manual/html_node/cvs_140.html
diff -N manual/html_node/cvs_140.html
--- manual/html_node/cvs_140.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,69 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - rcsinfo</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_139.html">previous</A>,
<A HREF="cvs_141.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC147" HREF="cvs_toc.html#TOC147">Rcsinfo</A></H2>
-<P>
-<A NAME="IDX395"></A>
-<A NAME="IDX396"></A>
-<A NAME="IDX397"></A>
-<A NAME="IDX398"></A>
-
-</P>
-<P>
-The <TT>`rcsinfo'</TT> file can be used to specify a form to
-edit when filling out the commit log. The
-<TT>`rcsinfo'</TT> file has a syntax similar to the
-<TT>`editinfo'</TT>, <TT>`commitinfo'</TT> and <TT>`loginfo'</TT>
-files. See section <A HREF="cvs_133.html#SEC140">The common syntax</A>.
Unlike the other files the second
-part is <EM>not</EM> a command-line template. Instead,
-the part after the regular expression should be a full pathname to
-a file containing the log message template.
-
-</P>
-<P>
-If the repository name does not match any of the
-regular expressions in this file, the <SAMP>`DEFAULT'</SAMP>
-line is used, if it is specified.
-
-</P>
-<P>
-All occurances of the name <SAMP>`ALL'</SAMP> appearing as a
-regular expression are used in addition to the first
-matching regular expression or <SAMP>`DEFAULT'</SAMP>.
-
-</P>
-<P>
-The log message template will be used as a default log
-message. If you specify a log message with <SAMP>`cvs
-commit -m <VAR>message</VAR>'</SAMP> or <SAMP>`cvs commit -f
-<VAR>file</VAR>'</SAMP> that log message will override the
-template.
-
-</P>
-<P>
-See section <A HREF="cvs_136.html#SEC143">Editinfo example</A>, for an example
<TT>`rcsinfo'</TT>
-file.
-
-</P>
-<P>
-When CVS is accessing a remote repository,
-the contents of <TT>`rcsinfo'</TT> at the time a directory
-is first checked out will specify a template which does
-not then change. If you edit <TT>`rcsinfo'</TT> or its
-templates, you may need to check out a new working
-directory.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_139.html">previous</A>,
<A HREF="cvs_141.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_141.html
===================================================================
RCS file: manual/html_node/cvs_141.html
diff -N manual/html_node/cvs_141.html
--- manual/html_node/cvs_141.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,104 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - cvsignore</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_140.html">previous</A>,
<A HREF="cvs_142.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC148" HREF="cvs_toc.html#TOC148">Ignoring files via
cvsignore</A></H2>
-<P>
-<A NAME="IDX399"></A>
-<A NAME="IDX400"></A>
-<A NAME="IDX401"></A>
-
-</P>
-<P>
-There are certain file names that frequently occur
-inside your working copy, but that you don't want to
-put under CVS control. Examples are all the object
-files that you get while you compile your sources.
-Normally, when you run <SAMP>`cvs update'</SAMP>, it prints a
-line for each file it encounters that it doesn't know
-about (see section <A HREF="cvs_127.html#SEC134">update output</A>).
-
-</P>
-<P>
-CVS has a list of files (or sh(1) file name patterns)
-that it should ignore while running <CODE>update</CODE>,
-<CODE>import</CODE> and <CODE>release</CODE>.
-This list is constructed in the following way.
-
-</P>
-
-<UL>
-<LI>
-
-The list is initialized to include certain file name
-patterns: names associated with CVS
-administration, or with other common source control
-systems; common names for patch files, object files,
-archive files, and editor backup files; and other names
-that are usually artifacts of assorted utilities.
-Currently, the default list of ignored file name
-patterns is:
-
-<A NAME="IDX402"></A>
-<A NAME="IDX403"></A>
-
-<PRE>
- RCS SCCS CVS CVS.adm
- RCSLOG cvslog.*
- tags TAGS
- .make.state .nse_depinfo
- *~ #* .#* ,* _$* *$
- *.old *.bak *.BAK *.orig *.rej .del-*
- *.a *.olb *.o *.obj *.so *.exe
- *.Z *.elc *.ln
- core
-</PRE>
-
-<LI>
-
-The per-repository list in
-<TT>`$CVSROOT/CVSROOT/cvsignore'</TT> is appended to
-the list, if that file exists.
-
-<LI>
-
-The per-user list in <TT>`.cvsignore'</TT> in your home
-directory is appended to the list, if it exists.
-
-<LI>
-
-Any entries in the environment variable
-<CODE>$CVSIGNORE</CODE> is appended to the list.
-
-<LI>
-
-Any <SAMP>`-I'</SAMP> options given to CVS is appended.
-
-<LI>
-
-As CVS traverses through your directories, the contents
-of any <TT>`.cvsignore'</TT> will be appended to the list.
-The patterns found in <TT>`.cvsignore'</TT> are only valid
-for the directory that contains them, not for
-any sub-directories.
-</UL>
-
-<P>
-In any of the 5 places listed above, a single
-exclamation mark (<SAMP>`!'</SAMP>) clears the ignore list.
-This can be used if you want to store any file which
-normally is ignored by CVS.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_140.html">previous</A>,
<A HREF="cvs_142.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_142.html
===================================================================
RCS file: manual/html_node/cvs_142.html
diff -N manual/html_node/cvs_142.html
--- manual/html_node/cvs_142.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,39 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - history file</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_141.html">previous</A>,
<A HREF="cvs_143.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC149" HREF="cvs_toc.html#TOC149">The history file</A></H2>
-<P>
-<A NAME="IDX404"></A>
-<A NAME="IDX405"></A>
-
-</P>
-<P>
-The file <TT>`$CVSROOT/CVSROOT/history'</TT> is used
-to log information for the <CODE>history</CODE> command
-(see section <A HREF="cvs_103.html#SEC110">history--Show status of files and
users</A>). This file must be created to turn
-on logging. This is done automatically if the
-<CODE>cvs init</CODE> command is used to set up the
-repository (see section <A HREF="cvs_21.html#SEC23">Creating a repository</A>).
-
-</P>
-<P>
-The file format of the <TT>`history'</TT> file is
-documented only in comments in the CVS source
-code, but generally programs should use the <CODE>cvs
-history</CODE> command to access it anyway, in case the
-format changes with future releases of CVS.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_141.html">previous</A>,
<A HREF="cvs_143.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_143.html
===================================================================
RCS file: manual/html_node/cvs_143.html
diff -N manual/html_node/cvs_143.html
--- manual/html_node/cvs_143.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,108 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Variables</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_142.html">previous</A>,
<A HREF="cvs_144.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC150" HREF="cvs_toc.html#TOC150">Expansions in administrative
files</A></H2>
-
-<P>
-Sometimes in writing an administrative file, you might
-want the file to be able to know various things based
-on environment CVS is running in. There are
-several mechanisms to do that.
-
-</P>
-<P>
-To find the home directory of the user running CVS
-(from the <CODE>HOME</CODE> environment variable), use
-<SAMP>`~'</SAMP> followed by <SAMP>`/'</SAMP> or the end of the line.
-Likewise for the home directory of <VAR>user</VAR>, use
-<SAMP>`~<VAR>user</VAR>'</SAMP>. These variables are expanded on
-the server machine, and don't get any resonable
-expansion if pserver (see section <A HREF="cvs_24.html#SEC26">Direct
connection with password authentication</A>)
-is in used; therefore user variables (see below) may be
-a better choice to customize behavior based on the user
-running CVS.
-
-</P>
-<P>
-One may want to know about various pieces of
-information internal to CVS. A CVS internal
-variable has the syntax <CODE>${<VAR>variable</VAR>}</CODE>,
-where <VAR>variable</VAR> starts with a letter and consists
-of alphanumberic characters and <SAMP>`_'</SAMP>. If the
-character following <VAR>variable</VAR> is a
-non-alphanumeric character other than <SAMP>`_'</SAMP>, the
-<SAMP>`{'</SAMP> and <SAMP>`}'</SAMP> can be omitted. The CVS
-internal variables are:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>CVSROOT</CODE>
-<DD>
-This is the value of the CVS root in use.
-See section <A HREF="cvs_14.html#SEC15">The Repository</A>, for a description
of the various
-ways to specify this.
-
-<DT><CODE>RCSBIN</CODE>
-<DD>
-This is the value CVS is using for where to find
-RCS binaries. See section <A HREF="cvs_87.html#SEC89">Global options</A>, for
a
-description of how to specify this.
-
-<DT><CODE>CVSEDITOR</CODE>
-<DD>
-<DT><CODE>VISUAL</CODE>
-<DD>
-<DT><CODE>EDITOR</CODE>
-<DD>
-These all expand to the same value, which is the editor
-that CVS is using. See section <A HREF="cvs_87.html#SEC89">Global
options</A>, for how
-to specify this.
-
-<DT><CODE>USER</CODE>
-<DD>
-Username of the user running CVS (on the CVS
-server machine).
-</DL>
-
-<P>
-If you want to pass a value to the administrative files
-which the user that is running CVS can specify,
-use a user variable. To expand a user variable, the
-administrative file contains
-<CODE>${=<VAR>variable</VAR>}</CODE>. To set a user variable,
-specify the global option <SAMP>`-s'</SAMP> to CVS, with
-argument <CODE><VAR>variable</VAR>=<VAR>value</VAR></CODE>. It may be
-particularly useful to specify this option via
-<TT>`.cvsrc'</TT> (see section <A HREF="cvs_86.html#SEC88">Default options and
the ~/.cvsrc file</A>).
-
-</P>
-<P>
-For example, if you want the administrative file to
-refer to a test directory you might create a user
-variable <CODE>TESTDIR</CODE>. Then if CVS is invoked
-as <CODE>cvs -s TESTDIR=/work/local/tests</CODE>, and the
-administrative file contains <CODE>sh
-${=TESTDIR}/runtests</CODE>, then that string is expanded
-to <CODE>sh /work/local/tests/runtests</CODE>.
-
-</P>
-<P>
-All other strings containing <SAMP>`$'</SAMP> are reserved;
-there is no way to quote a <SAMP>`$'</SAMP> character so that
-<SAMP>`$'</SAMP> represents itself.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_142.html">previous</A>,
<A HREF="cvs_144.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_144.html
===================================================================
RCS file: manual/html_node/cvs_144.html
diff -N manual/html_node/cvs_144.html
--- manual/html_node/cvs_144.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,234 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Environment variables</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_143.html">previous</A>,
<A HREF="cvs_145.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC151" HREF="cvs_toc.html#TOC151">All environment variables
which affect CVS</A></H1>
-<P>
-<A NAME="IDX406"></A>
-<A NAME="IDX407"></A>
-
-</P>
-<P>
-This is a complete list of all environment variables
-that affect CVS.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>$CVSIGNORE</CODE>
-<DD>
-<A NAME="IDX408"></A>
-
-A whitespace-separated list of file name patterns that
-CVS should ignore. See section <A HREF="cvs_141.html#SEC148">Ignoring files
via cvsignore</A>.
-
-<A NAME="IDX409"></A>
-<DT><CODE>$CVSWRAPPERS</CODE>
-<DD>
-A whitespace-separated list of file name patterns that
-CVS should treat as wrappers. See section <A HREF="cvs_131.html#SEC138">The
cvswrappers file</A>.
-
-<A NAME="IDX410"></A>
-<A NAME="IDX411"></A>
-<DT><CODE>$CVSREAD</CODE>
-<DD>
-If this is set, <CODE>checkout</CODE> and <CODE>update</CODE> will
-try hard to make the files in your working directory
-read-only. When this is not set, the default behavior
-is to permit modification of your working files.
-
-<A NAME="IDX412"></A>
-<DT><CODE>$CVSROOT</CODE>
-<DD>
-Should contain the full pathname to the root of the CVS
-source repository (where the RCS history files are
-kept). This information must be available to CVS for
-most commands to execute; if <CODE>$CVSROOT</CODE> is not set,
-or if you wish to override it for one invocation, you
-can supply it on the command line: <SAMP>`cvs -d cvsroot
-cvs_command...'</SAMP> Once you have checked out a working
-directory, CVS stores the appropriate root (in
-the file <TT>`CVS/Root'</TT>), so normally you only need to
-worry about this when initially checking out a working
-directory.
-
-<A NAME="IDX413"></A>
-<A NAME="IDX414"></A>
-<DT><CODE>$EDITOR</CODE>
-<DD>
-<DT><CODE>$CVSEDITOR</CODE>
-<DD>
-Specifies the program to use for recording log messages
-during commit. If not set, the default is
-<SAMP>`/usr/ucb/vi'</SAMP>. <CODE>$CVSEDITOR</CODE> overrides
-<CODE>$EDITOR</CODE>. <CODE>$CVSEDITOR</CODE> does not exist in
-CVS 1.3, but the next release will probably
-include it.
-
-<A NAME="IDX415"></A>
-<DT><CODE>$PATH</CODE>
-<DD>
-If <CODE>$RCSBIN</CODE> is not set, and no path is compiled
-into CVS, it will use <CODE>$PATH</CODE> to try to find all
-programs it uses.
-
-<A NAME="IDX416"></A>
-<DT><CODE>$RCSBIN</CODE>
-<DD>
-This is the value CVS is using for where to find
-RCS binaries. See section <A HREF="cvs_87.html#SEC89">Global options</A>, for
a
-description of how to specify this. If not set, a
-compiled-in value is used, or your <CODE>$PATH</CODE> is searched.
-
-<A NAME="IDX417"></A>
-<DT><CODE>$HOME</CODE>
-<DD>
-<A NAME="IDX418"></A>
-<DT><CODE>$HOMEPATH</CODE>
-<DD>
-Used to locate the directory where the <TT>`.cvsrc'</TT>
-file is searched (<CODE>$HOMEPATH</CODE> is used for Windows-NT).
-see section <A HREF="cvs_86.html#SEC88">Default options and the ~/.cvsrc
file</A>
-
-<A NAME="IDX419"></A>
-<DT><CODE>$CVS_RSH</CODE>
-<DD>
-Specifies the external program which CVS connects with,
-when <CODE>:ext:</CODE> access method is specified.
-see section <A HREF="cvs_23.html#SEC25">Connecting with rsh</A>.
-
-<DT><CODE>$CVS_SERVER</CODE>
-<DD>
-Used in client-server mode when accessing a remote
-repository using RSH. It specifies the name of
-the program to start on the server side when accessing
-a remote repository using RSH. The default value
-is <CODE>cvs</CODE>. see section <A HREF="cvs_23.html#SEC25">Connecting with
rsh</A>
-
-<DT><CODE>$CVS_PASSFILE</CODE>
-<DD>
-Used in client-server mode when accessing the <CODE>cvs
-login server</CODE>. Default value is <TT>`$HOME/.cvspass'</TT>.
-see section <A HREF="cvs_26.html#SEC28">Using the client with password
authentication</A>
-
-<DT><CODE>$CVS_PASSWORD</CODE>
-<DD>
-Used in client-server mode when accessing the <CODE>cvs
-login server</CODE>.
-see section <A HREF="cvs_26.html#SEC28">Using the client with password
authentication</A>
-
-<DT><CODE>$CVS_CLIENT_PORT</CODE>
-<DD>
-Used in client-server mode when accessing the server
-via Kerberos.
-see section <A HREF="cvs_28.html#SEC30">Direct connection with kerberos</A>
-
-<A NAME="IDX420"></A>
-<DT><CODE>$CVS_RCMD_PORT</CODE>
-<DD>
-Used in client-server mode. If set, specifies the port
-number to be used when accessing the RCMD demon on
-the server side. (Currently not used for Unix clients).
-
-<A NAME="IDX421"></A>
-<DT><CODE>$CVS_CLIENT_LOG</CODE>
-<DD>
-Used for debugging only in client-server
-mode. If set, everything send to the server is logged
-into <TT>`<CODE>$CVS_CLIENT_LOG</CODE>.in'</TT> and everything
-send from the server is logged into
-<TT>`<CODE>$CVS_CLIENT_LOG</CODE>.out'</TT>.
-
-<A NAME="IDX422"></A>
-<DT><CODE>$CVS_SERVER_SLEEP</CODE>
-<DD>
-Used only for debugging the server side in
-client-server mode. If set, delays the start of the
-server child process the the specified amount of
-seconds so that you can attach to it with a debugger.
-
-<A NAME="IDX423"></A>
-<DT><CODE>$CVS_IGNORE_REMOTE_ROOT</CODE>
-<DD>
-(What is the purpose of this variable?)
-
-<A NAME="IDX424"></A>
-<DT><CODE>$COMSPEC</CODE>
-<DD>
-Used under OS/2 only. It specifies the name of the
-command interpreter and defaults to CMD.EXE.
-
-<A NAME="IDX425"></A>
-<DT><CODE>$TMPDIR</CODE>
-<DD>
-<A NAME="IDX426"></A>
-<DT><CODE>$TMP</CODE>
-<DD>
-<A NAME="IDX427"></A>
-<DT><CODE>$TEMP</CODE>
-<DD>
-<A NAME="IDX428"></A>
-Directory in which temporary files are located. Those
-parts of CVS which are implemented using RCS
-inspect the above variables in the order they appear
-above and the first value found is taken; if none of
-them are set, a host-dependent default is used,
-typically <TT>`/tmp'</TT>. The CVS server uses
-<CODE>TMPDIR</CODE>. See section <A HREF="cvs_87.html#SEC89">Global
options</A>, for a
-description of how to specify this.
-Some parts of CVS will always use <TT>`/tmp'</TT> (via
-the <CODE>tmpnam</CODE> function provided by the system).
-
-On Windows NT, <CODE>TMP</CODE> is used (via the <CODE>_tempnam</CODE>
-function provided by the system).
-
-The <CODE>patch</CODE> program which is used by the CVS
-client uses <CODE>TMPDIR</CODE>, and if it is not set, uses
-<TT>`/tmp'</TT> (at least with GNU patch 2.1).
-</DL>
-
-<P>
-CVS invokes RCS to perform certain
-operations. The following environment
-variables affect RCS. Note that if you are using
-the client/server CVS, these variables need to be
-set on the server side (which may or not may be
-possible depending on how you are connecting). There
-is probably not any need to set any of them, however.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>$LOGNAME</CODE>
-<DD>
-<A NAME="IDX429"></A>
-
-<A NAME="IDX430"></A>
-<DT><CODE>$USER</CODE>
-<DD>
-If set, they affect who RCS thinks you are. If you
-have trouble checking in files it might be because your
-login name differs from the setting of e.g.
-<CODE>$LOGNAME</CODE>.
-
-<A NAME="IDX431"></A>
-<DT><CODE>$RCSINIT</CODE>
-<DD>
-Options prepended to the argument list, separated by
-spaces. A backslash escapes spaces within an option.
-The <CODE>$RCSINIT</CODE> options are prepended to the
-argument lists of most RCS commands.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_143.html">previous</A>,
<A HREF="cvs_145.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_145.html
===================================================================
RCS file: manual/html_node/cvs_145.html
diff -N manual/html_node/cvs_145.html
--- manual/html_node/cvs_145.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,18 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Troubleshooting</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_144.html">previous</A>,
<A HREF="cvs_146.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC152" HREF="cvs_toc.html#TOC152">Troubleshooting</A></H1>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_144.html">previous</A>,
<A HREF="cvs_146.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_146.html
===================================================================
RCS file: manual/html_node/cvs_146.html
diff -N manual/html_node/cvs_146.html
--- manual/html_node/cvs_146.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,67 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Magic branch numbers</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_145.html">previous</A>,
<A HREF="cvs_147.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC153" HREF="cvs_toc.html#TOC153">Magic branch numbers</A></H2>
-
-<P>
-Externally, branch numbers consist of an odd number of
-dot-separated decimal integers. See section <A
HREF="cvs_7.html#SEC8">Revision numbers</A>. That is not the whole truth,
however. For
-efficiency reasons CVS sometimes inserts an extra 0
-in the second rightmost position (1.2.3 becomes
-1.2.0.3, 8.9.10.11.12 becomes 8.9.10.11.0.12 and so
-on).
-
-</P>
-<P>
-CVS does a pretty good job at hiding these so
-called magic branches, but in a few places the hiding
-is incomplete:
-
-</P>
-
-<UL>
-<LI>
-
-The magic branch number appears in the output from
-<CODE>cvs log</CODE>.
-
-<LI>
-
-You cannot specify a symbolic branch name to <CODE>cvs
-admin</CODE>.
-
-</UL>
-
-<P>
-You can use the <CODE>admin</CODE> command to reassign a
-symbolic name to a branch the way RCS expects it
-to be. If <CODE>R4patches</CODE> is assigned to the branch
-1.4.2 (magic branch number 1.4.0.2) in file
-<TT>`numbers.c'</TT> you can do this:
-
-</P>
-
-<PRE>
-$ cvs admin -NR4patches:1.4.2 numbers.c
-</PRE>
-
-<P>
-It only works if at least one revision is already
-committed on the branch. Be very careful so that you
-do not assign the tag to the wrong number. (There is
-no way to see how the tag was assigned yesterday).
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_145.html">previous</A>,
<A HREF="cvs_147.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_147.html
===================================================================
RCS file: manual/html_node/cvs_147.html
diff -N manual/html_node/cvs_147.html
--- manual/html_node/cvs_147.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,18 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Copying</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_146.html">previous</A>,
<A HREF="cvs_148.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC154" HREF="cvs_toc.html#TOC154">GNU GENERAL PUBLIC
LICENSE</A></H1>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_146.html">previous</A>,
<A HREF="cvs_148.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_148.html
===================================================================
RCS file: manual/html_node/cvs_148.html
diff -N manual/html_node/cvs_148.html
--- manual/html_node/cvs_148.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,602 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Index</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_147.html">previous</A>,
next, last section, <A HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC155" HREF="cvs_toc.html#TOC155">Index</A></H1>
-<P>
-<A NAME="IDX432"></A>
-
-</P>
-<P>
-Jump to:
-<A HREF="#cindex_-">-</A>
--
-<A HREF="#cindex_.">.</A>
--
-<A HREF="#cindex_/">/</A>
--
-<A HREF="#cindex_:">:</A>
--
-<A HREF="#cindex_<"><</A>
--
-<A HREF="#cindex_=">=</A>
--
-<A HREF="#cindex_>">></A>
--
-<A HREF="#cindex__">_</A>
--
-<A HREF="#cindex_a">a</A>
--
-<A HREF="#cindex_b">b</A>
--
-<A HREF="#cindex_c">c</A>
--
-<A HREF="#cindex_d">d</A>
--
-<A HREF="#cindex_e">e</A>
--
-<A HREF="#cindex_f">f</A>
--
-<A HREF="#cindex_g">g</A>
--
-<A HREF="#cindex_h">h</A>
--
-<A HREF="#cindex_i">i</A>
--
-<A HREF="#cindex_j">j</A>
--
-<A HREF="#cindex_k">k</A>
--
-<A HREF="#cindex_l">l</A>
--
-<A HREF="#cindex_m">m</A>
--
-<A HREF="#cindex_n">n</A>
--
-<A HREF="#cindex_o">o</A>
--
-<A HREF="#cindex_p">p</A>
--
-<A HREF="#cindex_r">r</A>
--
-<A HREF="#cindex_s">s</A>
--
-<A HREF="#cindex_t">t</A>
--
-<A HREF="#cindex_u">u</A>
--
-<A HREF="#cindex_v">v</A>
--
-<A HREF="#cindex_w">w</A>
--
-<A HREF="#cindex_z">z</A>
-<P>
-<H2><A NAME="cindex_-">-</A></H2>
-<DIR>
-<LI><A HREF="cvs_54.html#IDX229">-j (merging branches)</A>
-<LI><A HREF="cvs_79.html#IDX286">-k (RCS kflags)</A>
-</DIR>
-<H2><A NAME="cindex_.">.</A></H2>
-<DIR>
-<LI><A HREF="cvs_127.html#IDX356">.# files</A>
-<LI><A HREF="cvs_15.html#IDX66">.bashrc, setting CVSROOT in</A>
-<LI><A HREF="cvs_15.html#IDX64">.cshrc, setting CVSROOT in</A>
-<LI><A HREF="cvs_86.html#IDX300">.cvsrc file</A>
-<LI><A HREF="cvs_15.html#IDX63">.profile, setting CVSROOT in</A>
-<LI><A HREF="cvs_15.html#IDX65">.tcshrc, setting CVSROOT in</A>
-</DIR>
-<H2><A NAME="cindex_/">/</A></H2>
-<DIR>
-<LI><A HREF="cvs_14.html#IDX60">/usr/local/cvsroot, as example repository</A>
-</DIR>
-<H2><A NAME="cindex_:">:</A></H2>
-<DIR>
-<LI><A HREF="cvs_23.html#IDX101">:ext:</A>
-<LI><A HREF="cvs_28.html#IDX114">:kserver:</A>
-<LI><A HREF="cvs_14.html#IDX62">:local:</A>
-<LI><A HREF="cvs_26.html#IDX110">:pserver:</A>
-<LI><A HREF="cvs_23.html#IDX100">:server:</A>
-</DIR>
-<H2><A NAME="cindex_<"><</A></H2>
-<DIR>
-<LI><A HREF="cvs_38.html#IDX157"><<<<<<<</A>
-</DIR>
-<H2><A NAME="cindex_=">=</A></H2>
-<DIR>
-<LI><A HREF="cvs_38.html#IDX159">=======</A>
-</DIR>
-<H2><A NAME="cindex_>">></A></H2>
-<DIR>
-<LI><A HREF="cvs_38.html#IDX158">>>>>>>></A>
-</DIR>
-<H2><A NAME="cindex__">_</A></H2>
-<DIR>
-<LI><A HREF="cvs_127.html#IDX357">__ files (VMS)</A>
-</DIR>
-<H2><A NAME="cindex_a">a</A></H2>
-<DIR>
-<LI><A HREF="cvs_9.html#IDX35">A sample session</A>
-<LI><A HREF="cvs_44.html#IDX185">abandoning work</A>
-<LI><A HREF="cvs_1.html#IDX2">About this manual</A>
-<LI><A HREF="cvs_59.html#IDX244">add (subcommand)</A>
-<LI><A HREF="cvs_49.html#IDX203">Adding a tag</A>
-<LI><A HREF="cvs_59.html#IDX243">Adding files</A>
-<LI><A HREF="cvs_89.html#IDX328">Admin (subcommand)</A>
-<LI><A HREF="cvs_19.html#IDX79">Administrative files (intro)</A>
-<LI><A HREF="cvs_129.html#IDX358">Administrative files (reference)</A>
-<LI><A HREF="cvs_19.html#IDX84">Administrative files, editing them</A>
-<LI><A HREF="cvs_134.html#IDX382">ALL in commitinfo</A>
-<LI><A HREF="cvs_74.html#IDX267">annotate (subcommand)</A>
-<LI><A HREF="cvs_40.html#IDX167">Atomic transactions, lack of</A>
-<LI><A HREF="cvs_26.html#IDX109">authenticated client, using</A>
-<LI><A HREF="cvs_25.html#IDX104">authenticating server, setting up</A>
-<LI><A HREF="cvs_76.html#IDX273">Author keyword</A>
-<LI><A HREF="cvs_141.html#IDX403">Automatically ignored files</A>
-<LI><A HREF="cvs_88.html#IDX327">Avoiding editor invocation</A>
-</DIR>
-<H2><A NAME="cindex_b">b</A></H2>
-<DIR>
-<LI><A HREF="cvs_81.html#IDX288">Binary files</A>
-<LI><A HREF="cvs_54.html#IDX231">Branch merge example</A>
-<LI><A HREF="cvs_7.html#IDX30">Branch number</A>
-<LI><A HREF="cvs_51.html#IDX213">Branch numbers</A>
-<LI><A HREF="cvs_51.html#IDX211">Branch, creating a</A>
-<LI><A HREF="cvs_61.html#IDX254">Branch, vendor-</A>
-<LI><A HREF="cvs_48.html#IDX194">Branches</A>
-<LI><A HREF="cvs_50.html#IDX207">Branches motivation</A>
-<LI><A HREF="cvs_53.html#IDX225">Branches, copying changes between</A>
-<LI><A HREF="cvs_52.html#IDX216">Branches, sticky</A>
-<LI><A HREF="cvs_37.html#IDX146">Bringing a file up to date</A>
-<LI><A HREF="cvs_4.html#IDX7">Bugs, known in this manual</A>
-<LI><A HREF="cvs_4.html#IDX10">Bugs, reporting (manual)</A>
-</DIR>
-<H2><A NAME="cindex_c">c</A></H2>
-<DIR>
-<LI><A HREF="cvs_53.html#IDX226">Changes, copying between branches</A>
-<LI><A HREF="cvs_90.html#IDX329">Changing a log message</A>
-<LI><A HREF="cvs_139.html#IDX394">checked out copy, keeping</A>
-<LI><A HREF="cvs_130.html#IDX365">Checkin program</A>
-<LI><A HREF="cvs_134.html#IDX379">Checking commits</A>
-<LI><A HREF="cvs_10.html#IDX42">Checking out source</A>
-<LI><A HREF="cvs_92.html#IDX340">Checkout (subcommand)</A>
-<LI><A HREF="cvs_130.html#IDX366">Checkout program</A>
-<LI><A HREF="cvs_44.html#IDX181">checkout, as term for getting ready to
edit</A>
-<LI><A HREF="cvs_10.html#IDX45">Checkout, example</A>
-<LI><A HREF="cvs_47.html#IDX193">choosing, reserved or unreserved checkouts</A>
-<LI><A HREF="cvs_12.html#IDX50">Cleaning up</A>
-<LI><A HREF="cvs_22.html#IDX97">Client/Server Operation</A>
-<LI><A HREF="cvs_92.html#IDX341">Co (subcommand)</A>
-<LI><A HREF="cvs_84.html#IDX293">Command reference</A>
-<LI><A HREF="cvs_85.html#IDX298">Command structure</A>
-<LI><A HREF="cvs_91.html#IDX337">Comment leader</A>
-<LI><A HREF="cvs_95.html#IDX342">Commit (subcommand)</A>
-<LI><A HREF="cvs_132.html#IDX374">Commit files</A>
-<LI><A HREF="cvs_83.html#IDX291">Commit, when to</A>
-<LI><A HREF="cvs_134.html#IDX378">Commitinfo</A>
-<LI><A HREF="cvs_11.html#IDX46">Committing changes</A>
-<LI><A HREF="cvs_88.html#IDX318">Common options</A>
-<LI><A HREF="cvs_133.html#IDX377">Common syntax of info files</A>
-<LI><A HREF="cvs_144.html#IDX424">COMSPEC</A>
-<LI><A HREF="cvs_38.html#IDX156">Conflict markers</A>
-<LI><A HREF="cvs_38.html#IDX161">Conflict resolution</A>
-<LI><A HREF="cvs_38.html#IDX154">Conflicts (merge example)</A>
-<LI><A HREF="cvs_5.html#IDX18">Contributors (CVS program)</A>
-<LI><A HREF="cvs_3.html#IDX5">Contributors (manual)</A>
-<LI><A HREF="cvs_53.html#IDX224">Copying changes</A>
-<LI><A HREF="cvs_90.html#IDX331">Correcting a log message</A>
-<LI><A HREF="cvs_51.html#IDX210">Creating a branch</A>
-<LI><A HREF="cvs_29.html#IDX118">Creating a project</A>
-<LI><A HREF="cvs_21.html#IDX92">Creating a repository</A>
-<LI><A HREF="cvs_5.html#IDX17">Credits (CVS program)</A>
-<LI><A HREF="cvs_3.html#IDX6">Credits (manual)</A>
-<LI><A HREF="cvs_46.html#IDX192">CVS 1.6, and watches</A>
-<LI><A HREF="cvs_85.html#IDX297">CVS command structure</A>
-<LI><A HREF="cvs_25.html#IDX105">CVS passwd file</A>
-<LI><A HREF="cvs_5.html#IDX16">CVS, history of</A>
-<LI><A HREF="cvs_5.html#IDX14">CVS, introduction to</A>
-<LI><A HREF="cvs_144.html#IDX421">CVS_CLIENT_LOG</A>
-<LI><A HREF="cvs_28.html#IDX115">CVS_CLIENT_PORT</A>
-<LI><A HREF="cvs_144.html#IDX423">CVS_IGNORE_REMOTE_ROOT</A>
-<LI><A HREF="cvs_26.html#IDX111">CVS_PASSFILE, environment variable</A>
-<LI><A HREF="cvs_26.html#IDX112">CVS_PASSWORD, environment variable</A>
-<LI><A HREF="cvs_144.html#IDX420">CVS_RCMD_PORT</A>
-<LI><A HREF="cvs_144.html#IDX419">CVS_RSH</A>
-<LI><A HREF="cvs_23.html#IDX99">CVS_SERVER</A>
-<LI><A HREF="cvs_144.html#IDX422">CVS_SERVER_SLEEP</A>
-<LI><A HREF="cvs_144.html#IDX414">CVSEDITOR</A>
-<LI><A HREF="cvs_11.html#IDX48">CVSEDITOR, environment variable</A>
-<LI><A HREF="cvs_144.html#IDX408">CVSIGNORE</A>
-<LI><A HREF="cvs_141.html#IDX399">cvsignore (admin file), global</A>
-<LI><A HREF="cvs_144.html#IDX410">CVSREAD</A>
-<LI><A HREF="cvs_87.html#IDX316">CVSREAD, overriding</A>
-<LI><A HREF="cvs_144.html#IDX412">CVSROOT</A>
-<LI><A HREF="cvs_14.html#IDX61">cvsroot</A>
-<LI><A HREF="cvs_129.html#IDX361">CVSROOT (file)</A>
-<LI><A HREF="cvs_15.html#IDX67">CVSROOT, environment variable</A>
-<LI><A HREF="cvs_19.html#IDX81">CVSROOT, module name</A>
-<LI><A HREF="cvs_20.html#IDX90">CVSROOT, multiple repositories</A>
-<LI><A HREF="cvs_87.html#IDX309">CVSROOT, overriding</A>
-<LI><A HREF="cvs_18.html#IDX75">CVSUMASK</A>
-<LI><A HREF="cvs_144.html#IDX409">CVSWRAPPERS</A>
-<LI><A HREF="cvs_131.html#IDX371">cvswrappers (admin file)</A>
-<LI><A HREF="cvs_131.html#IDX372">CVSWRAPPERS, environment variable</A>
-</DIR>
-<H2><A NAME="cindex_d">d</A></H2>
-<DIR>
-<LI><A HREF="cvs_76.html#IDX274">Date keyword</A>
-<LI><A HREF="cvs_88.html#IDX320">Dates</A>
-<LI><A HREF="cvs_7.html#IDX28">Decimal revision number</A>
-<LI><A HREF="cvs_134.html#IDX381">DEFAULT in commitinfo</A>
-<LI><A HREF="cvs_135.html#IDX387">DEFAULT in editinfo</A>
-<LI><A HREF="cvs_34.html#IDX123">Defining a module</A>
-<LI><A HREF="cvs_19.html#IDX82">Defining modules (intro)</A>
-<LI><A HREF="cvs_130.html#IDX363">Defining modules (reference manual)</A>
-<LI><A HREF="cvs_60.html#IDX247">Deleting files</A>
-<LI><A HREF="cvs_90.html#IDX334">Deleting revisions</A>
-<LI><A HREF="cvs_52.html#IDX219">Deleting sticky tags</A>
-<LI><A HREF="cvs_58.html#IDX241">Descending directories</A>
-<LI><A HREF="cvs_13.html#IDX55">Diff</A>
-<LI><A HREF="cvs_98.html#IDX343">Diff (subcommand)</A>
-<LI><A HREF="cvs_56.html#IDX236">Differences, merging</A>
-<LI><A HREF="cvs_69.html#IDX262">Directories, moving</A>
-<LI><A HREF="cvs_58.html#IDX240">Directory, descending</A>
-<LI><A HREF="cvs_20.html#IDX89">Disjoint repositories</A>
-<LI><A HREF="cvs_137.html#IDX391">Distributing log messages</A>
-<LI><A HREF="cvs_38.html#IDX153">driver.c (merge example)</A>
-</DIR>
-<H2><A NAME="cindex_e">e</A></H2>
-<DIR>
-<LI><A HREF="cvs_44.html#IDX182">edit (subcommand)</A>
-<LI><A HREF="cvs_135.html#IDX383">editinfo (admin file)</A>
-<LI><A HREF="cvs_19.html#IDX83">Editing administrative files</A>
-<LI><A HREF="cvs_34.html#IDX124">Editing the modules file</A>
-<LI><A HREF="cvs_144.html#IDX413">EDITOR</A>
-<LI><A HREF="cvs_88.html#IDX326">Editor, avoiding invocation of</A>
-<LI><A HREF="cvs_11.html#IDX49">EDITOR, environment variable</A>
-<LI><A HREF="cvs_87.html#IDX311">EDITOR, overriding</A>
-<LI><A HREF="cvs_135.html#IDX384">Editor, specifying per module</A>
-<LI><A HREF="cvs_45.html#IDX190">editors (subcommand)</A>
-<LI><A HREF="cvs_38.html#IDX162">emerge</A>
-<LI><A HREF="cvs_144.html#IDX406">Environment variables</A>
-<LI><A HREF="cvs_4.html#IDX11">Errors, reporting (manual)</A>
-<LI><A HREF="cvs_9.html#IDX36">Example of a work-session</A>
-<LI><A HREF="cvs_38.html#IDX152">Example of merge</A>
-<LI><A HREF="cvs_54.html#IDX232">Example, branch merge</A>
-<LI><A HREF="cvs_101.html#IDX344">Export (subcommand)</A>
-<LI><A HREF="cvs_130.html#IDX364">Export program</A>
-</DIR>
-<H2><A NAME="cindex_f">f</A></H2>
-<DIR>
-<LI><A HREF="cvs_10.html#IDX43">Fetching source</A>
-<LI><A HREF="cvs_35.html#IDX129">File locking</A>
-<LI><A HREF="cvs_18.html#IDX72">File permissions</A>
-<LI><A HREF="cvs_36.html#IDX135">File status</A>
-<LI><A HREF="cvs_65.html#IDX259">Files, moving</A>
-<LI><A HREF="cvs_129.html#IDX359">Files, reference manual</A>
-<LI><A HREF="cvs_90.html#IDX332">Fixing a log message</A>
-<LI><A HREF="cvs_88.html#IDX325">Forcing a tag match</A>
-<LI><A HREF="cvs_140.html#IDX396">Form for log message</A>
-<LI><A HREF="cvs_85.html#IDX299">Format of CVS commands</A>
-</DIR>
-<H2><A NAME="cindex_g">g</A></H2>
-<DIR>
-<LI><A HREF="cvs_9.html#IDX37">Getting started</A>
-<LI><A HREF="cvs_10.html#IDX41">Getting the source</A>
-<LI><A HREF="cvs_141.html#IDX400">Global cvsignore</A>
-<LI><A HREF="cvs_87.html#IDX303">Global options</A>
-<LI><A HREF="cvs_18.html#IDX73">Group</A>
-</DIR>
-<H2><A NAME="cindex_h">h</A></H2>
-<DIR>
-<LI><A HREF="cvs_76.html#IDX275">Header keyword</A>
-<LI><A HREF="cvs_103.html#IDX345">History (subcommand)</A>
-<LI><A HREF="cvs_70.html#IDX263">History browsing</A>
-<LI><A HREF="cvs_142.html#IDX404">History file</A>
-<LI><A HREF="cvs_17.html#IDX69">History files</A>
-<LI><A HREF="cvs_5.html#IDX15">History of CVS</A>
-<LI><A HREF="cvs_144.html#IDX417">HOME</A>
-<LI><A HREF="cvs_144.html#IDX418">HOMEPATH</A>
-</DIR>
-<H2><A NAME="cindex_i">i</A></H2>
-<DIR>
-<LI><A HREF="cvs_76.html#IDX276">Id keyword</A>
-<LI><A HREF="cvs_77.html#IDX284">Ident (shell command)</A>
-<LI><A HREF="cvs_75.html#IDX271">Identifying files</A>
-<LI><A HREF="cvs_141.html#IDX402">Ignored files</A>
-<LI><A HREF="cvs_141.html#IDX401">Ignoring files</A>
-<LI><A HREF="cvs_105.html#IDX346">Import (subcommand)</A>
-<LI><A HREF="cvs_31.html#IDX119">Importing files</A>
-<LI><A HREF="cvs_32.html#IDX120">Importing files, from other version control
systesm</A>
-<LI><A HREF="cvs_62.html#IDX255">Importing modules</A>
-<LI><A HREF="cvs_148.html#IDX432">Index</A>
-<LI><A HREF="cvs_133.html#IDX375">Info files (syntax)</A>
-<LI><A HREF="cvs_39.html#IDX163">Informing others</A>
-<LI><A HREF="cvs_21.html#IDX94">init (subcommand)</A>
-<LI><A HREF="cvs_5.html#IDX13">Introduction to CVS</A>
-<LI><A HREF="cvs_84.html#IDX295">Invoking CVS</A>
-<LI><A HREF="cvs_70.html#IDX265">Isolation</A>
-</DIR>
-<H2><A NAME="cindex_j">j</A></H2>
-<DIR>
-<LI><A HREF="cvs_54.html#IDX230">Join</A>
-</DIR>
-<H2><A NAME="cindex_k">k</A></H2>
-<DIR>
-<LI><A HREF="cvs_139.html#IDX393">keeping a checked out copy</A>
-<LI><A HREF="cvs_28.html#IDX113">kerberos</A>
-<LI><A HREF="cvs_75.html#IDX270">Keyword expansion</A>
-<LI><A HREF="cvs_75.html#IDX269">Keyword substitution</A>
-<LI><A HREF="cvs_79.html#IDX287">Kflag</A>
-<LI><A HREF="cvs_28.html#IDX116">kinit</A>
-<LI><A HREF="cvs_4.html#IDX8">Known bugs in this manual</A>
-</DIR>
-<H2><A NAME="cindex_l">l</A></H2>
-<DIR>
-<LI><A HREF="cvs_14.html#IDX58">Layout of repository</A>
-<LI><A HREF="cvs_87.html#IDX304">Left-hand options</A>
-<LI><A HREF="cvs_7.html#IDX26">Linear development</A>
-<LI><A HREF="cvs_5.html#IDX21">List, mailing list</A>
-<LI><A HREF="cvs_36.html#IDX139">Locally Added</A>
-<LI><A HREF="cvs_36.html#IDX138">Locally Modified</A>
-<LI><A HREF="cvs_36.html#IDX140">Locally Removed</A>
-<LI><A HREF="cvs_76.html#IDX278">Locker keyword</A>
-<LI><A HREF="cvs_35.html#IDX130">Locking files</A>
-<LI><A HREF="cvs_40.html#IDX166">locks, cvs</A>
-<LI><A HREF="cvs_109.html#IDX347">Log (subcommand)</A>
-<LI><A HREF="cvs_142.html#IDX405">Log information, saving</A>
-<LI><A HREF="cvs_76.html#IDX279">Log keyword</A>
-<LI><A HREF="cvs_91.html#IDX338">Log keyword, selecting comment leader</A>
-<LI><A HREF="cvs_11.html#IDX47">Log message entry</A>
-<LI><A HREF="cvs_140.html#IDX397">Log message template</A>
-<LI><A HREF="cvs_90.html#IDX333">Log message, correcting</A>
-<LI><A HREF="cvs_137.html#IDX392">Log messages</A>
-<LI><A HREF="cvs_135.html#IDX386">Log messages, editing</A>
-<LI><A HREF="cvs_26.html#IDX107">Login (subcommand)</A>
-<LI><A HREF="cvs_137.html#IDX388">loginfo (admin file)</A>
-<LI><A HREF="cvs_144.html#IDX429">LOGNAME</A>
-</DIR>
-<H2><A NAME="cindex_m">m</A></H2>
-<DIR>
-<LI><A HREF="cvs_39.html#IDX165">Mail, automatic mail on commit</A>
-<LI><A HREF="cvs_5.html#IDX20">Mailing list</A>
-<LI><A HREF="cvs_137.html#IDX390">Mailing log messages</A>
-<LI><A HREF="cvs_7.html#IDX29">Main trunk (intro)</A>
-<LI><A HREF="cvs_48.html#IDX195">Main trunk and branches</A>
-<LI><A HREF="cvs_20.html#IDX87">Many repositories</A>
-<LI><A HREF="cvs_38.html#IDX155">Markers, conflict</A>
-<LI><A HREF="cvs_38.html#IDX151">Merge, an example</A>
-<LI><A HREF="cvs_54.html#IDX233">Merge, branch example</A>
-<LI><A HREF="cvs_53.html#IDX223">Merging</A>
-<LI><A HREF="cvs_54.html#IDX228">Merging a branch</A>
-<LI><A HREF="cvs_37.html#IDX148">Merging a file</A>
-<LI><A HREF="cvs_56.html#IDX234">Merging two revisions</A>
-<LI><A HREF="cvs_53.html#IDX227">Modifications, copying between branches</A>
-<LI><A HREF="cvs_130.html#IDX368">Module status</A>
-<LI><A HREF="cvs_34.html#IDX125">Module, defining</A>
-<LI><A HREF="cvs_130.html#IDX362">Modules (admin file)</A>
-<LI><A HREF="cvs_6.html#IDX23">Modules (intro)</A>
-<LI><A HREF="cvs_19.html#IDX80">Modules file</A>
-<LI><A HREF="cvs_34.html#IDX126">Modules file, changing</A>
-<LI><A HREF="cvs_50.html#IDX209">Motivation for branches</A>
-<LI><A HREF="cvs_69.html#IDX260">Moving directories</A>
-<LI><A HREF="cvs_65.html#IDX257">Moving files</A>
-<LI><A HREF="cvs_35.html#IDX127">Multiple developers</A>
-<LI><A HREF="cvs_20.html#IDX85">Multiple repositories</A>
-</DIR>
-<H2><A NAME="cindex_n">n</A></H2>
-<DIR>
-<LI><A HREF="cvs_76.html#IDX277">Name keyword</A>
-<LI><A HREF="cvs_49.html#IDX202">Name, symbolic (tag)</A>
-<LI><A HREF="cvs_36.html#IDX141">Needs Checkout</A>
-<LI><A HREF="cvs_36.html#IDX143">Needs Merge</A>
-<LI><A HREF="cvs_36.html#IDX142">Needs Patch</A>
-<LI><A HREF="cvs_5.html#IDX22">Newsgroups</A>
-<LI><A HREF="cvs_43.html#IDX179">notify (admin file)</A>
-<LI><A HREF="cvs_91.html#IDX339">Nroff (selecting comment leader)</A>
-<LI><A HREF="cvs_7.html#IDX31">Number, branch</A>
-<LI><A HREF="cvs_7.html#IDX27">Number, revision-</A>
-</DIR>
-<H2><A NAME="cindex_o">o</A></H2>
-<DIR>
-<LI><A HREF="cvs_86.html#IDX301">option defaults</A>
-<LI><A HREF="cvs_87.html#IDX302">Options, global</A>
-<LI><A HREF="cvs_90.html#IDX335">Outdating revisions</A>
-<LI><A HREF="cvs_37.html#IDX150">Overlap</A>
-<LI><A HREF="cvs_87.html#IDX317">Overriding CVSREAD</A>
-<LI><A HREF="cvs_87.html#IDX310">Overriding CVSROOT</A>
-<LI><A HREF="cvs_87.html#IDX312">Overriding EDITOR</A>
-<LI><A HREF="cvs_87.html#IDX306">Overriding RCSBIN</A>
-<LI><A HREF="cvs_87.html#IDX308">Overriding TMPDIR</A>
-</DIR>
-<H2><A NAME="cindex_p">p</A></H2>
-<DIR>
-<LI><A HREF="cvs_20.html#IDX88">Parallel repositories</A>
-<LI><A HREF="cvs_25.html#IDX106">passwd (admin file)</A>
-<LI><A HREF="cvs_26.html#IDX108">password client, using</A>
-<LI><A HREF="cvs_25.html#IDX103">password server, setting up</A>
-<LI><A HREF="cvs_144.html#IDX415">PATH</A>
-<LI><A HREF="cvs_135.html#IDX385">Per-module editor</A>
-<LI><A HREF="cvs_83.html#IDX292">Policy</A>
-<LI><A HREF="cvs_134.html#IDX380">Precommit checking</A>
-<LI><A HREF="cvs_1.html#IDX1">Preface</A>
-<LI><A HREF="cvs_25.html#IDX102">Pserver (subcommand)</A>
-</DIR>
-<H2><A NAME="cindex_r">r</A></H2>
-<DIR>
-<LI><A HREF="cvs_17.html#IDX70">RCS history files</A>
-<LI><A HREF="cvs_76.html#IDX272">RCS keywords</A>
-<LI><A HREF="cvs_49.html#IDX198">RCS revision numbers</A>
-<LI><A HREF="cvs_32.html#IDX121">RCS, importing files from</A>
-<LI><A HREF="cvs_35.html#IDX134">RCS-style locking</A>
-<LI><A HREF="cvs_144.html#IDX416">RCSBIN</A>
-<LI><A HREF="cvs_87.html#IDX305">RCSBIN, overriding</A>
-<LI><A HREF="cvs_76.html#IDX280">RCSfile keyword</A>
-<LI><A HREF="cvs_140.html#IDX395">rcsinfo (admin file)</A>
-<LI><A HREF="cvs_144.html#IDX431">RCSINIT</A>
-<LI><A HREF="cvs_112.html#IDX350">Rdiff (subcommand)</A>
-<LI><A HREF="cvs_87.html#IDX314">read-only files, and -r</A>
-<LI><A HREF="cvs_144.html#IDX411">read-only files, and CVSREAD</A>
-<LI><A HREF="cvs_42.html#IDX172">read-only files, and watches</A>
-<LI><A HREF="cvs_18.html#IDX74">read-only files, in repository</A>
-<LI><A HREF="cvs_87.html#IDX313">Read-only mode</A>
-<LI><A HREF="cvs_58.html#IDX239">Recursive (directory descending)</A>
-<LI><A HREF="cvs_129.html#IDX360">Reference manual (files)</A>
-<LI><A HREF="cvs_144.html#IDX407">Reference manual for variables</A>
-<LI><A HREF="cvs_84.html#IDX294">Reference, commands</A>
-<LI><A HREF="cvs_115.html#IDX351">Release (subcommand)</A>
-<LI><A HREF="cvs_8.html#IDX34">Releases, revisions and versions</A>
-<LI><A HREF="cvs_12.html#IDX53">Releasing your working copy</A>
-<LI><A HREF="cvs_22.html#IDX96">Remote repositories</A>
-<LI><A HREF="cvs_60.html#IDX248">Remove (subcommand)</A>
-<LI><A HREF="cvs_56.html#IDX238">Removing a change</A>
-<LI><A HREF="cvs_60.html#IDX246">Removing files</A>
-<LI><A HREF="cvs_12.html#IDX52">Removing your working copy</A>
-<LI><A HREF="cvs_69.html#IDX261">Renaming directories</A>
-<LI><A HREF="cvs_65.html#IDX258">Renaming files</A>
-<LI><A HREF="cvs_90.html#IDX330">Replacing a log message</A>
-<LI><A HREF="cvs_4.html#IDX9">Reporting bugs (manual)</A>
-<LI><A HREF="cvs_20.html#IDX86">Repositories, multiple</A>
-<LI><A HREF="cvs_22.html#IDX95">Repositories, remote</A>
-<LI><A HREF="cvs_14.html#IDX56">Repository (intro)</A>
-<LI><A HREF="cvs_14.html#IDX57">Repository, example</A>
-<LI><A HREF="cvs_16.html#IDX68">Repository, how data is stored</A>
-<LI><A HREF="cvs_21.html#IDX91">Repository, setting up</A>
-<LI><A HREF="cvs_35.html#IDX132">reserved checkouts</A>
-<LI><A HREF="cvs_52.html#IDX217">Resetting sticky tags</A>
-<LI><A HREF="cvs_38.html#IDX160">Resolving a conflict</A>
-<LI><A HREF="cvs_52.html#IDX221">Restoring old version of removed file</A>
-<LI><A HREF="cvs_52.html#IDX222">Resurrecting old version of dead file</A>
-<LI><A HREF="cvs_49.html#IDX205">Retrieving an old revision using tags</A>
-<LI><A HREF="cvs_44.html#IDX186">reverting to repository version</A>
-<LI><A HREF="cvs_76.html#IDX281">Revision keyword</A>
-<LI><A HREF="cvs_82.html#IDX289">Revision management</A>
-<LI><A HREF="cvs_7.html#IDX24">Revision numbers</A>
-<LI><A HREF="cvs_7.html#IDX25">Revision tree</A>
-<LI><A HREF="cvs_48.html#IDX196">Revision tree, making branches</A>
-<LI><A HREF="cvs_56.html#IDX235">Revisions, merging differences between</A>
-<LI><A HREF="cvs_8.html#IDX32">Revisions, versions and releases</A>
-<LI><A HREF="cvs_88.html#IDX319">Right-hand options</A>
-<LI><A HREF="cvs_23.html#IDX98">rsh</A>
-<LI><A HREF="cvs_119.html#IDX352">Rtag (subcommand)</A>
-<LI><A HREF="cvs_51.html#IDX212">rtag, creating a branch using</A>
-</DIR>
-<H2><A NAME="cindex_s">s</A></H2>
-<DIR>
-<LI><A HREF="cvs_90.html#IDX336">Saving space</A>
-<LI><A HREF="cvs_32.html#IDX122">SCCS, importing files from</A>
-<LI><A HREF="cvs_18.html#IDX71">Security</A>
-<LI><A HREF="cvs_18.html#IDX78">setgid</A>
-<LI><A HREF="cvs_21.html#IDX93">Setting up a repository</A>
-<LI><A HREF="cvs_18.html#IDX77">setuid</A>
-<LI><A HREF="cvs_1.html#IDX3">Signum Support</A>
-<LI><A HREF="cvs_76.html#IDX282">Source keyword</A>
-<LI><A HREF="cvs_5.html#IDX19">Source, getting CVS source</A>
-<LI><A HREF="cvs_10.html#IDX44">Source, getting from CVS</A>
-<LI><A HREF="cvs_88.html#IDX322">Specifying dates</A>
-<LI><A HREF="cvs_39.html#IDX164">Spreading information</A>
-<LI><A HREF="cvs_29.html#IDX117">Starting a project with CVS</A>
-<LI><A HREF="cvs_76.html#IDX283">State keyword</A>
-<LI><A HREF="cvs_121.html#IDX353">Status (subcommand)</A>
-<LI><A HREF="cvs_36.html#IDX136">Status of a file</A>
-<LI><A HREF="cvs_130.html#IDX367">Status of a module</A>
-<LI><A HREF="cvs_52.html#IDX220">sticky date</A>
-<LI><A HREF="cvs_52.html#IDX214">Sticky tags</A>
-<LI><A HREF="cvs_52.html#IDX218">Sticky tags, resetting</A>
-<LI><A HREF="cvs_137.html#IDX389">Storing log messages</A>
-<LI><A HREF="cvs_85.html#IDX296">Structure</A>
-<LI><A HREF="cvs_58.html#IDX242">Subdirectories</A>
-<LI><A HREF="cvs_1.html#IDX4">Support, getting CVS support</A>
-<LI><A HREF="cvs_49.html#IDX201">Symbolic name (tag)</A>
-<LI><A HREF="cvs_133.html#IDX376">Syntax of info files</A>
-</DIR>
-<H2><A NAME="cindex_t">t</A></H2>
-<DIR>
-<LI><A HREF="cvs_123.html#IDX354">Tag (subcommand)</A>
-<LI><A HREF="cvs_130.html#IDX369">Tag program</A>
-<LI><A HREF="cvs_49.html#IDX199">tag, command, introduction</A>
-<LI><A HREF="cvs_49.html#IDX204">tag, example</A>
-<LI><A HREF="cvs_49.html#IDX206">Tag, retrieving old revisions</A>
-<LI><A HREF="cvs_49.html#IDX200">Tag, symbolic name</A>
-<LI><A HREF="cvs_73.html#IDX266">taginfo</A>
-<LI><A HREF="cvs_49.html#IDX197">Tags</A>
-<LI><A HREF="cvs_52.html#IDX215">Tags, sticky</A>
-<LI><A HREF="cvs_9.html#IDX39">tc, Trivial Compiler (example)</A>
-<LI><A HREF="cvs_35.html#IDX128">Team of developers</A>
-<LI><A HREF="cvs_144.html#IDX427">TEMP</A>
-<LI><A HREF="cvs_140.html#IDX398">Template for log message</A>
-<LI><A HREF="cvs_144.html#IDX428">temporary files, location of</A>
-<LI><A HREF="cvs_61.html#IDX250">Third-party sources</A>
-<LI><A HREF="cvs_88.html#IDX321">Time</A>
-<LI><A HREF="cvs_88.html#IDX323">timezone, in input</A>
-<LI><A HREF="cvs_109.html#IDX348">timezone, in output</A>
-<LI><A HREF="cvs_144.html#IDX426">TMP</A>
-<LI><A HREF="cvs_144.html#IDX425">TMPDIR</A>
-<LI><A HREF="cvs_87.html#IDX307">TMPDIR, overriding</A>
-<LI><A HREF="cvs_87.html#IDX315">Trace</A>
-<LI><A HREF="cvs_70.html#IDX264">Traceability</A>
-<LI><A HREF="cvs_61.html#IDX251">Tracking sources</A>
-<LI><A HREF="cvs_40.html#IDX168">Transactions, atomic, lack of</A>
-<LI><A HREF="cvs_9.html#IDX40">Trivial Compiler (example)</A>
-<LI><A HREF="cvs_14.html#IDX59">Typical repository</A>
-</DIR>
-<H2><A NAME="cindex_u">u</A></H2>
-<DIR>
-<LI><A HREF="cvs_18.html#IDX76">umask, for repository files</A>
-<LI><A HREF="cvs_56.html#IDX237">Undoing a change</A>
-<LI><A HREF="cvs_44.html#IDX184">unedit (subcommand)</A>
-<LI><A HREF="cvs_36.html#IDX145">Unknown</A>
-<LI><A HREF="cvs_35.html#IDX133">unreserved checkouts</A>
-<LI><A HREF="cvs_36.html#IDX144">Unresolved Conflict</A>
-<LI><A HREF="cvs_36.html#IDX137">Up-to-date</A>
-<LI><A HREF="cvs_125.html#IDX355">Update (subcommand)</A>
-<LI><A HREF="cvs_130.html#IDX370">Update program</A>
-<LI><A HREF="cvs_37.html#IDX149">update, introduction</A>
-<LI><A HREF="cvs_37.html#IDX147">Updating a file</A>
-<LI><A HREF="cvs_144.html#IDX430">USER</A>
-<LI><A HREF="cvs_43.html#IDX180">users (admin file)</A>
-</DIR>
-<H2><A NAME="cindex_v">v</A></H2>
-<DIR>
-<LI><A HREF="cvs_61.html#IDX252">Vendor</A>
-<LI><A HREF="cvs_61.html#IDX253">Vendor branch</A>
-<LI><A HREF="cvs_8.html#IDX33">Versions, revisions and releases</A>
-<LI><A HREF="cvs_13.html#IDX54">Viewing differences</A>
-</DIR>
-<H2><A NAME="cindex_w">w</A></H2>
-<DIR>
-<LI><A HREF="cvs_43.html#IDX175">watch add (subcommand)</A>
-<LI><A HREF="cvs_42.html#IDX173">watch off (subcommand)</A>
-<LI><A HREF="cvs_42.html#IDX170">watch on (subcommand)</A>
-<LI><A HREF="cvs_43.html#IDX177">watch remove (subcommand)</A>
-<LI><A HREF="cvs_45.html#IDX188">watchers (subcommand)</A>
-<LI><A HREF="cvs_41.html#IDX169">Watches</A>
-<LI><A HREF="cvs_62.html#IDX256">Wdiff (import example)</A>
-<LI><A HREF="cvs_77.html#IDX285">What (shell command)</A>
-<LI><A HREF="cvs_50.html#IDX208">What branches are good for</A>
-<LI><A HREF="cvs_5.html#IDX12">What is CVS?</A>
-<LI><A HREF="cvs_83.html#IDX290">When to commit</A>
-<LI><A HREF="cvs_9.html#IDX38">Work-session, example of</A>
-<LI><A HREF="cvs_35.html#IDX131">Working copy</A>
-<LI><A HREF="cvs_12.html#IDX51">Working copy, removing</A>
-<LI><A HREF="cvs_131.html#IDX373">Wrappers</A>
-</DIR>
-<H2><A NAME="cindex_z">z</A></H2>
-<DIR>
-<LI><A HREF="cvs_88.html#IDX324">zone, time, in input</A>
-<LI><A HREF="cvs_109.html#IDX349">zone, time, in output</A>
-</DIR>
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_147.html">previous</A>,
next, last section, <A HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_15.html
===================================================================
RCS file: manual/html_node/cvs_15.html
diff -N manual/html_node/cvs_15.html
--- manual/html_node/cvs_15.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,79 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Specifying a repository</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_14.html">previous</A>,
<A HREF="cvs_16.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC16" HREF="cvs_toc.html#TOC16">Telling CVS where your
repository is</A></H2>
-
-<P>
-There are a couple of different ways to tell CVS
-where to find the repository. You can name the
-repository on the command line explicitly, with the
-<CODE>-d</CODE> (for "directory") option:
-
-</P>
-
-<PRE>
-cvs -d /usr/local/cvsroot checkout yoyodyne/tc
-</PRE>
-
-<P>
-<A NAME="IDX63"></A>
-<A NAME="IDX64"></A>
-<A NAME="IDX65"></A>
-<A NAME="IDX66"></A>
-<A NAME="IDX67"></A>
- Or you can set the <CODE>$CVSROOT</CODE> environment
-variable to an absolute path to the root of the
-repository, <TT>`/usr/local/cvsroot'</TT> in this example.
-To set <CODE>$CVSROOT</CODE>, all <CODE>csh</CODE> and <CODE>tcsh</CODE>
-users should have this line in their <TT>`.cshrc'</TT> or
-<TT>`.tcshrc'</TT> files:
-
-</P>
-
-<PRE>
-setenv CVSROOT /usr/local/cvsroot
-</PRE>
-
-<P>
-<CODE>sh</CODE> and <CODE>bash</CODE> users should instead have these lines in
their
-<TT>`.profile'</TT> or <TT>`.bashrc'</TT>:
-
-</P>
-
-<PRE>
-CVSROOT=/usr/local/cvsroot
-export CVSROOT
-</PRE>
-
-<P>
- A repository specified with <CODE>-d</CODE> will
-override the <CODE>$CVSROOT</CODE> environment variable.
-Once you've checked a working copy out from the
-repository, it will remember where its repository is
-(the information is recorded in the
-<TT>`CVS/Root'</TT> file in the working copy).
-
-</P>
-<P>
-The <CODE>-d</CODE> option and the <TT>`CVS/Root'</TT> file both
-override the <CODE>$CVSROOT</CODE> environment variable. If
-<CODE>-d</CODE> option differs from <TT>`CVS/Root'</TT>, the
-former is used (and specifying <CODE>-d</CODE> will cause
-<TT>`CVS/Root'</TT> to be updated). Of course, for proper
-operation they should be two ways of referring to the
-same repository.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_14.html">previous</A>,
<A HREF="cvs_16.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_16.html
===================================================================
RCS file: manual/html_node/cvs_16.html
diff -N manual/html_node/cvs_16.html
--- manual/html_node/cvs_16.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,39 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Repository storage</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_15.html">previous</A>,
<A HREF="cvs_17.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC17" HREF="cvs_toc.html#TOC17">How data is stored in the
repository</A></H2>
-<P>
-<A NAME="IDX68"></A>
-
-</P>
-<P>
-For most purposes it isn't important <EM>how</EM>
-CVS stores information in the repository. In
-fact, the format has changed in the past, and is likely
-to change in the future. Since in almost all cases one
-accesses the repository via CVS commands; such
-changes need not be disruptive.
-
-</P>
-<P>
-However, in some cases it may be necessary to
-understand how CVS stores data in the repository,
-for example you might need to track down CVS locks
-(see section <A HREF="cvs_40.html#SEC42">Several developers simultaneously
attempting to run CVS</A>) or you might need to deal with
-the file permissions appropriate for the repository.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_15.html">previous</A>,
<A HREF="cvs_17.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_17.html
===================================================================
RCS file: manual/html_node/cvs_17.html
diff -N manual/html_node/cvs_17.html
--- manual/html_node/cvs_17.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,107 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Repository files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_16.html">previous</A>,
<A HREF="cvs_18.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC18" HREF="cvs_toc.html#TOC18">Where files are stored within
the repository</A></H3>
-
-<P>
-The overall structure of the repository is a directory
-tree corresponding to the directories in the working
-directory. For example, supposing the repository is in
-<TT>`/usr/local/cvsroot'</TT>, here is a possible directory
-tree (showing only the directories):
-
-</P>
-
-<PRE>
-<TT>/usr</TT>
- |
- +--<TT>local</TT>
- | |
- | +--<TT>cvsroot</TT>
- | | |
- | | +--<TT>CVSROOT</TT>
- | (administrative files)
- |
- +--<TT>gnu</TT>
- | |
- | +--<TT>diff</TT>
- | | (source code to GNU diff)
- | |
- | +--<TT>rcs</TT>
- | | (source code to RCS)
- | |
- | +--<TT>cvs</TT>
- | (source code to CVS)
- |
- +--<TT>yoyodyne</TT>
- |
- +--<TT>tc</TT>
- | |
- | +--<TT>man</TT>
- | |
- | +--<TT>testing</TT>
- |
- +--(other Yoyodyne software)
-</PRE>
-
-<P>
-With the directories are <EM>history files</EM> for each file
-under version control. The name of the history file is
-the name of the corresponding file with <SAMP>`,v'</SAMP>
-appended to the end. Here is what the repository for
-the <TT>`yoyodyne/tc'</TT> directory might look like:
-
-</P>
-
-<PRE>
- <CODE>$CVSROOT</CODE>
- |
- +--<TT>yoyodyne</TT>
- | |
- | +--<TT>tc</TT>
- | | |
- +--<TT>Makefile,v</TT>
- +--<TT>backend.c,v</TT>
- +--<TT>driver.c,v</TT>
- +--<TT>frontend.c,v</TT>
- +--<TT>parser.c,v</TT>
- +--<TT>man</TT>
- | |
- | +--<TT>tc.1,v</TT>
- |
- +--<TT>testing</TT>
- |
- +--<TT>testpgm.t,v</TT>
- +--<TT>test2.t,v</TT>
-</PRE>
-
-<P>
-<A NAME="IDX69"></A>
-<A NAME="IDX70"></A>
-The history files contain, among other things, enough
-information to recreate any revision of the file, a log
-of all commit messages and the user-name of the person
-who committed the revision. The history files are
-known as <EM>RCS files</EM>, because the first program to
-store files in that format was a version control system
-known as RCS. For a full
-description of the file format, see the <CODE>man</CODE> page
-<CITE>rcsfile(5)</CITE>, distributed with RCS. This
-file format has become very common--many systems other
-than CVS or RCS can at least import history
-files in this format.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_16.html">previous</A>,
<A HREF="cvs_18.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_18.html
===================================================================
RCS file: manual/html_node/cvs_18.html
diff -N manual/html_node/cvs_18.html
--- manual/html_node/cvs_18.html 7 Feb 2007 02:36:43 -0000 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,78 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - File permissions</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_17.html">previous</A>,
<A HREF="cvs_19.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC19" HREF="cvs_toc.html#TOC19">File permissions</A></H3>
-<P>
-<A NAME="IDX71"></A>
-<A NAME="IDX72"></A>
-<A NAME="IDX73"></A>
-<A NAME="IDX74"></A>
-All <SAMP>`,v'</SAMP> files are created read-only, and you
-should not change the permission of those files. The
-directories inside the repository should be writable by
-the persons that have permission to modify the files in
-each directory. This normally means that you must
-create a Unix group (see group(5)) consisting of the
-persons that are to edit the files in a project, and
-set up the repository so that it is that group that
-owns the directory.
-
-</P>
-<P>
-This means that you can only control access to files on
-a per-directory basis.
-
-</P>
-<P>
-Note that users must also have write access to check
-out files, because CVS needs to create lock files
-(see section <A HREF="cvs_40.html#SEC42">Several developers simultaneously
attempting to run CVS</A>).
-
-</P>
-<P>
-Also note that users must have write access to the
-<TT>`CVSROOT/val-tags'</TT> file. CVS uses it to keep
-track of what tags are valid tag names (it is sometimes
-updated when tags are used, as well as when they are
-created, though).
-
-</P>
-<P>
-<A NAME="IDX75"></A>
-<A NAME="IDX76"></A>
-CVS tries to set up reasonable file permissions
-for new directories that are added inside the tree, but
-you must fix the permissions manually when a new
-directory should have different permissions than its
-parent directory. If you set the <CODE>CVSUMASK</CODE>
-environment variable that will control the file
-permissions which CVS uses in creating directories
-and/or files in the repository. <CODE>CVSUMASK</CODE> does
-not affect the file permissions in the working
-directory; such files have the permissions which are
-typical for newly created files, except that sometimes
-CVS creates them read-only (see the sections on
-watches, section <A HREF="cvs_42.html#SEC44">Telling CVS to watch certain
files</A>; -r, section <A HREF="cvs_87.html#SEC89">Global options</A>; or
CVSREAD, section <A HREF="cvs_144.html#SEC151">All environment variables which
affect CVS</A>).
-
-</P>
-<P>
-<A NAME="IDX77"></A>
-<A NAME="IDX78"></A>
-Since CVS was not written to be run setuid, it is
-unsafe to try to run it setuid. You cannot use the
-setuid features of RCS together with CVS.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_17.html">previous</A>,
<A HREF="cvs_19.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_19.html
===================================================================
RCS file: manual/html_node/cvs_19.html
diff -N manual/html_node/cvs_19.html
--- manual/html_node/cvs_19.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,88 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Intro administrative files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_18.html">previous</A>,
<A HREF="cvs_20.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC20" HREF="cvs_toc.html#TOC20">The administrative files</A></H2>
-<P>
-<A NAME="IDX79"></A>
-<A NAME="IDX80"></A>
-<A NAME="IDX81"></A>
-<A NAME="IDX82"></A>
-
-</P>
-
-<P>
-The directory <TT>`$CVSROOT/CVSROOT'</TT> contains some <EM>administrative
-files</EM>. See section <A HREF="cvs_129.html#SEC136">Reference manual for
the Administrative files</A>, for a complete description.
-You can use CVS without any of these files, but
-some commands work better when at least the
-<TT>`modules'</TT> file is properly set up.
-
-</P>
-<P>
-The most important of these files is the <TT>`modules'</TT>
-file. It defines all modules in the repository. This
-is a sample <TT>`modules'</TT> file.
-
-</P>
-
-<PRE>
-CVSROOT CVSROOT
-modules CVSROOT modules
-cvs gnu/cvs
-rcs gnu/rcs
-diff gnu/diff
-tc yoyodyne/tc
-</PRE>
-
-<P>
-The <TT>`modules'</TT> file is line oriented. In its
-simplest form each line contains the name of the
-module, whitespace, and the directory where the module
-resides. The directory is a path relative to
-<CODE>$CVSROOT</CODE>. The last four lines in the example
-above are examples of such lines.
-
-</P>
-
-<P>
-The line that defines the module called <SAMP>`modules'</SAMP>
-uses features that are not explained here.
-See section <A HREF="cvs_130.html#SEC137">The modules file</A>, for a full
explanation of all the
-available features.
-
-</P>
-
-
-<H3><A NAME="SEC21" HREF="cvs_toc.html#TOC21">Editing administrative
files</A></H3>
-<P>
-<A NAME="IDX83"></A>
-<A NAME="IDX84"></A>
-
-</P>
-<P>
-You edit the administrative files in the same way that you would edit
-any other module. Use <SAMP>`cvs checkout CVSROOT'</SAMP> to get a working
-copy, edit it, and commit your changes in the normal way.
-
-</P>
-<P>
-It is possible to commit an erroneous administrative
-file. You can often fix the error and check in a new
-revision, but sometimes a particularly bad error in the
-administrative file makes it impossible to commit new
-revisions.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_18.html">previous</A>,
<A HREF="cvs_20.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_2.html
===================================================================
RCS file: manual/html_node/cvs_2.html
diff -N manual/html_node/cvs_2.html
--- manual/html_node/cvs_2.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,51 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Checklist</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_1.html">previous</A>,
<A HREF="cvs_3.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC2" HREF="cvs_toc.html#TOC2">Checklist for the impatient
reader</A></H2>
-
-<P>
-CVS is a complex system. You will need to read
-the manual to be able to use all of its capabilities.
-There are dangers that can easily be avoided if you
-know about them, and this manual tries to warn you
-about them. This checklist is intended to help you
-avoid the dangers without reading the entire manual.
-If you intend to read the entire manual you can skip
-this table.
-
-</P>
-<DL COMPACT>
-
-<DT>Binary files
-<DD>
-CVS can handle binary files, but
-you must have RCS release 5.5 or later and
-a release of GNU diff that supports the <SAMP>`-a'</SAMP>
-flag (release 1.15 and later are OK). You must also
-configure both RCS and CVS to handle binary
-files when you install them.
-
-Keword substitution can be a source of trouble with
-binary files. See section <A HREF="cvs_75.html#SEC77">Keyword
substitution</A>, for
-solutions.
-
-<DT>The <CODE>admin</CODE> command
-<DD>
-Careless use of the <CODE>admin</CODE> command can cause
-CVS to cease working. See section <A
HREF="cvs_89.html#SEC91">admin--Administration front end for rcs</A>, before
trying
-to use it.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_1.html">previous</A>,
<A HREF="cvs_3.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_20.html
===================================================================
RCS file: manual/html_node/cvs_20.html
diff -N manual/html_node/cvs_20.html
--- manual/html_node/cvs_20.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,56 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Multiple repositories</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_19.html">previous</A>,
<A HREF="cvs_21.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC22" HREF="cvs_toc.html#TOC22">Multiple repositories</A></H2>
-<P>
-<A NAME="IDX85"></A>
-<A NAME="IDX86"></A>
-<A NAME="IDX87"></A>
-<A NAME="IDX88"></A>
-<A NAME="IDX89"></A>
-<A NAME="IDX90"></A>
-
-</P>
-<P>
-In some situations it is a good idea to have more than
-one repository, for instance if you have two
-development groups that work on separate projects
-without sharing any code. All you have to do to have
-several repositories is to specify the appropriate
-repository, using the <CODE>CVSROOT</CODE> environment
-variable, the <SAMP>`-d'</SAMP> option to CVS, or (once
-you have checked out a working directory) by simply
-allowing CVS to use the repository that was used
-to check out the working directory
-(see section <A HREF="cvs_15.html#SEC16">Telling CVS where your repository
is</A>).
-
-</P>
-<P>
-The big advantage of having multiple repositories is
-that they can reside on different servers. The big
-disadvantage is that you cannot have a single CVS
-command recurse into directories which comes from
-different repositories. Generally speaking, if you are
-thinking of setting up several repositories on the same
-machine, you might want to consider using several
-directories within the same repository.
-
-</P>
-<P>
-None of the examples in this manual show multiple
-repositories.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_19.html">previous</A>,
<A HREF="cvs_21.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_21.html
===================================================================
RCS file: manual/html_node/cvs_21.html
diff -N manual/html_node/cvs_21.html
--- manual/html_node/cvs_21.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,63 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Creating a repository</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_20.html">previous</A>,
<A HREF="cvs_22.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC23" HREF="cvs_toc.html#TOC23">Creating a repository</A></H2>
-
-<P>
-<A NAME="IDX91"></A>
-<A NAME="IDX92"></A>
-<A NAME="IDX93"></A>
-
-</P>
-<P>
-To set up a CVS repository, choose a directory
-with ample disk space available for the revision
-history of the source files. It should be accessable
-(directly or via a networked file system) from all
-machines which want to use CVS in server or local
-mode; the client machines need not have any access to
-it other than via the CVS protocol. It is not
-possible to use CVS to read from a repository
-which one only has read access to; CVS needs to be
-able to create lock files (see section <A HREF="cvs_40.html#SEC42">Several
developers simultaneously attempting to run CVS</A>).
-
-</P>
-<P>
-<A NAME="IDX94"></A>
-To create a repository, run the <CODE>cvs init</CODE>
-command. It will set up an empty repository in the
-CVS root specified in the usual way
-(see section <A HREF="cvs_14.html#SEC15">The Repository</A>). For example,
-
-</P>
-
-<PRE>
-cvs -d /usr/local/cvsroot init
-</PRE>
-
-<P>
-<CODE>cvs init</CODE> is careful to never overwrite any
-existing files in the repository, so no harm is done if
-you run <CODE>cvs init</CODE> on an already set-up
-repository.
-
-</P>
-<P>
-<CODE>cvs init</CODE> will enable history logging; if you
-don't want that, remove the history file after running
-<CODE>cvs init</CODE>. See section <A HREF="cvs_142.html#SEC149">The history
file</A>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_20.html">previous</A>,
<A HREF="cvs_22.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_22.html
===================================================================
RCS file: manual/html_node/cvs_22.html
diff -N manual/html_node/cvs_22.html
--- manual/html_node/cvs_22.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,48 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Remote repositories</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_21.html">previous</A>,
<A HREF="cvs_23.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC24" HREF="cvs_toc.html#TOC24">Remote repositories</A></H2>
-<P>
-<A NAME="IDX95"></A>
-<A NAME="IDX96"></A>
-<A NAME="IDX97"></A>
-
-</P>
-<P>
- Your working copy of the sources can be on a
-different machine than the repository. Generally,
-using a remote repository is just like using a local
-one, except that the format of the repository name is:
-
-</P>
-
-<PRE>
-:<VAR>method</VAR>:<VAR>user</VAR>@<VAR>hostname</VAR>:/path/to/repository
-</PRE>
-
-<P>
-The details of exactly what needs to be set up depend
-on how you are connecting to the server.
-
-</P>
-<P>
-If <VAR>method</VAR> is not specified, and the repository
-name contains <SAMP>`:'</SAMP>, then the default is <CODE>ext</CODE>
-or <CODE>server</CODE>, depending on your platform; both are
-described in section <A HREF="cvs_23.html#SEC25">Connecting with rsh</A>.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_21.html">previous</A>,
<A HREF="cvs_23.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_23.html
===================================================================
RCS file: manual/html_node/cvs_23.html
diff -N manual/html_node/cvs_23.html
--- manual/html_node/cvs_23.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,111 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Connecting via rsh</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_22.html">previous</A>,
<A HREF="cvs_24.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC25" HREF="cvs_toc.html#TOC25">Connecting with rsh</A></H3>
-
-<P>
-<A NAME="IDX98"></A>
-CVS uses the <TT>`rsh'</TT> protocol to perform these
-operations, so the remote user host needs to have a
-<TT>`.rhosts'</TT> file which grants access to the local
-user.
-
-</P>
-<P>
-For example, suppose you are the user <TT>`mozart'</TT> on
-the local machine <TT>`anklet.grunge.com'</TT>, and the
-server machine is <TT>`chainsaw.brickyard.com'</TT>. On
-chainsaw, put the following line into the file
-<TT>`.rhosts'</TT> in <TT>`bach'</TT>'s home directory:
-
-</P>
-
-<PRE>
-anklet.grunge.com mozart
-</PRE>
-
-<P>
-Then test that <CODE>rsh</CODE> is working with
-
-</P>
-
-<PRE>
-rsh -l bach chainsaw.brickyard.com 'echo $PATH'
-</PRE>
-
-<P>
-<A NAME="IDX99"></A>
-Next you have to make sure that <CODE>rsh</CODE> will be able
-to find the server. Make sure that the path which
-<CODE>rsh</CODE> printed in the above example includes the
-directory containing a program named <CODE>cvs</CODE> which
-is the server. You need to set the path in
-<TT>`.bashrc'</TT>, <TT>`.cshrc'</TT>, etc., not <TT>`.login'</TT>
-or <TT>`.profile'</TT>. Alternately, you can set the
-environment variable <CODE>CVS_SERVER</CODE> on the client
-machine to the filename of the server you want to use,
-for example <TT>`/usr/local/bin/cvs-1.6'</TT>.
-
-</P>
-<P>
-There is no need to edit <CODE>inetd.conf</CODE> or start a
-CVS server daemon.
-
-</P>
-<P>
-<A NAME="IDX100"></A>
-<A NAME="IDX101"></A>
-There are two access methods that you use in CVSROOT
-for rsh. <CODE>:server:</CODE> specifies an internal rsh
-client, which is supported only by some CVS ports.
-<CODE>:ext:</CODE> specifies an external rsh program. By
-default this is <CODE>rsh</CODE> but you may set the
-<CODE>CVS_RSH</CODE> environment variable to invoke another
-program which can access the remote server (for
-example, <CODE>remsh</CODE> on HP-UX 9 because <CODE>rsh</CODE> is
-something different). It must be a program which can
-transmit data to and from the server without modifying
-it; for example the Windows NT <CODE>rsh</CODE> is not
-suitable since it by default translates between CRLF
-and LF. The OS/2 CVS port has a hack to pass <SAMP>`-b'</SAMP>
-to <CODE>rsh</CODE> to get around this, but since this could
-potentially cause programs for programs other than the
-standard <CODE>rsh</CODE>, it may change in the future. If
-you set <CODE>CVS_RSH</CODE> to <CODE>SSH</CODE> or some other rsh
-replacement, the instructions in the rest of this
-section concerning <TT>`.rhosts'</TT> and so on are likely
-to be incorrect; consult the documentation for your rsh
-replacement.
-
-</P>
-<P>
-Continuing our example, supposing you want to access
-the module <TT>`foo'</TT> in the repository
-<TT>`/usr/local/cvsroot/'</TT>, on machine
-<TT>`chainsaw.brickyard.com'</TT>, you are ready to go:
-
-</P>
-
-<PRE>
-cvs -d :ext:address@hidden:/usr/local/cvsroot checkout foo
-</PRE>
-
-<P>
-(The <TT>`bach@'</TT> can be omitted if the username is
-the same on both the local and remote hosts.)
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_22.html">previous</A>,
<A HREF="cvs_24.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_24.html
===================================================================
RCS file: manual/html_node/cvs_24.html
diff -N manual/html_node/cvs_24.html
--- manual/html_node/cvs_24.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,32 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Password authenticated</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_23.html">previous</A>,
<A HREF="cvs_25.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC26" HREF="cvs_toc.html#TOC26">Direct connection with password
authentication</A></H3>
-
-<P>
-The CVS client can also connect to the server
-using a password protocol. This is particularly useful
-if using <CODE>rsh</CODE> is not feasible (for example,
-the server is behind a firewall), and Kerberos also is
-not available.
-
-</P>
-<P>
- To use this method, it is necessary to make
-some adjustments on both the server and client sides.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_23.html">previous</A>,
<A HREF="cvs_25.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_25.html
===================================================================
RCS file: manual/html_node/cvs_25.html
diff -N manual/html_node/cvs_25.html
--- manual/html_node/cvs_25.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,123 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Password authentication server</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_24.html">previous</A>,
<A HREF="cvs_26.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H4><A NAME="SEC27" HREF="cvs_toc.html#TOC27">Setting up the server for
password authentication</A></H4>
-
-<P>
-<A NAME="IDX102"></A>
-<A NAME="IDX103"></A>
-<A NAME="IDX104"></A>
-On the server side, the file <TT>`/etc/inetd.conf'</TT>
-needs to be edited so <CODE>inetd</CODE> knows to run the
-command <CODE>cvs pserver</CODE> when it receives a
-connection on the right port. By default, the port
-number is 2401; it would be different if your client
-were compiled with <CODE>CVS_AUTH_PORT</CODE> defined to
-something else, though.
-
-</P>
-<P>
- If your <CODE>inetd</CODE> allows raw port numbers in
-<TT>`/etc/inetd.conf'</TT>, then the following (all on a
-single line in <TT>`inetd.conf'</TT>) should be sufficient:
-
-</P>
-
-<PRE>
-2401 stream tcp nowait root /usr/local/bin/cvs
-cvs -b /usr/local/bin pserver
-</PRE>
-
-<P>
-The <SAMP>`-b'</SAMP> option specifies the directory which contains
-the RCS binaries on the server. You could also use the
-<SAMP>`-T'</SAMP> option to specify a temporary directory.
-
-</P>
-<P>
- If your <CODE>inetd</CODE> wants a symbolic service
-name instead of a raw port number, then put this in
-<TT>`/etc/services'</TT>:
-
-</P>
-
-<PRE>
-cvspserver 2401/tcp
-</PRE>
-
-<P>
- and put <CODE>cvspserver</CODE> instead of
-<CODE>2401</CODE> in <TT>`inetd.conf'</TT>.
-
-</P>
-<P>
- Once the above is taken care of, restart your
-<CODE>inetd</CODE>, or do whatever is necessary to force it
-to reread its initialization files.
-
-</P>
-
-<P>
-<A NAME="IDX105"></A>
-<A NAME="IDX106"></A>
-Because the client stores and transmits passwords in
-cleartext (almost--see section <A HREF="cvs_27.html#SEC29">Security
considerations with password authentication</A> for details), a separate CVS
password
-file may be used, so people don't compromise their
-regular passwords when they access the repository.
-This file is <TT>`$CVSROOT/CVSROOT/passwd'</TT>
-(see section <A HREF="cvs_19.html#SEC20">The administrative files</A>). Its
format is
-similar to <TT>`/etc/passwd'</TT>, except that it only has
-two fields, username and password. For example:
-
-</P>
-
-<PRE>
-bach:ULtgRLXo7NRxs
-cwang:1sOp854gDF3DY
-</PRE>
-
-<P>
-The password is encrypted according to the standard
-Unix <CODE>crypt()</CODE> function, so it is possible to
-paste in passwords directly from regular Unix
-<TT>`passwd'</TT> files.
-
-</P>
-<P>
-When authenticating a password, the server first checks
-for the user in the CVS <TT>`passwd'</TT> file. If it
-finds the user, it compares against that password. If
-it does not find the user, or if the CVS
-<TT>`passwd'</TT> file does not exist, then the server
-tries to match the password using the system's
-user-lookup routine. When using the CVS
-<TT>`passwd'</TT> file, the server runs under as the
-username specified in the the third argument in the
-entry, or as the first argument if there is no third
-argument (in this way CVS allows imaginary
-usernames provided the CVS <TT>`passwd'</TT> file
-indicates corresponding valid system usernames). In
-any case, CVS will have no privileges which the
-(valid) user would not have.
-
-</P>
-<P>
-Right now, the only way to put a password in the
-CVS <TT>`passwd'</TT> file is to paste it there from
-somewhere else. Someday, there may be a <CODE>cvs
-passwd</CODE> command.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_24.html">previous</A>,
<A HREF="cvs_26.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_26.html
===================================================================
RCS file: manual/html_node/cvs_26.html
diff -N manual/html_node/cvs_26.html
--- manual/html_node/cvs_26.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,99 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Password authentication client</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_25.html">previous</A>,
<A HREF="cvs_27.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H4><A NAME="SEC28" HREF="cvs_toc.html#TOC28">Using the client with password
authentication</A></H4>
-<P>
-<A NAME="IDX107"></A>
-<A NAME="IDX108"></A>
-<A NAME="IDX109"></A>
-<A NAME="IDX110"></A>
-Before connecting to the server, the client must <EM>log
-in</EM> with the command <CODE>cvs login</CODE>. Logging in
-verifies a password with the server, and also records
-the password for later transactions with the server.
-The <CODE>cvs login</CODE> command needs to know the
-username, server hostname, and full repository path,
-and it gets this information from the repository
-argument or the <CODE>CVSROOT</CODE> environment variable.
-
-</P>
-<P>
-<CODE>cvs login</CODE> is interactive -- it prompts for a
-password:
-
-</P>
-
-<PRE>
-cvs -d :pserver:address@hidden:/usr/local/cvsroot login
-CVS password:
-</PRE>
-
-<P>
-The password is checked with the server; if it is
-correct, the <CODE>login</CODE> succeeds, else it fails,
-complaining that the password was incorrect.
-
-</P>
-<P>
-Once you have logged in, you can force CVS to
-connect directly to the server and authenticate with
-the stored password:
-
-</P>
-
-<PRE>
-cvs -d :pserver:address@hidden:/usr/local/cvsroot checkout foo
-</PRE>
-
-<P>
-The <SAMP>`:pserver:'</SAMP> is necessary because without it,
-CVS will assume it should use <CODE>rsh</CODE> to
-connect with the server (see section <A HREF="cvs_23.html#SEC25">Connecting
with rsh</A>).
-(Once you have a working copy checked out and are
-running CVS commands from within it, there is no
-longer any need to specify the repository explicitly,
-because CVS records it in the working copy's
-<TT>`CVS'</TT> subdirectory.)
-
-</P>
-<P>
-<A NAME="IDX111"></A>
-Passwords are stored by default in the file
-<TT>`$HOME/.cvspass'</TT>. Its format is human-readable,
-but don't edit it unless you know what you are doing.
-The passwords are not stored in cleartext, but are
-trivially encoded to protect them from "innocent"
-compromise (i.e., inadvertently being seen by a system
-administrator who happens to look at that file).
-
-</P>
-<P>
-The <CODE>CVS_PASSFILE</CODE> environment variable overrides
-this default. If you use this variable, make sure you
-set it <EM>before</EM> <CODE>cvs login</CODE> is run. If you
-were to set it after running <CODE>cvs login</CODE>, then
-later CVS commands would be unable to look up the
-password for transmission to the server.
-
-</P>
-<P>
-<A NAME="IDX112"></A>
-The <CODE>CVS_PASSWORD</CODE> environment variable overrides
-<EM>all</EM> stored passwords. If it is set, CVS
-will use it for all password-authenticated
-connections.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_25.html">previous</A>,
<A HREF="cvs_27.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_27.html
===================================================================
RCS file: manual/html_node/cvs_27.html
diff -N manual/html_node/cvs_27.html
--- manual/html_node/cvs_27.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,51 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Password authentication
security</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_26.html">previous</A>,
<A HREF="cvs_28.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H4><A NAME="SEC29" HREF="cvs_toc.html#TOC29">Security considerations with
password authentication</A></H4>
-
-<P>
-The passwords are stored on the client side in a
-trivial encoding of the cleartext, and transmitted in
-the same encoding. The encoding is done only to
-prevent inadvertent password compromises (i.e., a
-system administrator accidentally looking at the file),
-and will not prevent even a naive attacker from gaining
-the password.
-
-</P>
-<P>
-The separate CVS password file (see section <A
HREF="cvs_25.html#SEC27">Setting up the server for password authentication</A>)
allows people
-to use a different password for repository access than
-for login access. On the other hand, once a user has
-access to the repository, she can execute programs on
-the server system through a variety of means. Thus, repository
-access implies fairly broad system access as well. It
-might be possible to modify CVS to prevent that,
-but no one has done so as of this writing.
-Furthermore, there may be other ways in which having
-access to CVS allows people to gain more general
-access to the system; noone has done a careful audit.
-
-</P>
-<P>
-In summary, anyone who gets the password gets
-repository access, and some measure of general system
-access as well. The password is available to anyone
-who can sniff network packets or read a protected
-(i.e., user read-only) file. If you want real
-security, get Kerberos.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_26.html">previous</A>,
<A HREF="cvs_28.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_28.html
===================================================================
RCS file: manual/html_node/cvs_28.html
diff -N manual/html_node/cvs_28.html
--- manual/html_node/cvs_28.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,71 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Kerberos authenticated</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_27.html">previous</A>,
<A HREF="cvs_29.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC30" HREF="cvs_toc.html#TOC30">Direct connection with
kerberos</A></H3>
-
-<P>
-<A NAME="IDX113"></A>
-<A NAME="IDX114"></A>
-The main disadvantage of using rsh is that all the data
-needs to pass through additional programs, so it may be
-slower. So if you have kerberos installed you can
-connect via a direct TCP connection,
-authenticating with kerberos.
-
-</P>
-<P>
-To do this, CVS needs to be compiled with kerberos
-support; when configuring CVS it tries to detect
-whether kerberos is present or you can use the
-<TT>`--with-krb4'</TT> flag to configure.
-
-</P>
-<P>
-The data transmitted is <EM>not</EM> encrypted by
-default. Encryption support must be compiled into both
-the client and server; use the
-<TT>`--enable-encryption'</TT> configure option to turn it
-on. You must then use the <CODE>-x</CODE> global option to
-request encryption.
-
-</P>
-<P>
-<A NAME="IDX115"></A>
-You need to edit <CODE>inetd.conf</CODE> on the server
-machine to run <CODE>cvs kserver</CODE>. The client uses
-port 1999 by default; if you want to use another port
-specify it in the <CODE>CVS_CLIENT_PORT</CODE> environment
-variable on the client.
-
-</P>
-<P>
-<A NAME="IDX116"></A>
-When you want to use CVS, get a ticket in the
-usual way (generally <CODE>kinit</CODE>); it must be a ticket
-which allows you to log into the server machine. Then
-you are ready to go:
-
-</P>
-
-<PRE>
-cvs -d :kserver:chainsaw.brickyard.com:/user/local/cvsroot checkout foo
-</PRE>
-
-<P>
-Previous versions of CVS would fall back to a
-connection via rsh; this version will not do so.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_27.html">previous</A>,
<A HREF="cvs_29.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_29.html
===================================================================
RCS file: manual/html_node/cvs_29.html
diff -N manual/html_node/cvs_29.html
--- manual/html_node/cvs_29.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,38 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Starting a new project</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_28.html">previous</A>,
<A HREF="cvs_30.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC31" HREF="cvs_toc.html#TOC31">Starting a project with
CVS</A></H1>
-<P>
-<A NAME="IDX117"></A>
-<A NAME="IDX118"></A>
-
-</P>
-<P>
-Because renaming files and moving them between
-directories is somewhat inconvenient, the first thing
-you do when you start a new project should be to think
-through your file organization. It is not impossible
-to rename or move files, but it does increase the
-potential for confusion and CVS does have some
-quirks particularly in the area of renaming
-directories. See section <A HREF="cvs_65.html#SEC67">Moving and renaming
files</A>.
-
-</P>
-<P>
-What to do next depends on the situation at hand.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_28.html">previous</A>,
<A HREF="cvs_30.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_3.html
===================================================================
RCS file: manual/html_node/cvs_3.html
diff -N manual/html_node/cvs_3.html
--- manual/html_node/cvs_3.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,61 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Credits</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_2.html">previous</A>,
<A HREF="cvs_4.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC3" HREF="cvs_toc.html#TOC3">Credits</A></H2>
-
-<P>
-<A NAME="IDX5"></A>
-<A NAME="IDX6"></A>
-Roland Pesch, Cygnus Support <<TT>address@hidden</TT>>
-wrote the manual pages which were distributed with
-CVS 1.3. Appendix A and B contain much text that
-was extracted from them. He also read an early draft
-of this manual and contributed many ideas and
-corrections.
-
-</P>
-<P>
-The mailing-list <CODE>info-cvs</CODE> is sometimes
-informative. I have included information from postings
-made by the following persons:
-David G. Grubbs <<TT>address@hidden</TT>>.
-
-</P>
-<P>
-Some text has been extracted from the man pages for
-RCS.
-
-</P>
-<P>
-The CVS FAQ by David G. Grubbs has provided
-useful material. The FAQ is no longer maintained,
-however, and this manual about the closest thing there
-is to a successor (with respect to documenting how to
-use CVS, at least).
-
-</P>
-<P>
-In addition, the following persons have helped by
-telling me about mistakes I've made:
-Roxanne Brunskill <<TT>address@hidden</TT>>,
-Kathy Dyer <<TT>address@hidden</TT>>,
-Karl Pingle <<TT>address@hidden</TT>>,
-Thomas A Peterson <<TT>address@hidden</TT>>,
-Inge Wallin <<TT>address@hidden</TT>>,
-Dirk Koschuetzki <<TT>address@hidden</TT>>
-and Michael Brown <<TT>address@hidden</TT>>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_2.html">previous</A>,
<A HREF="cvs_4.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_30.html
===================================================================
RCS file: manual/html_node/cvs_30.html
diff -N manual/html_node/cvs_30.html
--- manual/html_node/cvs_30.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,24 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Setting up the files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_29.html">previous</A>,
<A HREF="cvs_31.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC32" HREF="cvs_toc.html#TOC32">Setting up the files</A></H2>
-
-<P>
-The first step is to create the files inside the repository. This can
-be done in a couple of different ways.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_29.html">previous</A>,
<A HREF="cvs_31.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_31.html
===================================================================
RCS file: manual/html_node/cvs_31.html
diff -N manual/html_node/cvs_31.html
--- manual/html_node/cvs_31.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,88 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - From files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_30.html">previous</A>,
<A HREF="cvs_32.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC33" HREF="cvs_toc.html#TOC33">Creating a directory tree from a
number of files</A></H3>
-<P>
-<A NAME="IDX119"></A>
-
-</P>
-<P>
-When you begin using CVS, you will probably already have several
-projects that can be
-put under CVS control. In these cases the easiest way is to use the
-<CODE>import</CODE> command. An example is probably the easiest way to
-explain how to use it. If the files you want to install in
-CVS reside in <TT>`<VAR>wdir</VAR>'</TT>, and you want them to appear in the
-repository as <TT>`$CVSROOT/yoyodyne/<VAR>rdir</VAR>'</TT>, you can do this:
-
-</P>
-
-<PRE>
-$ cd <VAR>wdir</VAR>
-$ cvs import -m "Imported sources" yoyodyne/<VAR>rdir</VAR> yoyo start
-</PRE>
-
-<P>
-Unless you supply a log message with the <SAMP>`-m'</SAMP>
-flag, CVS starts an editor and prompts for a
-message. The string <SAMP>`yoyo'</SAMP> is a <EM>vendor tag</EM>,
-and <SAMP>`start'</SAMP> is a <EM>release tag</EM>. They may fill
-no purpose in this context, but since CVS requires
-them they must be present. See section <A HREF="cvs_61.html#SEC63">Tracking
third-party sources</A>, for
-more information about them.
-
-</P>
-<P>
-You can now verify that it worked, and remove your
-original source directory.
-
-</P>
-
-<PRE>
-$ cd ..
-$ mv <VAR>dir</VAR> <VAR>dir</VAR>.orig
-$ cvs checkout yoyodyne/<VAR>dir</VAR> # Explanation below
-$ ls -R yoyodyne
-$ rm -r <VAR>dir</VAR>.orig
-</PRE>
-
-<P>
-Erasing the original sources is a good idea, to make sure that you do
-not accidentally edit them in <VAR>dir</VAR>, bypassing CVS.
-Of course, it would be wise to make sure that you have
-a backup of the sources before you remove them.
-
-</P>
-<P>
-The <CODE>checkout</CODE> command can either take a module
-name as argument (as it has done in all previous
-examples) or a path name relative to <CODE>$CVSROOT</CODE>,
-as it did in the example above.
-
-</P>
-<P>
-It is a good idea to check that the permissions
-CVS sets on the directories inside <SAMP>`$CVSROOT'</SAMP>
-are reasonable, and that they belong to the proper
-groups. See section <A HREF="cvs_18.html#SEC19">File permissions</A>.
-
-</P>
-<P>
-If some of the files you want to import are binary, you
-may want to use the wrappers features to specify which
-files are binary and which are not. See section <A
HREF="cvs_131.html#SEC138">The cvswrappers file</A>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_30.html">previous</A>,
<A HREF="cvs_32.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_32.html
===================================================================
RCS file: manual/html_node/cvs_32.html
diff -N manual/html_node/cvs_32.html
--- manual/html_node/cvs_32.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,74 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - From other version control
systems</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_31.html">previous</A>,
<A HREF="cvs_33.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC34" HREF="cvs_toc.html#TOC34">Creating Files From Other
Version Control Systems</A></H3>
-<P>
-<A NAME="IDX120"></A>
-
-</P>
-<P>
-If you have a project which you are maintaining with
-another version control system, such as RCS, you
-may wish to put the files from that project into
-CVS, and preserve the revision history of the
-files.
-
-</P>
-<DL COMPACT>
-
-<DT>From RCS
-<DD>
-<A NAME="IDX121"></A>
-
-If you have been using RCS, find the RCS
-files--usually a file named <TT>`foo.c'</TT> will have its
-RCS file in <TT>`RCS/foo.c,v'</TT> (but it could be
-other places; consult the RCS documentation for
-details). Then create the appropriate directories in
-CVS if they do not already exist. Then copy the
-files into the appropriate directories in the CVS
-repository (the name in the repository must be the name
-of the source file with <SAMP>`,v'</SAMP> added; the files go
-directly in the appopriate directory of the repository,
-not in an <TT>`RCS'</TT> subdirectory). This is one of the
-few times when it is a good idea to access the CVS
-repository directly, rather than using CVS
-commands. Then you are ready to check out a new
-working directory.
-
-The RCS file should not be locked when you move it
-into CVS; if it is, CVS will have trouble
-letting you operate on it.
-
-<DT>From another version control system
-<DD>
-Many version control systems have the ability to export
-RCS files in the standard format. If yours does,
-export the RCS files and then follow the above
-instructions.
-
-<A NAME="IDX122"></A>
-<DT>From SCCS
-<DD>
-There is a script in the <TT>`contrib'</TT> directory of
-the CVS source distribution called <TT>`sccs2rcs'</TT>
-which converts SCCS files to RCS files.
-Note: you must run it on a machine which has both
-SCCS and RCS installed, and like everything
-else in contrib it is unsupported (your mileage may
-vary).
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_31.html">previous</A>,
<A HREF="cvs_33.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_33.html
===================================================================
RCS file: manual/html_node/cvs_33.html
diff -N manual/html_node/cvs_33.html
--- manual/html_node/cvs_33.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,52 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - From scratch</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_32.html">previous</A>,
<A HREF="cvs_34.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC35" HREF="cvs_toc.html#TOC35">Creating a directory tree from
scratch</A></H3>
-
-<P>
-For a new project, the easiest thing to do is probably
-to create an empty directory structure, like this:
-
-</P>
-
-<PRE>
-$ mkdir tc
-$ mkdir tc/man
-$ mkdir tc/testing
-</PRE>
-
-<P>
-After that, you use the <CODE>import</CODE> command to create
-the corresponding (empty) directory structure inside
-the repository:
-
-</P>
-
-<PRE>
-$ cd tc
-$ cvs import -m "Created directory structure" yoyodyne/<VAR>dir</VAR> yoyo
start
-</PRE>
-
-<P>
-Then, use <CODE>add</CODE> to add files (and new directories)
-as they appear.
-
-</P>
-<P>
-Check that the permissions CVS sets on the
-directories inside <SAMP>`$CVSROOT'</SAMP> are reasonable.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_32.html">previous</A>,
<A HREF="cvs_34.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_34.html
===================================================================
RCS file: manual/html_node/cvs_34.html
diff -N manual/html_node/cvs_34.html
--- manual/html_node/cvs_34.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,79 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Defining the module</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_33.html">previous</A>,
<A HREF="cvs_35.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC36" HREF="cvs_toc.html#TOC36">Defining the module</A></H2>
-<P>
-<A NAME="IDX123"></A>
-<A NAME="IDX124"></A>
-<A NAME="IDX125"></A>
-<A NAME="IDX126"></A>
-
-</P>
-<P>
-The next step is to define the module in the
-<TT>`modules'</TT> file. This is not strictly necessary,
-but modules can be convenient in grouping together
-related files and directories.
-
-</P>
-<P>
-In simple cases these steps are sufficient to define a module.
-
-</P>
-
-<OL>
-<LI>
-
-Get a working copy of the modules file.
-
-
-<PRE>
-$ cvs checkout CVSROOT/modules
-$ cd CVSROOT
-</PRE>
-
-<LI>
-
-Edit the file and insert a line that defines the module. See section <A
HREF="cvs_19.html#SEC20">The administrative files</A>, for an introduction.
See section <A HREF="cvs_130.html#SEC137">The modules file</A>, for a full
-description of the modules file. You can use the
-following line to define the module <SAMP>`tc'</SAMP>:
-
-
-<PRE>
-tc yoyodyne/tc
-</PRE>
-
-<LI>
-
-Commit your changes to the modules file.
-
-
-<PRE>
-$ cvs commit -m "Added the tc module." modules
-</PRE>
-
-<LI>
-
-Release the modules module.
-
-
-<PRE>
-$ cd ..
-$ cvs release -d CVSROOT
-</PRE>
-
-</OL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_33.html">previous</A>,
<A HREF="cvs_35.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_35.html
===================================================================
RCS file: manual/html_node/cvs_35.html
diff -N manual/html_node/cvs_35.html
--- manual/html_node/cvs_35.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,71 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Multiple developers</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_34.html">previous</A>,
<A HREF="cvs_36.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC37" HREF="cvs_toc.html#TOC37">Multiple developers</A></H1>
-<P>
-<A NAME="IDX127"></A>
-<A NAME="IDX128"></A>
-<A NAME="IDX129"></A>
-<A NAME="IDX130"></A>
-<A NAME="IDX131"></A>
-<A NAME="IDX132"></A>
-<A NAME="IDX133"></A>
-<A NAME="IDX134"></A>
-
-</P>
-<P>
-When more than one person works on a software project
-things often get complicated. Often, two people try to
-edit the same file simultaneously. One solution, known
-as <EM>file locking</EM> or <EM>reserved checkouts</EM>, is
-to allow only one person to edit each file at a time.
-This is the only solution with some version control
-systems, including RCS and SCCS. CVS
-doesn't have a very nice implementation of reserved
-checkouts (yet) but there are ways to get it working
-(for example, see the <CODE>cvs admin -l</CODE> command in
-section <A HREF="cvs_90.html#SEC92">admin options</A>). It also may be
possible to use
-the watches features described below, together with
-suitable procedures (not enforced by software), to
-avoid having two people edit at the same time.
-
-</P>
-<P>
-The default model with CVS is known as
-<EM>unreserved checkouts</EM>. In this model, developers
-can edit their own <EM>working copy</EM> of a file
-simultaneously. The first person that commits his
-changes has no automatic way of knowing that another
-has started to edit it. Others will get an error
-message when they try to commit the file. They must
-then use CVS commands to bring their working copy
-up to date with the repository revision. This process
-is almost automatic.
-
-</P>
-<P>
-CVS also supports mechanisms which facilitate
-various kinds of communcation, without actually
-enforcing rules like reserved checkouts do.
-
-</P>
-<P>
-The rest of this chapter describes how these various
-models work, and some of the issues involved in
-choosing between them.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_34.html">previous</A>,
<A HREF="cvs_36.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_36.html
===================================================================
RCS file: manual/html_node/cvs_36.html
diff -N manual/html_node/cvs_36.html
--- manual/html_node/cvs_36.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,110 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - File status</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_35.html">previous</A>,
<A HREF="cvs_37.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC38" HREF="cvs_toc.html#TOC38">File status</A></H2>
-<P>
-<A NAME="IDX135"></A>
-<A NAME="IDX136"></A>
-
-</P>
-<P>
-Based on what operations you have performed on a
-checked out file, and what operations others have
-performed to that file in the repository, one can
-classify a file in a number of states. The states, as
-reported by the <CODE>status</CODE> command, are:
-
-</P>
-<DL COMPACT>
-
-<DT>Up-to-date
-<DD>
-<A NAME="IDX137"></A>
-
-The file is identical with the latest revision in the
-repository for the branch in use.
-
-<DT>Locally Modified
-<DD>
-<A NAME="IDX138"></A>
-You have edited the file, and not yet committed your changes.
-
-<DT>Locally Added
-<DD>
-<A NAME="IDX139"></A>
-You have added the file with <CODE>add</CODE>, and not yet
-committed your changes.
-
-<DT>Locally Removed
-<DD>
-<A NAME="IDX140"></A>
-You have removed the file with <CODE>remove</CODE>, and not yet
-committed your changes.
-
-<DT>Needs Checkout
-<DD>
-<A NAME="IDX141"></A>
-Someone else has committed a newer revision to the
-repository. The name is slightly misleading; you will
-ordinarily use <CODE>update</CODE> rather than
-<CODE>checkout</CODE> to get that newer revision.
-
-<DT>Needs Patch
-<DD>
-<A NAME="IDX142"></A>
-Like Needs Checkout, but the CVS server will send
-a patch rather than the entire file. Sending a patch or
-sending an entire file accomplishes the same thing.
-
-<DT>Needs Merge
-<DD>
-<A NAME="IDX143"></A>
-Someone else has committed a newer revision to the repository, and you
-have also made modifications to the file.
-
-<DT>Unresolved Conflict
-<DD>
-<A NAME="IDX144"></A>
-This is like Locally Modified, except that a previous
-<CODE>update</CODE> command gave a conflict. You need to
-resolve the conflict as described in section <A
HREF="cvs_38.html#SEC40">Conflicts example</A>.
-
-<DT>Unknown
-<DD>
-<A NAME="IDX145"></A>
-CVS doesn't know anything about this file. For
-example, you have created a new file and have not run
-<CODE>add</CODE>.
-
-</DL>
-
-<P>
-To help clarify the file status, <CODE>status</CODE> also
-reports the <CODE>Working revision</CODE> which is the
-revision that the file in the working directory derives
-from, and the <CODE>Repository revision</CODE> which is the
-latest revision in the repository for the branch in
-use.
-
-</P>
-<P>
-For information on the options to <CODE>status</CODE>, see
-section <A HREF="cvs_121.html#SEC128">status--Display status information on
checked out files</A>. For information on its <CODE>Sticky tag</CODE>
-and <CODE>Sticky date</CODE> output, see section <A
HREF="cvs_52.html#SEC54">Sticky tags</A>.
-For information on its <CODE>Sticky options</CODE> output,
-see the <SAMP>`-k'</SAMP> option in section <A
HREF="cvs_126.html#SEC133">update options</A>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_35.html">previous</A>,
<A HREF="cvs_37.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_37.html
===================================================================
RCS file: manual/html_node/cvs_37.html
diff -N manual/html_node/cvs_37.html
--- manual/html_node/cvs_37.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,60 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Updating a file</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_36.html">previous</A>,
<A HREF="cvs_38.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC39" HREF="cvs_toc.html#TOC39">Bringing a file up to
date</A></H2>
-<P>
-<A NAME="IDX146"></A>
-<A NAME="IDX147"></A>
-<A NAME="IDX148"></A>
-<A NAME="IDX149"></A>
-
-</P>
-<P>
-When you want to update or merge a file, use the <CODE>update</CODE>
-command. For files that are not up to date this is roughly equivalent
-to a <CODE>checkout</CODE> command: the newest revision of the file is
-extracted from the repository and put in your working copy of the
-module.
-
-</P>
-<P>
-Your modifications to a file are never lost when you
-use <CODE>update</CODE>. If no newer revision exists,
-running <CODE>update</CODE> has no effect. If you have
-edited the file, and a newer revision is available,
-CVS will merge all changes into your working copy.
-
-</P>
-<P>
-For instance, imagine that you checked out revision 1.4 and started
-editing it. In the meantime someone else committed revision 1.5, and
-shortly after that revision 1.6. If you run <CODE>update</CODE> on the file
-now, CVS will incorporate all changes between revision 1.4 and 1.6 into
-your file.
-
-</P>
-<P>
-<A NAME="IDX150"></A>
-If any of the changes between 1.4 and 1.6 were made too
-close to any of the changes you have made, an
-<EM>overlap</EM> occurs. In such cases a warning is
-printed, and the resulting file includes both
-versions of the lines that overlap, delimited by
-special markers.
-See section <A HREF="cvs_125.html#SEC132">update--Bring work tree in sync with
repository</A>, for a complete description of the
-<CODE>update</CODE> command.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_36.html">previous</A>,
<A HREF="cvs_38.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_38.html
===================================================================
RCS file: manual/html_node/cvs_38.html
diff -N manual/html_node/cvs_38.html
--- manual/html_node/cvs_38.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,216 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Conflicts example</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_37.html">previous</A>,
<A HREF="cvs_39.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC40" HREF="cvs_toc.html#TOC40">Conflicts example</A></H2>
-<P>
-<A NAME="IDX151"></A>
-<A NAME="IDX152"></A>
-<A NAME="IDX153"></A>
-
-</P>
-<P>
-Suppose revision 1.4 of <TT>`driver.c'</TT> contains this:
-
-</P>
-
-<PRE>
-#include <stdio.h>
-
-void main()
-{
- parse();
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? 0 : 1);
-}
-</PRE>
-
-<P>
-Revision 1.6 of <TT>`driver.c'</TT> contains this:
-
-</P>
-
-<PRE>
-#include <stdio.h>
-
-int main(int argc,
- char **argv)
-{
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(!!nerr);
-}
-</PRE>
-
-<P>
-Your working copy of <TT>`driver.c'</TT>, based on revision
-1.4, contains this before you run <SAMP>`cvs update'</SAMP>:
-
-</P>
-
-<PRE>
-#include <stdlib.h>
-#include <stdio.h>
-
-void main()
-{
- init_scanner();
- parse();
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
-}
-</PRE>
-
-<P>
-You run <SAMP>`cvs update'</SAMP>:
-
-</P>
-
-<PRE>
-$ cvs update driver.c
-RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
-retrieving revision 1.4
-retrieving revision 1.6
-Merging differences between 1.4 and 1.6 into driver.c
-rcsmerge warning: overlaps during merge
-cvs update: conflicts found in driver.c
-C driver.c
-</PRE>
-
-<P>
-<A NAME="IDX154"></A>
-CVS tells you that there were some conflicts.
-Your original working file is saved unmodified in
-<TT>`.#driver.c.1.4'</TT>. The new version of
-<TT>`driver.c'</TT> contains this:
-
-</P>
-
-<PRE>
-#include <stdlib.h>
-#include <stdio.h>
-
-int main(int argc,
- char **argv)
-{
- init_scanner();
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
-<<<<<<< driver.c
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
-=======
- exit(!!nerr);
->>>>>>> 1.6
-}
-</PRE>
-
-<P>
-<A NAME="IDX155"></A>
-<A NAME="IDX156"></A>
-<A NAME="IDX157"></A>
-<A NAME="IDX158"></A>
-<A NAME="IDX159"></A>
-
-</P>
-<P>
-Note how all non-overlapping modifications are incorporated in your working
-copy, and that the overlapping section is clearly marked with
-<SAMP>`<<<<<<<'</SAMP>, <SAMP>`======='</SAMP> and
<SAMP>`>>>>>>>'</SAMP>.
-
-</P>
-<P>
-<A NAME="IDX160"></A>
-<A NAME="IDX161"></A>
-You resolve the conflict by editing the file, removing the markers and
-the erroneous line. Suppose you end up with this file:
-
-<PRE>
-#include <stdlib.h>
-#include <stdio.h>
-
-int main(int argc,
- char **argv)
-{
- init_scanner();
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
-}
-</PRE>
-
-<P>
-You can now go ahead and commit this as revision 1.7.
-
-</P>
-
-<PRE>
-$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
-Checking in driver.c;
-/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
-new revision: 1.7; previous revision: 1.6
-done
-</PRE>
-
-<P>
-For your protection, CVS will refuse to check in a
-file if a conflict occurred and you have not resolved
-the conflict. Currently to resolve a conflict, you
-must change the timestamp on the file, and must also
-insure that the file contains no conflict markers. If
-your file legitimately contains conflict markers (that
-is, occurrences of <SAMP>`>>>>>>> '</SAMP> at the
start of a
-line that don't mark a conflict), then CVS has
-trouble handling this and you need to start hacking on
-the <CODE>CVS/Entries</CODE> file or other such workarounds.
-
-</P>
-<P>
-<A NAME="IDX162"></A>
-If you use release 1.04 or later of pcl-cvs (a GNU
-Emacs front-end for CVS) you can use an Emacs
-package called emerge to help you resolve conflicts.
-See the documentation for pcl-cvs.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_37.html">previous</A>,
<A HREF="cvs_39.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_39.html
===================================================================
RCS file: manual/html_node/cvs_39.html
diff -N manual/html_node/cvs_39.html
--- manual/html_node/cvs_39.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,34 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Informing others</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_38.html">previous</A>,
<A HREF="cvs_40.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC41" HREF="cvs_toc.html#TOC41">Informing others about
commits</A></H2>
-<P>
-<A NAME="IDX163"></A>
-<A NAME="IDX164"></A>
-<A NAME="IDX165"></A>
-
-</P>
-<P>
-It is often useful to inform others when you commit a
-new revision of a file. The <SAMP>`-i'</SAMP> option of the
-<TT>`modules'</TT> file, or the <TT>`loginfo'</TT> file, can be
-used to automate this process. See section <A HREF="cvs_130.html#SEC137">The
modules file</A>.
-See section <A HREF="cvs_137.html#SEC144">Loginfo</A>. You can use these
features of CVS
-to, for instance, instruct CVS to mail a
-message to all developers, or post a message to a local
-newsgroup.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_38.html">previous</A>,
<A HREF="cvs_40.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_4.html
===================================================================
RCS file: manual/html_node/cvs_4.html
diff -N manual/html_node/cvs_4.html
--- manual/html_node/cvs_4.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,71 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - BUGS</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_3.html">previous</A>,
<A HREF="cvs_5.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC4" HREF="cvs_toc.html#TOC4">BUGS</A></H2>
-
-<P>
-<A NAME="IDX7"></A>
-<A NAME="IDX8"></A>
-This manual is known to have room for improvement.
-Here is a list of known deficiencies:
-
-</P>
-
-<UL>
-<LI>
-
-In the examples, the output from CVS is sometimes
-displayed, sometimes not.
-
-<LI>
-
-The input that you are supposed to type in the examples
-should have a different font than the output from the
-computer.
-
-<LI>
-
-This manual should be clearer about what file
-permissions you should set up in the repository, and
-about setuid/setgid.
-
-<LI>
-
-Some of the chapters are not yet complete. They are
-noted by comments in the <TT>`cvs.texinfo'</TT> file.
-
-<LI>
-
-<A NAME="IDX9"></A>
-<A NAME="IDX10"></A>
-<A NAME="IDX11"></A>
-This list is not complete. If you notice any error,
-omission, or something that is unclear, please send
-mail to <TT>address@hidden</TT>.
-</UL>
-
-<P>
-I hope that you will find this manual useful, despite
-the above-mentioned shortcomings.
-
-</P>
-
-<PRE>
-
-Linkoping, October 1993
-Per Cederqvist
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_3.html">previous</A>,
<A HREF="cvs_5.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_40.html
===================================================================
RCS file: manual/html_node/cvs_40.html
diff -N manual/html_node/cvs_40.html
--- manual/html_node/cvs_40.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,97 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Concurrency</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_39.html">previous</A>,
<A HREF="cvs_41.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC42" HREF="cvs_toc.html#TOC42">Several developers
simultaneously attempting to run CVS</A></H2>
-
-<P>
-<A NAME="IDX166"></A>
-If several developers try to run CVS at the same
-time, one may get the following message:
-
-</P>
-
-<PRE>
-[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
-</PRE>
-
-<P>
-CVS will try again every 30 seconds, and either
-continue with the operation or print the message again,
-if it still needs to wait. If a lock seems to stick
-around for an undue amount of time, find the person
-holding the lock and ask them about the cvs command
-they are running. If they aren't running a cvs
-command, look for and remove files starting with
-<TT>`#cvs.tfl'</TT>, <TT>`#cvs.rfl'</TT>, or <TT>`#cvs.wfl'</TT>
-from the repository.
-
-</P>
-<P>
-Note that these locks are to protect CVS's
-internal data structures and have no relationship to
-the word <EM>lock</EM> in the sense used by
-RCS---which refers to reserved checkouts
-(see section <A HREF="cvs_35.html#SEC37">Multiple developers</A>).
-
-</P>
-<P>
-Any number of people can be reading from a given
-repository at a time; only when someone is writing do
-the locks prevent other people from reading or writing.
-
-</P>
-<P>
-<A NAME="IDX167"></A>
-<A NAME="IDX168"></A>
-One might hope for the following property
-
-</P>
-
-<PRE>
-If someone commits some changes in one cvs command,
-then an update by someone else will either get all the
-changes, or none of them.
-</PRE>
-
-<P>
-but CVS does <EM>not</EM> have this property. For
-example, given the files
-
-</P>
-
-<PRE>
-a/one.c
-a/two.c
-b/three.c
-b/four.c
-</PRE>
-
-<P>
-if someone runs
-
-</P>
-
-<PRE>
-cvs ci a/two.c b/three.c
-</PRE>
-
-<P>
-and someone else runs <CODE>cvs update</CODE> at the same
-time, the person running <CODE>update</CODE> might get only
-the change to <TT>`b/three.c'</TT> and not the change to
-<TT>`a/two.c'</TT>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_39.html">previous</A>,
<A HREF="cvs_41.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_41.html
===================================================================
RCS file: manual/html_node/cvs_41.html
diff -N manual/html_node/cvs_41.html
--- manual/html_node/cvs_41.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,45 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Watches</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_40.html">previous</A>,
<A HREF="cvs_42.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC43" HREF="cvs_toc.html#TOC43">Mechanisms to track who is
editing files</A></H2>
-<P>
-<A NAME="IDX169"></A>
-
-</P>
-<P>
-For many groups, use of CVS in its default mode is
-perfectly satisfactory. Users may sometimes go to
-check in a modification only to find that another
-modification has intervened, but they deal with it and
-proceed with their check in. Other groups prefer to be
-able to know who is editing what files, so that if two
-people try to edit the same file they can choose to
-talk about who is doing what when rather than be
-surprised at check in time. The features in this
-section allow such coordination, while retaining the
-ability of two developers to edit the same file at the
-same time.
-
-</P>
-<P>
-For maximum benefit developers should use <CODE>cvs
-edit</CODE> (not <CODE>chmod</CODE>) to make files read-write to
-edit them, and <CODE>cvs release</CODE> (not <CODE>rm</CODE>) to
-discard a working directory which is no longer in use,
-but CVS is not able to enforce this behavior.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_40.html">previous</A>,
<A HREF="cvs_42.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_42.html
===================================================================
RCS file: manual/html_node/cvs_42.html
diff -N manual/html_node/cvs_42.html
--- manual/html_node/cvs_42.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,76 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Setting a watch</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_41.html">previous</A>,
<A HREF="cvs_43.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC44" HREF="cvs_toc.html#TOC44">Telling CVS to watch certain
files</A></H3>
-
-<P>
-To enable the watch features, you first specify that
-certain files are to be watched.
-
-</P>
-<P>
-<A NAME="IDX170"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watch on</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX171"></A>
-
-</P>
-<P>
-<A NAME="IDX172"></A>
-Specify that developers should run <CODE>cvs edit</CODE>
-before editing <VAR>files</VAR>. CVS will create working
-copies of <VAR>files</VAR> read-only, to remind developers
-to run the <CODE>cvs edit</CODE> command before working on
-them.
-
-</P>
-<P>
-If <VAR>files</VAR> includes the name of a directory, CVS
-arranges to watch all files added to the corresponding
-repository directory, and sets a default for files
-added in the future; this allows the user to set
-notification policies on a per-directory basis. The
-contents of the directory are processed recursively,
-unless the <CODE>-l</CODE> option is given.
-
-</P>
-<P>
-If <VAR>files</VAR> is omitted, it defaults to the current directory.
-
-</P>
-<P>
-<A NAME="IDX173"></A>
-</DL>
-
-</P>
-<P>
-<DL>
-<DT><U>Command:</U> <B>cvs watch off</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX174"></A>
-
-</P>
-<P>
-Do not provide notification about work on <VAR>files</VAR>. CVS will create
-working copies of <VAR>files</VAR> read-write.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> arguments are processed as for
<CODE>cvs
-watch on</CODE>.
-
-</P>
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_41.html">previous</A>,
<A HREF="cvs_43.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_43.html
===================================================================
RCS file: manual/html_node/cvs_43.html
diff -N manual/html_node/cvs_43.html
--- manual/html_node/cvs_43.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,140 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Getting Notified</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_42.html">previous</A>,
<A HREF="cvs_44.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC45" HREF="cvs_toc.html#TOC45">Telling CVS to notify
you</A></H3>
-
-<P>
-You can tell CVS that you want to receive
-notifications about various actions taken on a file.
-You can do this without using <CODE>cvs watch on</CODE> for
-the file, but generally you will want to use <CODE>cvs
-watch on</CODE>, so that developers use the <CODE>cvs edit</CODE>
-command.
-
-</P>
-<P>
-<A NAME="IDX175"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watch add</B> <I>[<CODE>-a</CODE> action]
[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX176"></A>
-
-</P>
-<P>
-Add the current user to the list of people to receive notification of
-work done on <VAR>files</VAR>.
-
-</P>
-<P>
-The <CODE>-a</CODE> option specifies what kinds of events CVS should notify
-the user about. <VAR>action</VAR> is one of the following:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>edit</CODE>
-<DD>
-Another user has applied the <CODE>cvs edit</CODE> command (described
-below) to a file.
-
-<DT><CODE>unedit</CODE>
-<DD>
-Another user has applied the <CODE>cvs unedit</CODE> command (described
-below) or the <CODE>cvs release</CODE> command to a file, or has deleted
-the file and allowed <CODE>cvs update</CODE> to recreate it.
-
-<DT><CODE>commit</CODE>
-<DD>
-Another user has committed changes to a file.
-
-<DT><CODE>all</CODE>
-<DD>
-All of the above.
-
-<DT><CODE>none</CODE>
-<DD>
-None of the above. (This is useful with <CODE>cvs edit</CODE>,
-described below.)
-
-</DL>
-
-<P>
-The <CODE>-a</CODE> option may appear more than once, or not at all. If
-omitted, the action defaults to <CODE>all</CODE>.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> option are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-</DL>
-
-<P>
-<A NAME="IDX177"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watch remove</B> <I>[<CODE>-a</CODE> action]
[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX178"></A>
-
-</P>
-<P>
-Remove a notification request established using <CODE>cvs watch add</CODE>;
-the arguments are the same. If the <CODE>-a</CODE> option is present, only
-watches for the specified actions are removed.
-
-</P>
-</DL>
-
-<P>
-<A NAME="IDX179"></A>
-When the conditions exist for notification, CVS
-calls the <TT>`notify'</TT> administrative file. Edit
-<TT>`notify'</TT> as one edits the other administrative
-files (see section <A HREF="cvs_19.html#SEC20">The administrative files</A>).
This
-file follows the usual conventions for administrative
-files (see section <A HREF="cvs_133.html#SEC140">The common syntax</A>), where
each line is a regular
-expression followed by a command to execute. The
-command should contain a single ocurrence of <SAMP>`%s'</SAMP>
-which will be replaced by the user to notify; the rest
-of the information regarding the notification will be
-supplied to the command on standard input. The
-standard thing to put in the <CODE>notify</CODE> file is the
-single line:
-
-</P>
-
-<PRE>
-ALL mail %s -s \"CVS notification\"
-</PRE>
-
-<P>
-This causes users to be notified by electronic mail.
-
-</P>
-<P>
-<A NAME="IDX180"></A>
-Note that if you set this up in the straightforward
-way, users receive notifications on the server machine.
-One could of course write a <TT>`notify'</TT> script which
-directed notifications elsewhere, but to make this
-easy, CVS allows you to associate a notification
-address for each user. To do so create a file
-<TT>`users'</TT> in <TT>`CVSROOT'</TT> with a line for each
-user in the format <VAR>user</VAR>:<VAR>value</VAR>. Then
-instead of passing the name of the user to be notified
-to <TT>`notify'</TT>, CVS will pass the <VAR>value</VAR>
-(normally an email address on some other machine).
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_42.html">previous</A>,
<A HREF="cvs_44.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_44.html
===================================================================
RCS file: manual/html_node/cvs_44.html
diff -N manual/html_node/cvs_44.html
--- manual/html_node/cvs_44.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,107 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Editing files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_43.html">previous</A>,
<A HREF="cvs_45.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC46" HREF="cvs_toc.html#TOC46">How to edit a file which is
being watched</A></H3>
-
-<P>
-<A NAME="IDX181"></A>
-Since a file which is being watched is checked out
-read-only, you cannot simply edit it. To make it
-read-write, and inform others that you are planning to
-edit it, use the <CODE>cvs edit</CODE> command. Some systems
-call this a <EM>checkout</EM>, but CVS uses that term
-for obtaining a copy of the sources (see section <A
HREF="cvs_10.html#SEC11">Getting the source</A>), an operation which those
systems call a
-<EM>get</EM> or a <EM>fetch</EM>.
-
-</P>
-<P>
-<A NAME="IDX182"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs edit</B> <I>[options] files ...</I>
-<DD><A NAME="IDX183"></A>
-
-</P>
-<P>
-Prepare to edit the working files <VAR>files</VAR>. CVS makes the
-<VAR>files</VAR> read-write, and notifies users who have requested
-<CODE>edit</CODE> notification for any of <VAR>files</VAR>.
-
-</P>
-<P>
-The <CODE>cvs edit</CODE> command accepts the same <VAR>options</VAR> as the
-<CODE>cvs watch add</CODE> command, and establishes a temporary watch for the
-user on <VAR>files</VAR>; CVS will remove the watch when <VAR>files</VAR> are
-<CODE>unedit</CODE>ed or <CODE>commit</CODE>ted. If the user does not wish to
-receive notifications, she should specify <CODE>-a none</CODE>.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> option are processed as for the
<CODE>cvs
-watch</CODE> commands.
-
-</P>
-</DL>
-
-<P>
-Normally when you are done with a set of changes, you
-use the <CODE>cvs commit</CODE> command, which checks in your
-changes and returns the watched files to their usual
-read-only state. But if you instead decide to abandon
-your changes, or not to make any changes, you can use
-the <CODE>cvs unedit</CODE> command.
-
-</P>
-<P>
-<A NAME="IDX184"></A>
-<A NAME="IDX185"></A>
-<A NAME="IDX186"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs unedit</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX187"></A>
-
-</P>
-<P>
-Abandon work on the working files <VAR>files</VAR>, and revert them to the
-repository versions on which they are based. CVS makes those
-<VAR>files</VAR> read-only for which users have requested notification using
-<CODE>cvs watch on</CODE>. CVS notifies users who have requested
<CODE>unedit</CODE>
-notification for any of <VAR>files</VAR>.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> option are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-<P>
-If watches are not in use, the <CODE>unedit</CODE> command
-probably does not work, and the way to revert to the
-repository version is to remove the file and then use
-<CODE>cvs update</CODE> to get a new copy. The meaning is
-not precisely the same; removing and updating may also
-bring in some changes which have been made in the
-repository since the last time you updated.
-</DL>
-
-</P>
-<P>
-When using client/server CVS, you can use the
-<CODE>cvs edit</CODE> and <CODE>cvs unedit</CODE> commands even if
-CVS is unable to succesfully communicate with the
-server; the notifications will be sent upon the next
-successful CVS command.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_43.html">previous</A>,
<A HREF="cvs_45.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_45.html
===================================================================
RCS file: manual/html_node/cvs_45.html
diff -N manual/html_node/cvs_45.html
--- manual/html_node/cvs_45.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,58 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Watch information</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_44.html">previous</A>,
<A HREF="cvs_46.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC47" HREF="cvs_toc.html#TOC47">Information about who is
watching and editing</A></H3>
-
-<P>
-<A NAME="IDX188"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs watchers</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX189"></A>
-
-</P>
-<P>
-List the users currently watching changes to <VAR>files</VAR>. The report
-includes the files being watched, and the mail address of each watcher.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> arguments are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-</DL>
-
-<P>
-<A NAME="IDX190"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs editors</B> <I>[<CODE>-l</CODE>] files ...</I>
-<DD><A NAME="IDX191"></A>
-
-</P>
-<P>
-List the users currently working on <VAR>files</VAR>. The report
-includes the mail address of each user, the time when the user began
-working with the file, and the host and path of the working directory
-containing the file.
-
-</P>
-<P>
-The <VAR>files</VAR> and <CODE>-l</CODE> arguments are processed as for the
-<CODE>cvs watch</CODE> commands.
-
-</P>
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_44.html">previous</A>,
<A HREF="cvs_46.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_46.html
===================================================================
RCS file: manual/html_node/cvs_46.html
diff -N manual/html_node/cvs_46.html
--- manual/html_node/cvs_46.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,42 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Watches Compatibility</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_45.html">previous</A>,
<A HREF="cvs_47.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC48" HREF="cvs_toc.html#TOC48">Using watches with old versions
of CVS</A></H3>
-
-<P>
-<A NAME="IDX192"></A>
-If you use the watch features on a repository, it
-creates <TT>`CVS'</TT> directories in the repository and
-stores the information about watches in that directory.
-If you attempt to use CVS 1.6 or earlier with the
-repository, you get an error message such as
-
-</P>
-
-<PRE>
-cvs update: cannot open CVS/Entries for reading: No such file or directory
-</PRE>
-
-<P>
-and your operation will likely be aborted. To use the
-watch features, you must upgrade all copies of CVS
-which use that repository in local or server mode. If
-you cannot upgrade, use the <CODE>watch off</CODE> and
-<CODE>watch remove</CODE> commands to remove all watches, and
-that will restore the repository to a state which
-CVS 1.6 can cope with.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_45.html">previous</A>,
<A HREF="cvs_47.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_47.html
===================================================================
RCS file: manual/html_node/cvs_47.html
diff -N manual/html_node/cvs_47.html
--- manual/html_node/cvs_47.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,86 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Choosing a model</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_46.html">previous</A>,
<A HREF="cvs_48.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC49" HREF="cvs_toc.html#TOC49">Choosing between reserved or
unreserved checkouts</A></H2>
-<P>
-<A NAME="IDX193"></A>
-
-</P>
-<P>
-Reserved and unreserved checkouts each have pros and
-cons. Let it be said that a lot of this is a matter of
-opinion or what works given different groups' working
-styles, but here is an attempt to briefly describe the
-issues. There are many ways to organize a team of
-developers. CVS does not try to enforce a certain
-organization. It is a tool that can be used in several
-ways.
-
-</P>
-<P>
-Reserved checkouts can be very counter-productive. If
-two persons want to edit different parts of a file,
-there may be no reason to prevent either of them from
-doing so. Also, it is common for someone to take out a
-lock on a file, because they are planning to edit it,
-but then forget to release the lock.
-
-</P>
-<P>
-People, especially people who are familiar with
-reserved checkouts, often wonder how often conflicts
-occur if unreserved checkouts are used, and how
-difficult they are to resolve. The experience with
-many groups is that they occur rarely and usually are
-relatively straightforward to resolve.
-
-</P>
-<P>
-The rarity of serious conflicts may be surprising, until one realizes
-that they occur only when two developers disagree on the proper design
-for a given section of code; such a disagreement suggests that the
-team has not been communicating properly in the first place. In order
-to collaborate under <EM>any</EM> source management regimen, developers
-must agree on the general design of the system; given this agreement,
-overlapping changes are usually straightforward to merge.
-
-</P>
-<P>
-In some cases unreserved checkouts are clearly
-inappropriate. If no merge tool exists for the kind of
-file you are managing (for example word processor files
-or files edited by Computer Aided Design programs), and
-it is not desirable to change to a program which uses a
-mergeable data format, then resolving conflicts is
-going to be unpleasant enough that you generally will
-be better off to simply avoid the conflicts instead, by
-using reserved checkouts.
-
-</P>
-<P>
-The watches features described above in section <A
HREF="cvs_41.html#SEC43">Mechanisms to track who is editing files</A>
-can be considered to be an intermediate model between
-reserved checkouts and unreserved checkouts. When you
-go to edit a file, it is possible to find out who else
-is editing it. And rather than having the system
-simply forbid both people editing the file, it can tell
-you what the situation is and let you figure out
-whether it is a problem in that particular case or not.
-Therefore, for some groups it can be considered the
-best of both the reserved checkout and unreserved
-checkout worlds.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_46.html">previous</A>,
<A HREF="cvs_48.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_48.html
===================================================================
RCS file: manual/html_node/cvs_48.html
diff -N manual/html_node/cvs_48.html
--- manual/html_node/cvs_48.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,36 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Branches</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_47.html">previous</A>,
<A HREF="cvs_49.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC50" HREF="cvs_toc.html#TOC50">Branches</A></H1>
-<P>
-<A NAME="IDX194"></A>
-<A NAME="IDX195"></A>
-<A NAME="IDX196"></A>
-
-</P>
-<P>
-So far, all revisions shown in this manual have been on
-the <EM>main trunk</EM>
-of the revision tree, i.e., all revision numbers
-have been of the form <VAR>x</VAR>.<VAR>y</VAR>. One useful
-feature, especially when maintaining several releases
-of a software product at once, is the ability to make
-branches on the revision tree. <EM>Tags</EM>, symbolic
-names for revisions, will also be
-introduced in this chapter.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_47.html">previous</A>,
<A HREF="cvs_49.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_49.html
===================================================================
RCS file: manual/html_node/cvs_49.html
diff -N manual/html_node/cvs_49.html
--- manual/html_node/cvs_49.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,187 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Tags</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_48.html">previous</A>,
<A HREF="cvs_50.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC51" HREF="cvs_toc.html#TOC51">Tags--Symbolic revisions</A></H2>
-<P>
-<A NAME="IDX197"></A>
-
-</P>
-<P>
-The revision numbers live a life of their own. They
-need not have anything at all to do with the release
-numbers of your software product. Depending
-on how you use CVS the revision numbers might change several times
-between two releases. As an example, some of the
-source files that make up RCS 5.6 have the following
-revision numbers:
-<A NAME="IDX198"></A>
-
-</P>
-
-<PRE>
-ci.c 5.21
-co.c 5.9
-ident.c 5.3
-rcs.c 5.12
-rcsbase.h 5.11
-rcsdiff.c 5.10
-rcsedit.c 5.11
-rcsfcmp.c 5.9
-rcsgen.c 5.10
-rcslex.c 5.11
-rcsmap.c 5.2
-rcsutil.c 5.10
-</PRE>
-
-<P>
-<A NAME="IDX199"></A>
-<A NAME="IDX200"></A>
-<A NAME="IDX201"></A>
-<A NAME="IDX202"></A>
-You can use the <CODE>tag</CODE> command to give a symbolic name to a
-certain revision of a file. You can use the <SAMP>`-v'</SAMP> flag to the
-<CODE>status</CODE> command to see all tags that a file has, and
-which revision numbers they represent. Tag names can
-contain uppercase and lowercase letters, digits,
-<SAMP>`-'</SAMP>, and <SAMP>`_'</SAMP>. The two tag names <CODE>BASE</CODE>
-and <CODE>HEAD</CODE> are reserved for use by CVS. It
-is expected that future names which are special to
-CVS will contain characters such as <SAMP>`%'</SAMP> or
-<SAMP>`='</SAMP>, rather than being named analogously to
-<CODE>BASE</CODE> and <CODE>HEAD</CODE>, to avoid conflicts with
-actual tag names.
-
-</P>
-<P>
-<A NAME="IDX203"></A>
-<A NAME="IDX204"></A>
-The following example shows how you can add a tag to a
-file. The commands must be issued inside your working
-copy of the module. That is, you should issue the
-command in the directory where <TT>`backend.c'</TT>
-resides.
-
-</P>
-
-<PRE>
-$ cvs tag release-0-4 backend.c
-T backend.c
-$ cvs status -v backend.c
-===================================================================
-File: backend.c Status: Up-to-date
-
- Version: 1.4 Tue Dec 1 14:39:01 1992
- RCS Version: 1.4 /usr/local/cvsroot/yoyodyne/tc/backend.c,v
- Sticky Tag: (none)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-0-4 (revision: 1.4)
-
-</PRE>
-
-<P>
-There is seldom reason to tag a file in isolation. A more common use is
-to tag all the files that constitute a module with the same tag at
-strategic points in the development life-cycle, such as when a release
-is made.
-
-</P>
-
-<PRE>
-$ cvs tag release-1-0 .
-cvs tag: Tagging .
-T Makefile
-T backend.c
-T driver.c
-T frontend.c
-T parser.c
-</PRE>
-
-<P>
-(When you give CVS a directory as argument, it generally applies the
-operation to all the files in that directory, and (recursively), to any
-subdirectories that it may contain. See section <A
HREF="cvs_58.html#SEC60">Recursive behavior</A>.)
-
-</P>
-<P>
-<A NAME="IDX205"></A>
-<A NAME="IDX206"></A>
-The <CODE>checkout</CODE> command has a flag, <SAMP>`-r'</SAMP>, that lets you
check out
-a certain revision of a module. This flag makes it easy to
-retrieve the sources that make up release 1.0 of the module <SAMP>`tc'</SAMP>
at
-any time in the future:
-
-</P>
-
-<PRE>
-$ cvs checkout -r release-1-0 tc
-</PRE>
-
-<P>
-This is useful, for instance, if someone claims that there is a bug in
-that release, but you cannot find the bug in the current working copy.
-
-</P>
-<P>
-You can also check out a module as it was at any given date.
-See section <A HREF="cvs_93.html#SEC97">checkout options</A>.
-
-</P>
-<P>
-When you tag more than one file with the same tag you
-can think about the tag as "a curve drawn through a
-matrix of filename vs. revision number." Say we have 5
-files with the following revisions:
-
-</P>
-
-<PRE>
- file1 file2 file3 file4 file5
-
- 1.1 1.1 1.1 1.1 /--1.1* <-*- TAG
- 1.2*- 1.2 1.2 -1.2*-
- 1.3 \- 1.3*- 1.3 / 1.3
- 1.4 \ 1.4 / 1.4
- \-1.5*- 1.5
- 1.6
-</PRE>
-
-<P>
-At some time in the past, the <CODE>*</CODE> versions were tagged.
-You can think of the tag as a handle attached to the curve
-drawn through the tagged revisions. When you pull on
-the handle, you get all the tagged revisions. Another
-way to look at it is that you "sight" through a set of
-revisions that is "flat" along the tagged revisions,
-like this:
-
-</P>
-
-<PRE>
- file1 file2 file3 file4 file5
-
- 1.1
- 1.2
- 1.1 1.3 _
- 1.1 1.2 1.4 1.1 /
- 1.2*----1.3*----1.5*----1.2*----1.1 (--- <--- Look here
- 1.3 1.6 1.3 \_
- 1.4 1.4
- 1.5
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_48.html">previous</A>,
<A HREF="cvs_50.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_5.html
===================================================================
RCS file: manual/html_node/cvs_5.html
diff -N manual/html_node/cvs_5.html
--- manual/html_node/cvs_5.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,247 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - What is CVS?</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_4.html">previous</A>,
<A HREF="cvs_6.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC5" HREF="cvs_toc.html#TOC5">What is CVS?</A></H1>
-<P>
-<A NAME="IDX12"></A>
-<A NAME="IDX13"></A>
-<A NAME="IDX14"></A>
-
-</P>
-<P>
-CVS is a version control system. Using it, you can
-record the history of your source files.
-
-</P>
-
-<P>
-For example, bugs sometimes creep in when
-software is modified, and you might not detect the bug
-until a long time after you make the modification.
-With CVS, you can easily retrieve old versions to see
-exactly which change caused the bug. This can
-sometimes be a big help.
-
-</P>
-<P>
-You could of course save every version of every file
-you have ever created. This would
-however waste an enormous amount of disk space. CVS
-stores all the versions of a file in a single file in a
-clever way that only stores the differences between
-versions.
-
-</P>
-<P>
-CVS also helps you if you are part of a group of people working
-on the same project. It is all too easy to overwrite
-each others' changes unless you are extremely careful.
-Some editors, like GNU Emacs, try to make sure that
-the same file is never modified by two people at the
-same time. Unfortunately, if someone is using another
-editor, that safeguard will not work. CVS solves this problem
-by insulating the different developers from each other. Every
-developer works in his own directory, and CVS merges
-the work when each developer is done.
-
-</P>
-<P>
-<A NAME="IDX15"></A>
-<A NAME="IDX16"></A>
-<A NAME="IDX17"></A>
-<A NAME="IDX18"></A>
-CVS started out as a bunch of shell scripts written by
-Dick Grune, posted to <CODE>comp.sources.unix</CODE> in the volume 6
-release of December, 1986. While no actual code from
-these shell scripts is present in the current version
-of CVS much of the CVS conflict resolution algorithms
-come from them.
-
-</P>
-<P>
-In April, 1989, Brian Berliner designed and coded CVS.
-Jeff Polk later helped Brian with the design of the CVS
-module and vendor branch support.
-
-</P>
-<P>
-<A NAME="IDX19"></A>
-You can get CVS via anonymous ftp from a number of
-sites, for instance <TT>prep.ai.mit.edu</TT> in
-<TT>`pub/gnu'</TT>.
-
-</P>
-<P>
-<A NAME="IDX20"></A>
-<A NAME="IDX21"></A>
-<A NAME="IDX22"></A>
-There is a mailing list, known as <CODE>info-cvs</CODE>,
-devoted to CVS. To subscribe or
-unsubscribe
-send a message to
-<CODE>address@hidden</CODE>. Please be
-specific about your email address. As of May 1996,
-subscription requests are handled by a busy human
-being, so you cannot expect to be added or removed
-immediately. The usenet group
-<CODE>comp.software.config-mgmt</CODE> is also a suitable
-place for CVS discussions (along with other
-configuration management systems).
-
-</P>
-
-
-
-<H2><A NAME="SEC6" HREF="cvs_toc.html#TOC6">CVS is not...</A></H2>
-
-<P>
-CVS can do a lot of things for you, but it does
-not try to be everything for everyone.
-
-</P>
-<DL COMPACT>
-
-<DT>CVS is not a build system.
-<DD>
-Though the structure of your repository and modules
-file interact with your build system
-(e.g. <TT>`Makefile'</TT>s), they are essentially
-independent.
-
-CVS does not dictate how you build anything. It
-merely stores files for retrieval in a tree structure
-you devise.
-
-CVS does not dictate how to use disk space in the
-checked out working directories. If you write your
-<TT>`Makefile'</TT>s or scripts in every directory so they
-have to know the relative positions of everything else,
-you wind up requiring the entire repository to be
-checked out.
-
-If you modularize your work, and construct a build
-system that will share files (via links, mounts,
-<CODE>VPATH</CODE> in <TT>`Makefile'</TT>s, etc.), you can
-arrange your disk usage however you like.
-
-But you have to remember that <EM>any</EM> such system is
-a lot of work to construct and maintain. CVS does
-not address the issues involved.
-
-Of course, you should place the tools created to
-support such a build system (scripts, <TT>`Makefile'</TT>s,
-etc) under CVS.
-
-Figuring out what files need to be rebuilt when
-something changes is, again, something to be handled
-outside the scope of CVS. One traditional
-approach is to use <CODE>make</CODE> for building, and use
-some automated tool for generating the depencies which
-<CODE>make</CODE> uses.
-
-<DT>CVS is not a substitute for management.
-<DD>
-Your managers and project leaders are expected to talk
-to you frequently enough to make certain you are aware
-of schedules, merge points, branch names and release
-dates. If they don't, CVS can't help.
-
-CVS is an instrument for making sources dance to
-your tune. But you are the piper and the composer. No
-instrument plays itself or writes its own music.
-
-<DT>CVS is not a substitute for developer communication.
-<DD>
-When faced with conflicts within a single file, most
-developers manage to resolve them without too much
-effort. But a more general definition of "conflict"
-includes problems too difficult to solve without
-communication between developers.
-
-CVS cannot determine when simultaneous changes
-within a single file, or across a whole collection of
-files, will logically conflict with one another. Its
-concept of a <EM>conflict</EM> is purely textual, arising
-when two changes to the same base file are near enough
-to spook the merge (i.e. <CODE>diff3</CODE>) command.
-
-CVS does not claim to help at all in figuring out
-non-textual or distributed conflicts in program logic.
-
-For example: Say you change the arguments to function
-<CODE>X</CODE> defined in file <TT>`A'</TT>. At the same time,
-someone edits file <TT>`B'</TT>, adding new calls to
-function <CODE>X</CODE> using the old arguments. You are
-outside the realm of CVS's competence.
-
-Acquire the habit of reading specs and talking to your
-peers.
-
-<DT>CVS does not have change control
-<DD>
-Change control refers to a number of things. First of
-all it can mean <EM>bug-tracking</EM>, that is being able
-to keep a database of reported bugs and the status of
-each one (is it fixed? in what release? has the bug
-submitter agreed that it is fixed?). For interfacing
-CVS to an external bug-tracking system, see the
-<TT>`rcsinfo'</TT> and <TT>`editinfo'</TT> files
-(see section <A HREF="cvs_129.html#SEC136">Reference manual for the
Administrative files</A>).
-
-Another aspect of change control is keeping track of
-the fact that changes to several files were in fact
-changed together as one logical change. If you check
-in several files in a single <CODE>cvs commit</CODE>
-operation, CVS then forgets that those files were
-checked in together, and the fact that they have the
-same log message is the only thing tying them
-together. Keeping a GNU style <TT>`ChangeLog'</TT>
-can help somewhat.
-
-Another aspect of change control, in some systems, is
-the ability to keep track of the status of each
-change. Some changes have been written by a developer,
-others have been reviewed by a second developer, and so
-on. Generally, the way to do this with CVS is to
-generate a diff (using <CODE>cvs diff</CODE> or <CODE>diff</CODE>)
-and email it to someone who can then apply it using the
-<CODE>patch</CODE> utility. This is very flexible, but
-depends on mechanisms outside CVS to make sure
-nothing falls through the cracks.
-
-<DT>CVS is not an automated testing program
-<DD>
-It should be possible to enforce mandatory use of a
-testsuite using the <CODE>commitinfo</CODE> file. I haven't
-heard a lot about projects trying to do that or whether
-there are subtle gotchas, however.
-
-<DT>CVS does not have a builtin process model
-<DD>
-Some systems provide ways to ensure that changes or
-releases go through various steps, with various
-approvals as needed. Generally, one can accomplish
-this with CVS but it might be a little more work.
-In some cases you'll want to use the <TT>`commitinfo'</TT>,
-<TT>`loginfo'</TT>, <TT>`rcsinfo'</TT>, or <TT>`editinfo'</TT>
-files, to require that certain steps be performed
-before cvs will allow a checkin. Also consider whether
-features such as branches and tags can be used to
-perform tasks such as doing work in a development tree
-and then merging certain changes over to a stable tree
-only once they have been proven.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_4.html">previous</A>,
<A HREF="cvs_6.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_50.html
===================================================================
RCS file: manual/html_node/cvs_50.html
diff -N manual/html_node/cvs_50.html
--- manual/html_node/cvs_50.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,43 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Branches motivation</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_49.html">previous</A>,
<A HREF="cvs_51.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC52" HREF="cvs_toc.html#TOC52">What branches are good
for</A></H2>
-<P>
-<A NAME="IDX207"></A>
-<A NAME="IDX208"></A>
-<A NAME="IDX209"></A>
-
-</P>
-<P>
-Suppose that release 1.0 of tc has been made. You are continuing to
-develop tc, planning to create release 1.1 in a couple of months. After a
-while your customers start to complain about a fatal bug. You check
-out release 1.0 (see section <A HREF="cvs_49.html#SEC51">Tags--Symbolic
revisions</A>) and find the bug
-(which turns out to have a trivial fix). However, the current revision
-of the sources are in a state of flux and are not expected to be stable
-for at least another month. There is no way to make a
-bugfix release based on the newest sources.
-
-</P>
-<P>
-The thing to do in a situation like this is to create a <EM>branch</EM> on
-the revision trees for all the files that make up
-release 1.0 of tc. You can then make
-modifications to the branch without disturbing the main trunk. When the
-modifications are finished you can select to either incorporate them on
-the main trunk, or leave them on the branch.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_49.html">previous</A>,
<A HREF="cvs_51.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_51.html
===================================================================
RCS file: manual/html_node/cvs_51.html
diff -N manual/html_node/cvs_51.html
--- manual/html_node/cvs_51.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,95 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Creating a branch</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_50.html">previous</A>,
<A HREF="cvs_52.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC53" HREF="cvs_toc.html#TOC53">Creating a branch</A></H2>
-<P>
-<A NAME="IDX210"></A>
-<A NAME="IDX211"></A>
-<A NAME="IDX212"></A>
-
-</P>
-<P>
-The <CODE>rtag</CODE> command can be used to create a branch.
-The <CODE>rtag</CODE> command is much like <CODE>tag</CODE>, but it
-does not require that you have a working copy of the
-module. See section <A HREF="cvs_119.html#SEC126">rtag--Add a symbolic tag to
a module</A>. (You can also use the <CODE>tag</CODE>
-command; see section <A HREF="cvs_123.html#SEC130">tag--Add a symbolic tag to
checked out versions of files</A>).
-
-</P>
-
-<PRE>
-$ cvs rtag -b -r release-1-0 release-1-0-patches tc
-</PRE>
-
-<P>
-The <SAMP>`-b'</SAMP> flag makes <CODE>rtag</CODE> create a branch
-(rather than just a symbolic revision name). <SAMP>`-r
-release-1-0'</SAMP> says that this branch should be rooted at the node (in
-the revision tree) that corresponds to the tag
-<SAMP>`release-1-0'</SAMP>. Note that the numeric revision number that matches
-<SAMP>`release-1-0'</SAMP> will probably be different from file to file. The
-name of the new branch is <SAMP>`release-1-0-patches'</SAMP>, and the
-module affected is <SAMP>`tc'</SAMP>.
-
-</P>
-<P>
-To fix the problem in release 1.0, you need a working
-copy of the branch you just created.
-
-</P>
-
-<PRE>
-$ cvs checkout -r release-1-0-patches tc
-$ cvs status -v driver.c backend.c
-===================================================================
-File: driver.c Status: Up-to-date
-
- Version: 1.7 Sat Dec 5 18:25:54 1992
- RCS Version: 1.7 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
- Sticky Tag: release-1-0-patches (branch: 1.7.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.7.2)
- release-1-0 (revision: 1.7)
-
-===================================================================
-File: backend.c Status: Up-to-date
-
- Version: 1.4 Tue Dec 1 14:39:01 1992
- RCS Version: 1.4 /usr/local/cvsroot/yoyodyne/tc/backend.c,v
- Sticky Tag: release-1-0-patches (branch: 1.4.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.4.2)
- release-1-0 (revision: 1.4)
- release-0-4 (revision: 1.4)
-
-</PRE>
-
-<P>
-<A NAME="IDX213"></A>
-As the output from the <CODE>status</CODE> command shows the branch
-number is created by adding a digit at the tail of the revision number
-it is based on. (If <SAMP>`release-1-0'</SAMP> corresponds to revision 1.4,
the
-branch's revision number will be 1.4.2. For obscure reasons CVS always
-gives branches even numbers, starting at 2.
-See section <A HREF="cvs_7.html#SEC8">Revision numbers</A>).
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_50.html">previous</A>,
<A HREF="cvs_52.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_52.html
===================================================================
RCS file: manual/html_node/cvs_52.html
diff -N manual/html_node/cvs_52.html
--- manual/html_node/cvs_52.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,123 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Sticky tags</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_51.html">previous</A>,
<A HREF="cvs_53.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC54" HREF="cvs_toc.html#TOC54">Sticky tags</A></H2>
-<P>
-<A NAME="IDX214"></A>
-<A NAME="IDX215"></A>
-<A NAME="IDX216"></A>
-
-</P>
-<P>
-The <SAMP>`-r release-1-0-patches'</SAMP> flag that was given
-to <CODE>checkout</CODE> in the previous example
-is <EM>sticky</EM>, that is, it will apply to subsequent commands
-in this directory. If you commit any modifications, they are
-committed on the branch. You can later merge the modifications into
-the main trunk. See section <A HREF="cvs_53.html#SEC55">Merging</A>.
-
-</P>
-<P>
-You can use the <CODE>status</CODE> command to see what
-sticky tags or dates are set:
-
-</P>
-
-<PRE>
-$ vi driver.c # Fix the bugs
-$ cvs commit -m "Fixed initialization bug" driver.c
-Checking in driver.c;
-/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
-new revision: 1.7.2.1; previous revision: 1.7
-done
-$ cvs status -v driver.c
-===================================================================
-File: driver.c Status: Up-to-date
-
- Version: 1.7.2.1 Sat Dec 5 19:35:03 1992
- RCS Version: 1.7.2.1 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
- Sticky Tag: release-1-0-patches (branch: 1.7.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.7.2)
- release-1-0 (revision: 1.7)
-
-</PRE>
-
-<P>
-<A NAME="IDX217"></A>
-<A NAME="IDX218"></A>
-<A NAME="IDX219"></A>
-The sticky tags will remain on your working files until
-you delete them with <SAMP>`cvs update -A'</SAMP>. The
-<SAMP>`-A'</SAMP> option retrieves the version of the file from
-the head of the trunk, and forgets any sticky tags,
-dates, or options.
-
-</P>
-<P>
-<A NAME="IDX220"></A>
-Sticky tags are not just for branches. For example,
-suppose that you want to avoid updating your working
-directory, to isolate yourself from possibly
-destabilizing changes other people are making. You
-can, of course, just refrain from running <CODE>cvs
-update</CODE>. But if you want to avoid updating only a
-portion of a larger tree, then sticky tags can help.
-If you check out a certain revision (such as 1.4) it
-will become sticky. Subsequent <CODE>cvs update</CODE> will
-not retrieve the latest revision until you reset the
-tag with <CODE>cvs update -A</CODE>. Likewise, use of the
-<SAMP>`-D'</SAMP> option to <CODE>update</CODE> or <CODE>checkout</CODE>
-sets a <EM>sticky date</EM>, which, similarly, causes that
-date to be used for future retrievals.
-
-</P>
-<P>
-<A NAME="IDX221"></A>
-<A NAME="IDX222"></A>
-Many times you will want to retrieve an old version of
-a file without setting a sticky tag. The way to do
-that is with the <SAMP>`-p'</SAMP> option to <CODE>checkout</CODE> or
-<CODE>update</CODE>, which sends the contents of the file to
-standard output. For example, suppose you have a file
-named <TT>`file1'</TT> which existed as revision 1.1, and
-you then removed it (thus adding a dead revision 1.2).
-Now suppose you want to add it again, with the same
-contents it had previously. Here is how to do it:
-
-</P>
-
-<PRE>
-$ cvs update -p -r 1.1 file1 >file1
-===================================================================
-Checking out file1
-RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
-VERS: 1.1
-***************
-$ cvs add file1
-cvs add: re-adding file file1 (in place of dead revision 1.2)
-cvs add: use 'cvs commit' to add this file permanently
-$ cvs commit -m test
-Checking in file1;
-/tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1
-new revision: 1.3; previous revision: 1.2
-done
-$
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_51.html">previous</A>,
<A HREF="cvs_53.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_53.html
===================================================================
RCS file: manual/html_node/cvs_53.html
diff -N manual/html_node/cvs_53.html
--- manual/html_node/cvs_53.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,33 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Merging</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_52.html">previous</A>,
<A HREF="cvs_54.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC55" HREF="cvs_toc.html#TOC55">Merging</A></H1>
-<P>
-<A NAME="IDX223"></A>
-<A NAME="IDX224"></A>
-<A NAME="IDX225"></A>
-<A NAME="IDX226"></A>
-<A NAME="IDX227"></A>
-
-</P>
-<P>
-You can include the changes made between any two
-revisions into your working copy, by <EM>merging</EM>.
-You can then commit that revision, and thus effectively
-copy the changes onto another branch.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_52.html">previous</A>,
<A HREF="cvs_54.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_54.html
===================================================================
RCS file: manual/html_node/cvs_54.html
diff -N manual/html_node/cvs_54.html
--- manual/html_node/cvs_54.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,89 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Merging a branch</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_53.html">previous</A>,
<A HREF="cvs_55.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC56" HREF="cvs_toc.html#TOC56">Merging an entire branch</A></H2>
-<P>
-<A NAME="IDX228"></A>
-<A NAME="IDX229"></A>
-
-</P>
-<P>
-You can merge changes made on a branch into your working copy by giving
-the <SAMP>`-j <VAR>branch</VAR>'</SAMP> flag to the <CODE>update</CODE>
command. With one
-<SAMP>`-j <VAR>branch</VAR>'</SAMP> option it merges the changes made between
the
-point where the branch forked and newest revision on that branch (into
-your working copy).
-
-</P>
-<P>
-<A NAME="IDX230"></A>
-The <SAMP>`-j'</SAMP> stands for "join".
-
-</P>
-<P>
-<A NAME="IDX231"></A>
-<A NAME="IDX232"></A>
-<A NAME="IDX233"></A>
-Consider this revision tree:
-
-</P>
-
-<PRE>
-+-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+
- !
- !
- ! +---------+ +---------+
-Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
- +---------+ +---------+
-</PRE>
-
-<P>
-The branch 1.2.2 has been given the tag (symbolic name) <SAMP>`R1fix'</SAMP>.
The
-following example assumes that the module <SAMP>`mod'</SAMP> contains only one
-file, <TT>`m.c'</TT>.
-
-</P>
-
-<PRE>
-$ cvs checkout mod # Retrieve the latest revision, 1.4
-
-$ cvs update -j R1fix m.c # Merge all changes made on the branch,
- # i.e. the changes between revision 1.2
- # and 1.2.2.2, into your working copy
- # of the file.
-
-$ cvs commit -m "Included R1fix" # Create revision 1.5.
-</PRE>
-
-<P>
-A conflict can result from a merge operation. If that
-happens, you should resolve it before committing the
-new revision. See section <A HREF="cvs_38.html#SEC40">Conflicts example</A>.
-
-</P>
-<P>
-The <CODE>checkout</CODE> command also supports the <SAMP>`-j
<VAR>branch</VAR>'</SAMP> flag. The
-same effect as above could be achieved with this:
-
-</P>
-
-<PRE>
-$ cvs checkout -j R1fix mod
-$ cvs commit -m "Included R1fix"
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_53.html">previous</A>,
<A HREF="cvs_55.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_55.html
===================================================================
RCS file: manual/html_node/cvs_55.html
diff -N manual/html_node/cvs_55.html
--- manual/html_node/cvs_55.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,102 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Merging more than once</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_54.html">previous</A>,
<A HREF="cvs_56.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC57" HREF="cvs_toc.html#TOC57">Merging from a branch several
times</A></H2>
-
-<P>
-Continuing our example, the revision tree now looks
-like this:
-
-</P>
-
-<PRE>
-+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+ +-----+
- ! *
- ! *
- ! +---------+ +---------+
-Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
- +---------+ +---------+
-</PRE>
-
-<P>
-where the starred line represents the merge from the
-<SAMP>`R1fix'</SAMP> branch to the main trunk, as just
-discussed.
-
-</P>
-<P>
-Now suppose that development continues on the
-<SAMP>`R1fix'</SAMP> branch:
-
-</P>
-
-<PRE>
-+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+ +-----+
- ! *
- ! *
- ! +---------+ +---------+ +---------+
-Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
- +---------+ +---------+ +---------+
-</PRE>
-
-<P>
-and then you want to merge those new changes onto the
-main trunk. If you just use the <CODE>cvs update -j
-R1fix m.c</CODE> command again, CVS will attempt to
-merge again the changes which you have already merged,
-which can have undesirable side effects.
-
-</P>
-<P>
-So instead you need to specify that you only want to
-merge the changes on the branch which have not yet been
-merged into the trunk. To do that you specify two
-<SAMP>`-j'</SAMP> options, and CVS merges the changes from
-the first revision to the second revision. For
-example, in this case the simplest way would be
-
-</P>
-
-<PRE>
-cvs update -j 1.2.2.2 -j R1fix m.c # Merge changes from 1.2.2.2 to the
- # head of the R1fix branch
-</PRE>
-
-<P>
-The problem with this is that you need to specify the
-1.2.2.2 revision manually. A slightly better approach
-might be to use the date the last merge was done:
-
-</P>
-
-<PRE>
-cvs update -j R1fix:yesterday -j R1fix m.c
-</PRE>
-
-<P>
-Better yet, tag the R1fix branch after every merge into
-the trunk, and then use that tag for subsequent merges:
-
-</P>
-
-<PRE>
-cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_54.html">previous</A>,
<A HREF="cvs_56.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_56.html
===================================================================
RCS file: manual/html_node/cvs_56.html
diff -N manual/html_node/cvs_56.html
--- manual/html_node/cvs_56.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,51 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Merging two revisions</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_55.html">previous</A>,
<A HREF="cvs_57.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC58" HREF="cvs_toc.html#TOC58">Merging differences between any
two revisions</A></H2>
-<P>
-<A NAME="IDX234"></A>
-<A NAME="IDX235"></A>
-<A NAME="IDX236"></A>
-
-</P>
-<P>
-With two <SAMP>`-j <VAR>revision</VAR>'</SAMP> flags, the <CODE>update</CODE>
-(and <CODE>checkout</CODE>) command can merge the differences
-between any two revisions into your working file.
-
-</P>
-<P>
-<A NAME="IDX237"></A>
-<A NAME="IDX238"></A>
-
-<PRE>
-$ cvs update -j 1.5 -j 1.3 backend.c
-</PRE>
-
-<P>
-will <EM>remove</EM> all changes made between revision
-1.3 and 1.5. Note the order of the revisions!
-
-</P>
-<P>
-If you try to use this option when operating on
-multiple files, remember that the numeric revisions will
-probably be very different between the various files
-that make up a module. You almost always use symbolic
-tags rather than revision numbers when operating on
-multiple files.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_55.html">previous</A>,
<A HREF="cvs_57.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_57.html
===================================================================
RCS file: manual/html_node/cvs_57.html
diff -N manual/html_node/cvs_57.html
--- manual/html_node/cvs_57.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,40 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Merging adds and removals</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_56.html">previous</A>,
<A HREF="cvs_58.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC59" HREF="cvs_toc.html#TOC59">Merging can add or remove
files</A></H2>
-
-<P>
-If the changes which you are merging involve removing
-or adding some files, <CODE>update -j</CODE> will reflect
-such additions or removals.
-
-</P>
-<P>
-For example:
-
-<PRE>
-cvs update -A
-touch a b c
-cvs add a b c ; cvs ci -m "added" a b c
-cvs tag -b branchtag
-cvs update -r branchtag
-touch d ; cvs add d
-rm a ; cvs rm a
-cvs ci -m "added d, removed a"
-cvs update -A
-cvs update -jbranchtag
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_56.html">previous</A>,
<A HREF="cvs_58.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_58.html
===================================================================
RCS file: manual/html_node/cvs_58.html
diff -N manual/html_node/cvs_58.html
--- manual/html_node/cvs_58.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,100 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Recursive behavior</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_57.html">previous</A>,
<A HREF="cvs_59.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC60" HREF="cvs_toc.html#TOC60">Recursive behavior</A></H1>
-<P>
-<A NAME="IDX239"></A>
-<A NAME="IDX240"></A>
-<A NAME="IDX241"></A>
-<A NAME="IDX242"></A>
-
-</P>
-<P>
-Almost all of the subcommands of CVS work
-recursively when you specify a directory as an
-argument. For instance, consider this directory
-structure:
-
-</P>
-
-<PRE>
- <CODE>$HOME</CODE>
- |
- +--<TT>tc</TT>
- | |
- +--<TT>CVS</TT>
- | (internal CVS files)
- +--<TT>Makefile</TT>
- +--<TT>backend.c</TT>
- +--<TT>driver.c</TT>
- +--<TT>frontend.c</TT>
- +--<TT>parser.c</TT>
- +--<TT>man</TT>
- | |
- | +--<TT>CVS</TT>
- | | (internal CVS files)
- | +--<TT>tc.1</TT>
- |
- +--<TT>testing</TT>
- |
- +--<TT>CVS</TT>
- | (internal CVS files)
- +--<TT>testpgm.t</TT>
- +--<TT>test2.t</TT>
-</PRE>
-
-<P>
-If <TT>`tc'</TT> is the current working directory, the
-following is true:
-
-</P>
-
-<UL>
-<LI>
-
-<SAMP>`cvs update testing'</SAMP> is equivalent to <SAMP>`cvs
-update testing/testpgm.t testing/test2.t'</SAMP>
-
-<LI>
-
-<SAMP>`cvs update testing man'</SAMP> updates all files in the
-subdirectories
-
-<LI>
-
-<SAMP>`cvs update .'</SAMP> or just <SAMP>`cvs update'</SAMP> updates
-all files in the <CODE>tc</CODE> module
-</UL>
-
-<P>
-If no arguments are given to <CODE>update</CODE> it will
-update all files in the current working directory and
-all its subdirectories. In other words, <TT>`.'</TT> is a
-default argument to <CODE>update</CODE>. This is also true
-for most of the CVS subcommands, not only the
-<CODE>update</CODE> command.
-
-</P>
-<P>
-The recursive behavior of the CVS subcommands can be
-turned off with the <SAMP>`-l'</SAMP> option.
-
-</P>
-
-<PRE>
-$ cvs update -l # Don't update files in subdirectories
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_57.html">previous</A>,
<A HREF="cvs_59.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_59.html
===================================================================
RCS file: manual/html_node/cvs_59.html
diff -N manual/html_node/cvs_59.html
--- manual/html_node/cvs_59.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,129 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Adding files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_58.html">previous</A>,
<A HREF="cvs_60.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC61" HREF="cvs_toc.html#TOC61">Adding files to a
directory</A></H1>
-<P>
-<A NAME="IDX243"></A>
-
-</P>
-<P>
-To add a new file to a directory, follow these steps.
-
-</P>
-
-<UL>
-<LI>
-
-You must have a working copy of the directory.
-See section <A HREF="cvs_10.html#SEC11">Getting the source</A>.
-
-<LI>
-
-Create the new file inside your working copy of the directory.
-
-<LI>
-
-Use <SAMP>`cvs add <VAR>filename</VAR>'</SAMP> to tell CVS that you
-want to version control the file. If the file contains
-binary data, specify <SAMP>`-kb'</SAMP> (see section <A
HREF="cvs_81.html#SEC83">Handling binary files</A>).
-
-<LI>
-
-Use <SAMP>`cvs commit <VAR>filename</VAR>'</SAMP> to actually check
-in the file into the repository. Other developers
-cannot see the file until you perform this step.
-</UL>
-
-<P>
-You can also use the <CODE>add</CODE> command to add a new
-directory.
-
-</P>
-<P>
-Unlike most other commands, the <CODE>add</CODE> command is
-not recursive. You cannot even type <SAMP>`cvs add
-foo/bar'</SAMP>! Instead, you have to
-
-</P>
-
-<PRE>
-$ cd foo
-$ cvs add bar
-</PRE>
-
-<P>
-<A NAME="IDX244"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs add</B> <I>[<CODE>-k</CODE> kflag] [<CODE>-m</CODE>
message] files ...</I>
-<DD><A NAME="IDX245"></A>
-
-</P>
-<P>
-Schedule <VAR>files</VAR> to be added to the repository.
-The files or directories specified with <CODE>add</CODE> must
-already exist in the current directory. To add a whole
-new directory hierarchy to the source repository (for
-example, files received from a third-party vendor), use
-the <CODE>import</CODE> command instead. See section <A
HREF="cvs_105.html#SEC112">import--Import sources into CVS, using vendor
branches</A>.
-
-</P>
-<P>
-The added files are not placed in the source repository
-until you use <CODE>commit</CODE> to make the change
-permanent. Doing an <CODE>add</CODE> on a file that was
-removed with the <CODE>remove</CODE> command will undo the
-effect of the <CODE>remove</CODE>, unless a <CODE>commit</CODE>
-command intervened. See section <A HREF="cvs_60.html#SEC62">Removing files
from a module</A>, for an
-example.
-
-</P>
-<P>
-The <SAMP>`-k'</SAMP> option specifies the default way that
-this file will be checked out; for more information see
-section <A HREF="cvs_79.html#SEC81">Substitution modes</A>.
-
-</P>
-<P>
-The <SAMP>`-m'</SAMP> option specifies a description for the
-file. This description appears in the history log (if
-it is enabled, see section <A HREF="cvs_142.html#SEC149">The history
file</A>). It will also be
-saved in the version history inside the repository when
-the file is committed. The <CODE>log</CODE> command displays
-this description. The description can be changed using
-<SAMP>`admin -t'</SAMP>. See section <A
HREF="cvs_89.html#SEC91">admin--Administration front end for rcs</A>. If you
omit the
-<SAMP>`-m <VAR>description</VAR>'</SAMP> flag, an empty string will
-be used. You will not be prompted for a description.
-</DL>
-
-</P>
-<P>
-For example, the following commands add the file
-<TT>`backend.c'</TT> to the repository:
-
-</P>
-
-<PRE>
-$ cvs add backend.c
-$ cvs commit -m "Early version. Not yet compilable." backend.c
-</PRE>
-
-<P>
-When you add a file it is added only on the branch
-which you are working on (see section <A
HREF="cvs_48.html#SEC50">Branches</A>). You can
-later merge the additions to another branch if you want
-(see section <A HREF="cvs_57.html#SEC59">Merging can add or remove files</A>).
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_58.html">previous</A>,
<A HREF="cvs_60.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_6.html
===================================================================
RCS file: manual/html_node/cvs_6.html
diff -N manual/html_node/cvs_6.html
--- manual/html_node/cvs_6.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,35 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Basic concepts</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_5.html">previous</A>,
<A HREF="cvs_7.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC7" HREF="cvs_toc.html#TOC7">Basic concepts</A></H1>
-<P>
-<A NAME="IDX23"></A>
-
-</P>
-<P>
-CVS stores all files in a centralized
-<EM>repository</EM> (see section <A HREF="cvs_14.html#SEC15">The
Repository</A>).
-
-</P>
-<P>
-The repository contains directories and files, in an
-arbitrary tree. The <EM>modules</EM> feature can be used
-to group together a set of directories or files into a
-single entity (see section <A HREF="cvs_130.html#SEC137">The modules
file</A>). A typical usage is to
-define one module per project.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_5.html">previous</A>,
<A HREF="cvs_7.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_60.html
===================================================================
RCS file: manual/html_node/cvs_60.html
diff -N manual/html_node/cvs_60.html
--- manual/html_node/cvs_60.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,147 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Removing files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_59.html">previous</A>,
<A HREF="cvs_61.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC62" HREF="cvs_toc.html#TOC62">Removing files from a
module</A></H1>
-<P>
-<A NAME="IDX246"></A>
-<A NAME="IDX247"></A>
-
-</P>
-<P>
-Modules change. New files are added, and old files
-disappear. Still, you want to be able to retrieve an
-exact copy of old releases of the module.
-
-</P>
-<P>
-Here is what you can do to remove a file from a module,
-but remain able to retrieve old revisions:
-
-</P>
-
-<UL>
-<LI>
-
-Make sure that you have not made any uncommitted
-modifications to the file. See section <A HREF="cvs_13.html#SEC14">Viewing
differences</A>,
-for one way to do that. You can also use the
-<CODE>status</CODE> or <CODE>update</CODE> command. If you remove
-the file without committing your changes, you will of
-course not be able to retrieve the file as it was
-immediately before you deleted it.
-
-<LI>
-
-Remove the file from your working copy of the module.
-You can for instance use <CODE>rm</CODE>.
-
-<LI>
-
-Use <SAMP>`cvs remove <VAR>filename</VAR>'</SAMP> to tell CVS that
-you really want to delete the file.
-
-<LI>
-
-Use <SAMP>`cvs commit <VAR>filename</VAR>'</SAMP> to actually
-perform the removal of the file from the repository.
-</UL>
-
-<P>
-When you commit the removal of the file, CVS
-records the fact that the file no longer exists. It is
-possible for a file to exist on only some branches and
-not on others, or to re-add another file with the same
-name later. CVS will correctly create or not create
-the file, based on the <SAMP>`-r'</SAMP> and <SAMP>`-D'</SAMP> options
-specified to <CODE>checkout</CODE> or <CODE>update</CODE>.
-
-</P>
-<P>
-<A NAME="IDX248"></A>
-<DL>
-<DT><U>Command:</U> <B>cvs remove</B> <I>[<CODE>-lR</CODE>] files ...</I>
-<DD><A NAME="IDX249"></A>
-
-</P>
-<P>
-Schedule file(s) to be removed from the repository
-(files which have not already been removed from the
-working directory are not processed). This command
-does not actually remove the file from the repository
-until you commit the removal. The <SAMP>`-R'</SAMP> option
-(the default) specifies that it will recurse into
-subdirectories; <SAMP>`-l'</SAMP> specifies that it will not.
-</DL>
-
-</P>
-<P>
-Here is an example of removing several files:
-
-</P>
-
-<PRE>
-$ cd test
-$ rm ?.c
-$ cvs remove
-cvs remove: Removing .
-cvs remove: scheduling a.c for removal
-cvs remove: scheduling b.c for removal
-cvs remove: use 'cvs commit' to remove these files permanently
-$ cvs ci -m "Removed unneeded files"
-cvs commit: Examining .
-cvs commit: Committing .
-</PRE>
-
-<P>
-If you change your mind you can easily resurrect the
-file before you commit it, using the <CODE>add</CODE>
-command.
-
-</P>
-
-<PRE>
-$ ls
-CVS ja.h oj.c
-$ rm oj.c
-$ cvs remove oj.c
-cvs remove: scheduling oj.c for removal
-cvs remove: use 'cvs commit' to remove this file permanently
-$ cvs add oj.c
-U oj.c
-cvs add: oj.c, version 1.1.1.1, resurrected
-</PRE>
-
-<P>
-If you realize your mistake before you run the
-<CODE>remove</CODE> command you can use <CODE>update</CODE> to
-resurrect the file:
-
-</P>
-
-<PRE>
-$ rm oj.c
-$ cvs update oj.c
-cvs update: warning: oj.c was lost
-U oj.c
-</PRE>
-
-<P>
-When you remove a file it is added only on the branch
-which you are working on (see section <A
HREF="cvs_48.html#SEC50">Branches</A>). You can
-later merge the additions to another branch if you want
-(see section <A HREF="cvs_57.html#SEC59">Merging can add or remove files</A>).
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_59.html">previous</A>,
<A HREF="cvs_61.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_61.html
===================================================================
RCS file: manual/html_node/cvs_61.html
diff -N manual/html_node/cvs_61.html
--- manual/html_node/cvs_61.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,58 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Tracking sources</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_60.html">previous</A>,
<A HREF="cvs_62.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC63" HREF="cvs_toc.html#TOC63">Tracking third-party
sources</A></H1>
-<P>
-<A NAME="IDX250"></A>
-<A NAME="IDX251"></A>
-
-</P>
-<P>
-If you modify a program to better fit your site, you
-probably want to include your modifications when the next
-release of the program arrives. CVS can help you with
-this task.
-
-</P>
-<P>
-<A NAME="IDX252"></A>
-<A NAME="IDX253"></A>
-<A NAME="IDX254"></A>
-In the terminology used in CVS, the supplier of the
-program is called a <EM>vendor</EM>. The unmodified
-distribution from the vendor is checked in on its own
-branch, the <EM>vendor branch</EM>. CVS reserves branch
-1.1.1 for this use.
-
-</P>
-<P>
-When you modify the source and commit it, your revision
-will end up on the main trunk. When a new release is
-made by the vendor, you commit it on the vendor branch
-and copy the modifications onto the main trunk.
-
-</P>
-<P>
-Use the <CODE>import</CODE> command to create and update
-the vendor branch. After a successful <CODE>import</CODE>
-the vendor branch is made the `head' revision, so
-anyone that checks out a copy of the file gets that
-revision. When a local modification is committed it is
-placed on the main trunk, and made the `head'
-revision.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_60.html">previous</A>,
<A HREF="cvs_62.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_62.html
===================================================================
RCS file: manual/html_node/cvs_62.html
diff -N manual/html_node/cvs_62.html
--- manual/html_node/cvs_62.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,56 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - First import</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_61.html">previous</A>,
<A HREF="cvs_63.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC64" HREF="cvs_toc.html#TOC64">Importing a module for the first
time</A></H2>
-<P>
-<A NAME="IDX255"></A>
-
-</P>
-<P>
-Use the <CODE>import</CODE> command to check in the sources
-for the first time. When you use the <CODE>import</CODE>
-command to track third-party sources, the <EM>vendor
-tag</EM> and <EM>release tags</EM> are useful. The
-<EM>vendor tag</EM> is a symbolic name for the branch
-(which is always 1.1.1, unless you use the <SAMP>`-b
-<VAR>branch</VAR>'</SAMP> flag---See section <A
HREF="cvs_106.html#SEC113">import options</A>). The
-<EM>release tags</EM> are symbolic names for a particular
-release, such as <SAMP>`FSF_0_04'</SAMP>.
-
-</P>
-<P>
-<A NAME="IDX256"></A>
-Suppose you use <CODE>wdiff</CODE> (a variant of <CODE>diff</CODE>
-that ignores changes that only involve whitespace), and
-are going to make private modifications that you want
-to be able to use even when new releases are made in
-the future. You start by importing the source to your
-repository:
-
-</P>
-
-<PRE>
-$ tar xfz wdiff-0.04.tar.gz
-$ cd wdiff-0.04
-$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
-</PRE>
-
-<P>
-The vendor tag is named <SAMP>`FSF_DIST'</SAMP> in the above
-example, and the only release tag assigned is
-<SAMP>`WDIFF_0_04'</SAMP>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_61.html">previous</A>,
<A HREF="cvs_63.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_63.html
===================================================================
RCS file: manual/html_node/cvs_63.html
diff -N manual/html_node/cvs_63.html
--- manual/html_node/cvs_63.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,67 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Update imports</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_62.html">previous</A>,
<A HREF="cvs_64.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC65" HREF="cvs_toc.html#TOC65">Updating a module with the
import command</A></H2>
-
-<P>
-When a new release of the source arrives, you import it into the
-repository with the same <CODE>import</CODE> command that you used to set up
-the repository in the first place. The only difference is that you
-specify a different release tag this time.
-
-</P>
-
-<PRE>
-$ tar xfz wdiff-0.05.tar.gz
-$ cd wdiff-0.05
-$ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
-</PRE>
-
-<P>
-For files that have not been modified locally, the newly created
-revision becomes the head revision. If you have made local
-changes, <CODE>import</CODE> will warn you that you must merge the changes
-into the main trunk, and tell you to use <SAMP>`checkout -j'</SAMP> to do so.
-
-</P>
-
-<PRE>
-$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
-</PRE>
-
-<P>
-The above command will check out the latest revision of
-<SAMP>`wdiff'</SAMP>, merging the changes made on the vendor branch
<SAMP>`FSF_DIST'</SAMP>
-since yesterday into the working copy. If any conflicts arise during
-the merge they should be resolved in the normal way (see section <A
HREF="cvs_38.html#SEC40">Conflicts example</A>). Then, the modified files may
be committed.
-
-</P>
-<P>
-Using a date, as suggested above, assumes that you do
-not import more than one release of a product per
-day. If you do, you can always use something like this
-instead:
-
-</P>
-
-<PRE>
-$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
-</PRE>
-
-<P>
-In this case, the two above commands are equivalent.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_62.html">previous</A>,
<A HREF="cvs_64.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_64.html
===================================================================
RCS file: manual/html_node/cvs_64.html
diff -N manual/html_node/cvs_64.html
--- manual/html_node/cvs_64.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,23 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Binary files in imports</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_63.html">previous</A>,
<A HREF="cvs_65.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC66" HREF="cvs_toc.html#TOC66">How to handle binary files with
cvs import</A></H2>
-
-<P>
-Use the <SAMP>`-k'</SAMP> wrapper option to tell import which
-files are binary. See section <A HREF="cvs_131.html#SEC138">The cvswrappers
file</A>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_63.html">previous</A>,
<A HREF="cvs_65.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_65.html
===================================================================
RCS file: manual/html_node/cvs_65.html
diff -N manual/html_node/cvs_65.html
--- manual/html_node/cvs_65.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,36 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Moving files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_64.html">previous</A>,
<A HREF="cvs_66.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC67" HREF="cvs_toc.html#TOC67">Moving and renaming
files</A></H1>
-<P>
-<A NAME="IDX257"></A>
-<A NAME="IDX258"></A>
-<A NAME="IDX259"></A>
-
-</P>
-<P>
-Moving files to a different directory or renaming them
-is not difficult, but some of the ways in which this
-works may be non-obvious. (Moving or renaming a
-directory is even harder. See section <A HREF="cvs_69.html#SEC71">Moving and
renaming directories</A>).
-
-</P>
-<P>
-The examples below assume that the file <VAR>old</VAR> is renamed to
-<VAR>new</VAR>.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_64.html">previous</A>,
<A HREF="cvs_66.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_66.html
===================================================================
RCS file: manual/html_node/cvs_66.html
diff -N manual/html_node/cvs_66.html
--- manual/html_node/cvs_66.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,50 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Outside</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_65.html">previous</A>,
<A HREF="cvs_67.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC68" HREF="cvs_toc.html#TOC68">The Normal way to Rename</A></H2>
-
-<P>
-The normal way to move a file is to copy <VAR>old</VAR> to
-<VAR>new</VAR>, and then issue the normal CVS commands
-to remove <VAR>old</VAR> from the repository, and add
-<VAR>new</VAR> to it. (Both <VAR>old</VAR> and <VAR>new</VAR> could
-contain relative paths, for example <TT>`foo/bar.c'</TT>).
-
-</P>
-
-<PRE>
-$ mv <VAR>old</VAR> <VAR>new</VAR>
-$ cvs remove <VAR>old</VAR>
-$ cvs add <VAR>new</VAR>
-$ cvs commit -m "Renamed <VAR>old</VAR> to <VAR>new</VAR>" <VAR>old</VAR>
<VAR>new</VAR>
-</PRE>
-
-<P>
-This is the simplest way to move a file, it is not
-error-prone, and it preserves the history of what was
-done. Note that to access the history of the file you
-must specify the old or the new name, depending on what
-portion of the history you are accessing. For example,
-<CODE>cvs log <VAR>old</VAR></CODE> will give the log up until the
-time of the rename.
-
-</P>
-<P>
-When <VAR>new</VAR> is committed its revision numbers will
-start at 1.0 again, so if that bothers you, use the
-<SAMP>`-r rev'</SAMP> option to commit (see section <A
HREF="cvs_96.html#SEC100">commit options</A>)
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_65.html">previous</A>,
<A HREF="cvs_67.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_67.html
===================================================================
RCS file: manual/html_node/cvs_67.html
diff -N manual/html_node/cvs_67.html
--- manual/html_node/cvs_67.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,68 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Inside</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_66.html">previous</A>,
<A HREF="cvs_68.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC69" HREF="cvs_toc.html#TOC69">Moving the history file</A></H2>
-
-<P>
-This method is more dangerous, since it involves moving
-files inside the repository. Read this entire section
-before trying it out!
-
-</P>
-
-<PRE>
-$ cd $CVSROOT/<VAR>module</VAR>
-$ mv <VAR>old</VAR>,v <VAR>new</VAR>,v
-</PRE>
-
-<P>
-Advantages:
-
-</P>
-
-<UL>
-<LI>
-
-The log of changes is maintained intact.
-
-<LI>
-
-The revision numbers are not affected.
-</UL>
-
-<P>
-Disadvantages:
-
-</P>
-
-<UL>
-<LI>
-
-Old releases of the module cannot easily be fetched from the
-repository. (The file will show up as <VAR>new</VAR> even
-in revisions from the time before it was renamed).
-
-<LI>
-
-There is no log information of when the file was renamed.
-
-<LI>
-
-Nasty things might happen if someone accesses the history file
-while you are moving it. Make sure no one else runs any of the CVS
-commands while you move it.
-</UL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_66.html">previous</A>,
<A HREF="cvs_68.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_68.html
===================================================================
RCS file: manual/html_node/cvs_68.html
diff -N manual/html_node/cvs_68.html
--- manual/html_node/cvs_68.html 7 Nov 2003 20:55:32 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,83 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Rename by copying</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_67.html">previous</A>,
<A HREF="cvs_69.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC70" HREF="cvs_toc.html#TOC70">Copying the history file</A></H2>
-
-<P>
-This way also involves direct modifications to the
-repository. It is safe, but not without drawbacks.
-
-</P>
-
-<PRE>
-# Copy the RCS file inside the repository
-$ cd $CVSROOT/<VAR>module</VAR>
-$ cp <VAR>old</VAR>,v <VAR>new</VAR>,v
-# Remove the old file
-$ cd ~/<VAR>module</VAR>
-$ rm <VAR>old</VAR>
-$ cvs remove <VAR>old</VAR>
-$ cvs commit <VAR>old</VAR>
-# Remove all tags from <VAR>new</VAR>
-$ cvs update <VAR>new</VAR>
-$ cvs log <VAR>new</VAR> # Remember the non-branch tag names
-$ cvs tag -d <VAR>tag1</VAR> <VAR>new</VAR>
-$ cvs tag -d <VAR>tag2</VAR> <VAR>new</VAR>
-...
-</PRE>
-
-<P>
-By removing the tags you will be able to check out old
-revisions of the module.
-
-</P>
-<P>
-Advantages:
-
-</P>
-
-<UL>
-<LI>
-
-Checking out old revisions works correctly, as long as
-you use <SAMP>`-r<VAR>tag</VAR>'</SAMP> and not
<SAMP>`-D<VAR>date</VAR>'</SAMP>
-to retrieve the revisions.
-
-<LI>
-
-The log of changes is maintained intact.
-
-<LI>
-
-The revision numbers are not affected.
-</UL>
-
-<P>
-Disadvantages:
-
-</P>
-
-<UL>
-<LI>
-
-You cannot easily see the history of the file across the rename.
-
-<LI>
-
-Unless you use the <SAMP>`-r rev'</SAMP> (see section <A
HREF="cvs_96.html#SEC100">commit options</A>) flag when <VAR>new</VAR> is
committed its revision
-numbers will start at 1.0 again.
-</UL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_67.html">previous</A>,
<A HREF="cvs_69.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_69.html
===================================================================
RCS file: manual/html_node/cvs_69.html
diff -N manual/html_node/cvs_69.html
--- manual/html_node/cvs_69.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,82 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Moving directories</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_68.html">previous</A>,
<A HREF="cvs_70.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC71" HREF="cvs_toc.html#TOC71">Moving and renaming
directories</A></H1>
-<P>
-<A NAME="IDX260"></A>
-<A NAME="IDX261"></A>
-<A NAME="IDX262"></A>
-
-</P>
-<P>
-If you want to be able to retrieve old versions of the
-module, you must move each file in the directory
-with the CVS commands. See section <A HREF="cvs_66.html#SEC68">The Normal way
to Rename</A>. The old, empty
-directory will remain inside the repository, but it
-will not appear in your workspace when you check out
-the module in the future.
-
-</P>
-<P>
-If you really want to rename or delete a directory, you
-can do it like this:
-
-</P>
-
-<OL>
-<LI>
-
-Inform everyone who has a copy of the module that the
-directory will be renamed. They should commit all
-their changes, and remove their working copies of the
-module, before you take the steps below.
-
-<LI>
-
-Rename the directory inside the repository.
-
-
-<PRE>
-$ cd $CVSROOT/<VAR>module</VAR>
-$ mv <VAR>old-dir</VAR> <VAR>new-dir</VAR>
-</PRE>
-
-<LI>
-
-Fix the CVS administrative files, if necessary (for
-instance if you renamed an entire module).
-
-<LI>
-
-Tell everyone that they can check out the module and continue
-working.
-
-</OL>
-
-<P>
-If someone had a working copy of the module the CVS commands will
-cease to work for him, until he removes the directory
-that disappeared inside the repository.
-
-</P>
-<P>
-It is almost always better to move the files in the
-directory instead of moving the directory. If you move the
-directory you are unlikely to be able to retrieve old
-releases correctly, since they probably depend on the
-name of the directories.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_68.html">previous</A>,
<A HREF="cvs_70.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_7.html
===================================================================
RCS file: manual/html_node/cvs_7.html
diff -N manual/html_node/cvs_7.html
--- manual/html_node/cvs_7.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,107 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Revision numbers</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_6.html">previous</A>,
<A HREF="cvs_8.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC8" HREF="cvs_toc.html#TOC8">Revision numbers</A></H2>
-<P>
-<A NAME="IDX24"></A>
-<A NAME="IDX25"></A>
-<A NAME="IDX26"></A>
-<A NAME="IDX27"></A>
-<A NAME="IDX28"></A>
-<A NAME="IDX29"></A>
-<A NAME="IDX30"></A>
-<A NAME="IDX31"></A>
-
-</P>
-<P>
-Each version of a file has a unique <EM>revision
-number</EM>. Revision numbers look like <SAMP>`1.1'</SAMP>,
-<SAMP>`1.2'</SAMP>, <SAMP>`1.3.2.2'</SAMP> or even <SAMP>`1.3.2.2.4.5'</SAMP>.
-A revision number always has an even number of
-period-separated decimal integers. By default revision
-1.1 is the first revision of a file. Each successive
-revision is given a new number by increasing the
-rightmost number by one. The following figure displays
-a few revisions, with newer revisions to the right.
-
-</P>
-
-<PRE>
- +-----+ +-----+ +-----+ +-----+ +-----+
- ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
- +-----+ +-----+ +-----+ +-----+ +-----+
-</PRE>
-
-<P>
-CVS is not limited to linear development. The
-<EM>revision tree</EM> can be split into <EM>branches</EM>,
-where each branch is a self-maintained line of
-development. Changes made on one branch can easily be
-moved back to the main trunk.
-
-</P>
-<P>
-Each branch has a <EM>branch number</EM>, consisting of an
-odd number of period-separated decimal integers. The
-branch number is created by appending an integer to the
-revision number where the corresponding branch forked
-off. Having branch numbers allows more than one branch
-to be forked off from a certain revision.
-
-</P>
-<P>
-All revisions on a branch have revision numbers formed
-by appending an ordinal number to the branch number.
-The following figure illustrates branching with an
-example.
-
-</P>
-
-<PRE>
- +-------------+
- Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 !
- / +-------------+
- /
- /
- +---------+ +---------+ +---------+ +---------+
-Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !----! 1.2.2.4 !
- / +---------+ +---------+ +---------+ +---------+
- /
- /
-+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+ +-----+
- !
- !
- ! +---------+ +---------+ +---------+
-Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
- +---------+ +---------+ +---------+
-
-</PRE>
-
-<P>
-The exact details of how the branch number is
-constructed is not something you normally need to be
-concerned about, but here is how it works: When
-CVS creates a branch number it picks the first
-unused even integer, starting with 2. So when you want
-to create a branch from revision 6.4 it will be
-numbered 6.4.2. All branch numbers ending in a zero
-(such as 6.4.0) are used internally by CVS
-(see section <A HREF="cvs_146.html#SEC153">Magic branch numbers</A>). The
branch 1.1.1 has a
-special meaning. See section <A HREF="cvs_61.html#SEC63">Tracking third-party
sources</A>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_6.html">previous</A>,
<A HREF="cvs_8.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_70.html
===================================================================
RCS file: manual/html_node/cvs_70.html
diff -N manual/html_node/cvs_70.html
--- manual/html_node/cvs_70.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,32 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - History browsing</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_69.html">previous</A>,
<A HREF="cvs_71.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC72" HREF="cvs_toc.html#TOC72">History browsing</A></H1>
-<P>
-<A NAME="IDX263"></A>
-<A NAME="IDX264"></A>
-<A NAME="IDX265"></A>
-
-</P>
-
-<P>
-Once you have used CVS to store a version control
-history--what files have changed when, how, and by
-whom, there are a variety of mechanisms for looking
-through the history.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_69.html">previous</A>,
<A HREF="cvs_71.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_71.html
===================================================================
RCS file: manual/html_node/cvs_71.html
diff -N manual/html_node/cvs_71.html
--- manual/html_node/cvs_71.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,28 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - log messages</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_70.html">previous</A>,
<A HREF="cvs_72.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC73" HREF="cvs_toc.html#TOC73">Log messages</A></H2>
-
-<P>
-Whenever you commit a file you specify a log message.
-
-</P>
-<P>
-To look through the log messages which have been
-specified for every revision which has been committed,
-use the <CODE>cvs log</CODE> command (see section <A
HREF="cvs_109.html#SEC116">log--Print out log information for files</A>).
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_70.html">previous</A>,
<A HREF="cvs_72.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_72.html
===================================================================
RCS file: manual/html_node/cvs_72.html
diff -N manual/html_node/cvs_72.html
--- manual/html_node/cvs_72.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,25 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - history database</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_71.html">previous</A>,
<A HREF="cvs_73.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC74" HREF="cvs_toc.html#TOC74">The history database</A></H2>
-
-<P>
-You can use the history file (see section <A HREF="cvs_142.html#SEC149">The
history file</A>) to
-log various CVS actions. To retrieve the
-information from the history file, use the <CODE>cvs
-history</CODE> command (see section <A
HREF="cvs_103.html#SEC110">history--Show status of files and users</A>).
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_71.html">previous</A>,
<A HREF="cvs_73.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_73.html
===================================================================
RCS file: manual/html_node/cvs_73.html
diff -N manual/html_node/cvs_73.html
--- manual/html_node/cvs_73.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,53 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - user-defined logging</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_72.html">previous</A>,
<A HREF="cvs_74.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC75" HREF="cvs_toc.html#TOC75">User-defined logging</A></H2>
-
-<P>
-You can customize CVS to log various kinds of
-actions, in whatever manner you choose. These
-mechanisms operate by executing a script at various
-times. The script might append a message to a file
-listing the information and the programmer who created
-it, or send mail to a group of developers, or, perhaps,
-post a message to a particular newsgroup. To log
-commits, use the <TT>`loginfo'</TT> file (see section <A
HREF="cvs_137.html#SEC144">Loginfo</A>).
-To log commits, checkouts, exports, and tags,
-respectively, you can also use the <SAMP>`-i'</SAMP>,
-<SAMP>`-o'</SAMP>, <SAMP>`-e'</SAMP>, and <SAMP>`-t'</SAMP> options in the
-modules file. For a more flexible way of giving
-notifications to various users, which requires less in
-the way of keeping centralized scripts up to date, use
-the <CODE>cvs watch add</CODE> command (see section <A
HREF="cvs_43.html#SEC45">Telling CVS to notify you</A>); this command is useful
even if you are not
-using <CODE>cvs watch on</CODE>.
-
-</P>
-<P>
-<A NAME="IDX266"></A>
-The <TT>`taginfo'</TT> file defines programs to execute
-when someone executes a <CODE>tag</CODE> or <CODE>rtag</CODE>
-command. The <TT>`taginfo'</TT> file has the standard form
-for administrative files (see section <A HREF="cvs_129.html#SEC136">Reference
manual for the Administrative files</A>), where each line is a regular
expression
-followed by a command to execute. The arguments passed
-to the command are, in order, the <VAR>tagname</VAR>,
-<VAR>operation</VAR> (<CODE>add</CODE> for <CODE>tag</CODE>,
-<CODE>mov</CODE> for <CODE>tag -F</CODE>, and <CODE>del</CODE> for
-<CODE>tag -d</CODE>), <VAR>repository</VAR>, and any remaining are
-pairs of <VAR>filename</VAR> <VAR>revision</VAR>. A non-zero
-exit of the filter program will cause the tag to be
-aborted.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_72.html">previous</A>,
<A HREF="cvs_74.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_74.html
===================================================================
RCS file: manual/html_node/cvs_74.html
diff -N manual/html_node/cvs_74.html
--- manual/html_node/cvs_74.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,83 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - annotate</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_73.html">previous</A>,
<A HREF="cvs_75.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC76" HREF="cvs_toc.html#TOC76">Annotate command</A></H2>
-<P>
-<A NAME="IDX267"></A>
-
-</P>
-<P>
-<DL>
-<DT><U>Command:</U> <B>cvs annotate</B> <I>[<CODE>-lf</CODE>] [<CODE>-r
rev</CODE>|<CODE>-D date</CODE>] files ...</I>
-<DD><A NAME="IDX268"></A>
-
-</P>
-<P>
-For each file in <VAR>files</VAR>, print the head revision
-of the trunk, together with information on the last
-modification for each line. For example:
-
-</P>
-
-<PRE>
-$ cvs annotate ssfile
-Annotations for ssfile
-***************
-1.1 (mary 27-Mar-96): ssfile line 1
-1.2 (joe 28-Mar-96): ssfile line 2
-</PRE>
-
-<P>
-The file <TT>`ssfile'</TT> currently contains two lines.
-The <CODE>ssfile line 1</CODE> line was checked in by
-<CODE>mary</CODE> on March 27. Then, on March 28, <CODE>joe</CODE>
-added a line <CODE>ssfile line 2</CODE>, without modifying
-the <CODE>ssfile line 1</CODE> line. This report doesn't
-tell you anything about lines which have been deleted
-or replaced; you need to use <CODE>cvs diff</CODE> for that
-(see section <A HREF="cvs_98.html#SEC105">diff--Run diffs between
revisions</A>).
-
-</P>
-</DL>
-
-<P>
-These standard options are available with
-<CODE>annotate</CODE> (see section <A HREF="cvs_88.html#SEC90">Common command
options</A>, for a complete
-description of them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Annotate the most recent revision no later than <VAR>date</VAR>.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
-<VAR>tag</VAR>'</SAMP> flags. If no matching revision is found,
-annotate the most recent revision (instead of ignoring
-the file).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory. See section <A
HREF="cvs_58.html#SEC60">Recursive behavior</A>.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Annotate revision <VAR>tag</VAR>.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_73.html">previous</A>,
<A HREF="cvs_75.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_75.html
===================================================================
RCS file: manual/html_node/cvs_75.html
diff -N manual/html_node/cvs_75.html
--- manual/html_node/cvs_75.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,45 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Keyword substitution</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_74.html">previous</A>,
<A HREF="cvs_76.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC77" HREF="cvs_toc.html#TOC77">Keyword substitution</A></H1>
-<P>
-<A NAME="IDX269"></A>
-<A NAME="IDX270"></A>
-<A NAME="IDX271"></A>
-
-</P>
-
-<P>
-As long as you edit source files inside your working
-copy of a module you can always find out the state of
-your files via <SAMP>`cvs status'</SAMP> and <SAMP>`cvs log'</SAMP>.
-But as soon as you export the files from your
-development environment it becomes harder to identify
-which revisions they are.
-
-</P>
-<P>
-RCS uses a mechanism known as <EM>keyword
-substitution</EM> (or <EM>keyword expansion</EM>) to help
-identifying the files. Embedded strings of the form
-<CODE>$<VAR>keyword</VAR>$</CODE> and
-<CODE>$<VAR>keyword</VAR>:...$</CODE> in a file are replaced
-with strings of the form
-<CODE>$<VAR>keyword</VAR>:<VAR>value</VAR>$</CODE> whenever you obtain
-a new revision of the file.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_74.html">previous</A>,
<A HREF="cvs_76.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_76.html
===================================================================
RCS file: manual/html_node/cvs_76.html
diff -N manual/html_node/cvs_76.html
--- manual/html_node/cvs_76.html 8 Jun 2009 20:46:59 -0000 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,116 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Keyword list</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_75.html">previous</A>,
<A HREF="cvs_77.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC78" HREF="cvs_toc.html#TOC78">RCS Keywords</A></H2>
-<P>
-<A NAME="IDX272"></A>
-
-</P>
-<P>
-This is a list of the keywords that RCS currently
-(in release 5.6.0.1) supports:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>$Author: ward $</CODE>
-<DD>
-<A NAME="IDX273"></A>
-
-The login name of the user who checked in the revision.
-
-<A NAME="IDX274"></A>
-<DT><CODE>$Date: 2009/06/08 20:46:59 $</CODE>
-<DD>
-The date and time (UTC) the revision was checked in.
-
-<A NAME="IDX275"></A>
-<DT><CODE>$Header:
/web/www/www/software/cvs/manual/html_node/Attic/cvs_76.html,v 1.2 2009/06/08
20:46:59 ward Exp $</CODE>
-<DD>
-A standard header containing the full pathname of the
-RCS file, the revision number, the date (UTC), the
-author, the state, and the locker (if locked). Files
-will normally never be locked when you use CVS.
-
-<A NAME="IDX276"></A>
-<DT><CODE>$Id: cvs_76.html,v 1.2 2009/06/08 20:46:59 ward Exp $</CODE>
-<DD>
-Same as <CODE>$Header:
/web/www/www/software/cvs/manual/html_node/Attic/cvs_76.html,v 1.2 2009/06/08
20:46:59 ward Exp $</CODE>, except that the RCS
-filename is without a path.
-
-<A NAME="IDX277"></A>
-<DT><CODE>$Name: $</CODE>
-<DD>
-Tag name used to check out this file.
-
-<A NAME="IDX278"></A>
-<DT><CODE>$Locker: $</CODE>
-<DD>
-The login name of the user who locked the revision
-(empty if not locked, and thus almost always useless
-when you are using CVS).
-
-<A NAME="IDX279"></A>
-<DT><CODE>$Log: cvs_76.html,v $
-<DT><CODE>Revision 1.2 2009/06/08 20:46:59 ward
-<DT><CODE>changes that were lost from the CVS tree due to the savannah crash
of 2009/05/29
-<DT><CODE>
-<DT><CODE>Revision 1.1 2003/11/07 20:55:33 sinuhe
-<DT><CODE>Add manual.
-<DT><CODE></CODE>
-<DD>
-The log message supplied during commit, preceded by a
-header containing the RCS filename, the revision
-number, the author, and the date (UTC). Existing log
-messages are <EM>not</EM> replaced. Instead, the new log
-message is inserted after <CODE>$Log: cvs_76.html,v $
-message is inserted after <CODE>Revision 1.1 2003/11/07 20:55:33 sinuhe
-message is inserted after <CODE>Add manual.
-message is inserted after <CODE></CODE>.
-Each new line is prefixed with a <EM>comment leader</EM>
-which RCS guesses from the file name extension.
-It can be changed with <CODE>cvs admin -c</CODE>.
-See section <A HREF="cvs_90.html#SEC92">admin options</A>. This keyword is
useful for
-accumulating a complete change log in a source file,
-but for several reasons it can be problematic.
-See section <A HREF="cvs_80.html#SEC82">Problems with the $Log: cvs_76.html,v $
-See section <A HREF="cvs_80.html#SEC82">Problems with the Revision 1.1
2003/11/07 20:55:33 sinuhe
-See section <A HREF="cvs_80.html#SEC82">Problems with the Add manual.
-See section <A HREF="cvs_80.html#SEC82">Problems with the keyword.</A>.
-
-<A NAME="IDX280"></A>
-<DT><CODE>$RCSfile: cvs_76.html,v $</CODE>
-<DD>
-The name of the RCS file without a path.
-
-<A NAME="IDX281"></A>
-<DT><CODE>$Revision: 1.2 $</CODE>
-<DD>
-The revision number assigned to the revision.
-
-<A NAME="IDX282"></A>
-<DT><CODE>$Source:
/web/www/www/software/cvs/manual/html_node/Attic/cvs_76.html,v $</CODE>
-<DD>
-The full pathname of the RCS file.
-
-<A NAME="IDX283"></A>
-<DT><CODE>$State: Exp $</CODE>
-<DD>
-The state assigned to the revision. States can be
-assigned with <CODE>cvs admin -s</CODE>---See section <A
HREF="cvs_90.html#SEC92">admin options</A>.
-
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_75.html">previous</A>,
<A HREF="cvs_77.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_77.html
===================================================================
RCS file: manual/html_node/cvs_77.html
diff -N manual/html_node/cvs_77.html
--- manual/html_node/cvs_77.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,88 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Using keywords</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_76.html">previous</A>,
<A HREF="cvs_78.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC79" HREF="cvs_toc.html#TOC79">Using keywords</A></H2>
-
-<P>
-To include a keyword string you simply include the
-relevant text string, such as <CODE>$Id: cvs_77.html,v 1.1 2003/11/07 20:55:33
sinuhe Exp $</CODE>, inside the
-file, and commit the file. CVS will automatically
-expand the string as part of the commit operation.
-
-</P>
-<P>
-It is common to embed <CODE>$</CODE>Id$ string in the
-C source code. This example shows the first few lines
-of a typical file, after keyword substitution has been
-performed:
-
-</P>
-
-<PRE>
-static char *rcsid="$Id: cvs_77.html,v 1.1 2003/11/07 20:55:33 sinuhe Exp $";
-/* The following lines will prevent <CODE>gcc</CODE> version 2.<VAR>x</VAR>
- from issuing an "unused variable" warning. */
-#if __GNUC__ == 2
-#define USE(var) static void * use_##var = (&use_##var, (void *) &var)
-USE (rcsid);
-#endif
-</PRE>
-
-<P>
-Even though a clever optimizing compiler could remove
-the unused variable <CODE>rcsid</CODE>, most compilers tend
-to include the string in the binary. Some compilers
-have a <CODE>#pragma</CODE> directive to include literal text
-in the binary.
-
-</P>
-<P>
-<A NAME="IDX284"></A>
-The <CODE>ident</CODE> command (which is part of the RCS
-package) can be used to extract keywords and their
-values from a file. This can be handy for text files,
-but it is even more useful for extracting keywords from
-binary files.
-
-</P>
-
-<PRE>
-$ ident samp.c
-samp.c:
- $Id: cvs_77.html,v 1.1 2003/11/07 20:55:33 sinuhe Exp $
-$ gcc samp.c
-$ ident a.out
-a.out:
- $Id: cvs_77.html,v 1.1 2003/11/07 20:55:33 sinuhe Exp $
-</PRE>
-
-<P>
-<A NAME="IDX285"></A>
-SCCS is another popular revision control system.
-It has a command, <CODE>what</CODE>, which is very similar to
-<CODE>ident</CODE> and used for the same purpose. Many sites
-without RCS have SCCS. Since <CODE>what</CODE>
-looks for the character sequence <CODE>@(#)</CODE> it is
-easy to include keywords that are detected by either
-command. Simply prefix the RCS keyword with the
-magic SCCS phrase, like this:
-
-</P>
-
-<PRE>
-static char *id="@(#) $Id: cvs_77.html,v 1.1 2003/11/07 20:55:33 sinuhe Exp $";
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_76.html">previous</A>,
<A HREF="cvs_78.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_78.html
===================================================================
RCS file: manual/html_node/cvs_78.html
diff -N manual/html_node/cvs_78.html
--- manual/html_node/cvs_78.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,43 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Avoiding substitution</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_77.html">previous</A>,
<A HREF="cvs_79.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC80" HREF="cvs_toc.html#TOC80">Avoiding substitution</A></H2>
-
-<P>
-Keyword substitution has its disadvantages. Sometimes
-you might want the literal text string
-<SAMP>`$'</SAMP>Author$ to appear inside a file without
-RCS interpreting it as a keyword and expanding it
-into something like <SAMP>`$'</SAMP>Author: ceder $.
-
-</P>
-<P>
-There is unfortunately no way to selectively turn off
-keyword substitution. You can use <SAMP>`-ko'</SAMP>
-(see section <A HREF="cvs_79.html#SEC81">Substitution modes</A>) to turn off
keyword
-substitution entirely.
-
-</P>
-<P>
-In many cases you can avoid using RCS keywords in
-the source, even though they appear in the final
-product. For example, the source for this manual
-contains <SAMP>address@hidden'</SAMP> whenever the text
-<SAMP>`$'</SAMP>Author$ should appear. In <CODE>nroff</CODE>
-and <CODE>troff</CODE> you can embed the null-character
-<CODE>\&</CODE> inside the keyword for a similar effect.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_77.html">previous</A>,
<A HREF="cvs_79.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_79.html
===================================================================
RCS file: manual/html_node/cvs_79.html
diff -N manual/html_node/cvs_79.html
--- manual/html_node/cvs_79.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,99 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Substitution modes</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_78.html">previous</A>,
<A HREF="cvs_80.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC81" HREF="cvs_toc.html#TOC81">Substitution modes</A></H2>
-<P>
-<A NAME="IDX286"></A>
-<A NAME="IDX287"></A>
-
-</P>
-<P>
-Each file has a stored default substitution mode, and
-each working directory copy of a file also has a
-substitution mode. The former is set by the <SAMP>`-k'</SAMP>
-option to <CODE>cvs add</CODE> and <CODE>cvs admin</CODE>; the
-latter is set by the -k or -A options to <CODE>cvs
-checkout</CODE> or <CODE>cvs update</CODE>. <CODE>cvs diff</CODE> also
-has a <SAMP>`-k'</SAMP> option. For some examples,
-See section <A HREF="cvs_81.html#SEC83">Handling binary files</A>.
-
-</P>
-<P>
-The modes available are:
-
-</P>
-<DL COMPACT>
-
-<DT><SAMP>`-kkv'</SAMP>
-<DD>
-Generate keyword strings using the default form, e.g.
-<CODE>$</CODE>Revision: 5.7 $ for the <CODE>Revision</CODE>
-keyword.
-
-<DT><SAMP>`-kkvl'</SAMP>
-<DD>
-Like <SAMP>`-kkv'</SAMP>, except that a locker's name is always
-inserted if the given revision is currently locked.
-This option is normally not useful when CVS is used.
-
-<DT><SAMP>`-kk'</SAMP>
-<DD>
-Generate only keyword names in keyword strings; omit
-their values. For example, for the <CODE>Revision</CODE>
-keyword, generate the string <CODE>$</CODE>Revision$
-instead of <CODE>$</CODE>Revision: 5.7 $. This option
-is useful to ignore differences due to keyword
-substitution when comparing different revisions of a
-file.
-
-<DT><SAMP>`-ko'</SAMP>
-<DD>
-Generate the old keyword string, present in the working
-file just before it was checked in. For example, for
-the <CODE>Revision</CODE> keyword, generate the string
-<CODE>$</CODE>Revision: 1.1 $ instead of
-<CODE>$</CODE>Revision: 5.7 $ if that is how the
-string appeared when the file was checked in.
-
-<DT><SAMP>`-kb'</SAMP>
-<DD>
-Like <SAMP>`-ko'</SAMP>, but also inhibit conversion of line
-endings between the canonical form in which they are
-stored in the repository (linefeed only), and the form
-appropriate to the operating system in use on the
-client. For systems, like unix, which use linefeed
-only to terminate lines, this is the same as
-<SAMP>`-ko'</SAMP>. For more information on binary files, see
-section <A HREF="cvs_81.html#SEC83">Handling binary files</A>.
-
-<DT><SAMP>`-kv'</SAMP>
-<DD>
-Generate only keyword values for keyword strings. For
-example, for the <CODE>Revision</CODE> keyword, generate the string
-<CODE>5.7</CODE> instead of <CODE>$</CODE>Revision: 5.7 $.
-This can help generate files in programming languages
-where it is hard to strip keyword delimiters like
-<CODE>$</CODE>Revision: $ from a string. However,
-further keyword substitution cannot be performed once
-the keyword names are removed, so this option should be
-used with care.
-
-One often would like to use <SAMP>`-kv'</SAMP> with <CODE>cvs
-export</CODE>---see section <A HREF="cvs_101.html#SEC108">export--Export
sources from CVS, similar to checkout</A>. But be aware that doesn't
-handle an export containing binary files correctly.
-
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_78.html">previous</A>,
<A HREF="cvs_80.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_8.html
===================================================================
RCS file: manual/html_node/cvs_8.html
diff -N manual/html_node/cvs_8.html
--- manual/html_node/cvs_8.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,37 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Versions revisions releases</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_7.html">previous</A>,
<A HREF="cvs_9.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC9" HREF="cvs_toc.html#TOC9">Versions, revisions and
releases</A></H2>
-<P>
-<A NAME="IDX32"></A>
-<A NAME="IDX33"></A>
-<A NAME="IDX34"></A>
-
-</P>
-<P>
-A file can have several versions, as described above.
-Likewise, a software product can have several versions.
-A software product is often given a version number such
-as <SAMP>`4.1.1'</SAMP>.
-
-</P>
-<P>
-Versions in the first sense are called <EM>revisions</EM>
-in this document, and versions in the second sense are
-called <EM>releases</EM>. To avoid confusion, the word
-<EM>version</EM> is almost never used in this document.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_7.html">previous</A>,
<A HREF="cvs_9.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_80.html
===================================================================
RCS file: manual/html_node/cvs_80.html
diff -N manual/html_node/cvs_80.html
--- manual/html_node/cvs_80.html 8 Jun 2009 20:47:00 -0000 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,55 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Log keyword</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_79.html">previous</A>,
<A HREF="cvs_81.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC82" HREF="cvs_toc.html#TOC82">Problems with the $Log:
cvs_80.html,v $
-<H2><A NAME="SEC82" HREF="cvs_toc.html#TOC82">Problems with the Revision 1.1
2003/11/07 20:55:33 sinuhe
-<H2><A NAME="SEC82" HREF="cvs_toc.html#TOC82">Problems with the Add manual.
-<H2><A NAME="SEC82" HREF="cvs_toc.html#TOC82">Problems with the
keyword.</A></H2>
-
-<P>
-The <CODE>$</CODE>Log$ keyword is somewhat
-controversial. As long as you are working on your
-development system the information is easily accessible
-even if you do not use the <CODE>$</CODE>Log$
-keyword--just do a <CODE>cvs log</CODE>. Once you export
-the file the history information might be useless
-anyhow.
-
-</P>
-<P>
-A more serious concern is that RCS is not good at
-handling <CODE>$</CODE>Log$ entries when a branch is
-merged onto the main trunk. Conflicts often result
-from the merging operation.
-
-</P>
-<P>
-People also tend to "fix" the log entries in the file
-(correcting spelling mistakes and maybe even factual
-errors). If that is done the information from
-<CODE>cvs log</CODE> will not be consistent with the
-information inside the file. This may or may not be a
-problem in real life.
-
-</P>
-<P>
-It has been suggested that the <CODE>$</CODE>Log$
-keyword should be inserted <EM>last</EM> in the file, and
-not in the files header, if it is to be used at all.
-That way the long list of change messages will not
-interfere with everyday source file browsing.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_79.html">previous</A>,
<A HREF="cvs_81.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_81.html
===================================================================
RCS file: manual/html_node/cvs_81.html
diff -N manual/html_node/cvs_81.html
--- manual/html_node/cvs_81.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,111 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Binary files</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_80.html">previous</A>,
<A HREF="cvs_82.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC83" HREF="cvs_toc.html#TOC83">Handling binary files</A></H1>
-<P>
-<A NAME="IDX288"></A>
-
-</P>
-<P>
-There are two issues with using CVS to store
-binary files. The first is that CVS by default
-convert line endings between the canonical form in
-which they are stored in the repository (linefeed
-only), and the form appropriate to the operating system
-in use on the client (for example, carriage return
-followed by line feed for Windows NT).
-
-</P>
-<P>
-The second is that a binary file might happen to
-contain data which looks like a keyword (see section <A
HREF="cvs_75.html#SEC77">Keyword substitution</A>), so keyword expansion must
be turned
-off.
-
-</P>
-<P>
-The <SAMP>`-kb'</SAMP> option available with some CVS
-commands insures that neither line ending conversion
-nor keyword expansion will be done. If you are using
-an old version of RCS without this option, and you
-are using an operating system, such as unix, which
-terminates lines with linefeeds only, you can use
-<SAMP>`-ko'</SAMP> instead; if you are on another operating
-system, upgrade to a version of RCS, such as 5.7
-or later, which supports <SAMP>`-kb'</SAMP>.
-
-</P>
-<P>
-Here is an example of how you can create a new file
-using the <SAMP>`-kb'</SAMP> flag:
-
-</P>
-
-<PRE>
-$ echo '$Id: cvs_81.html,v 1.1 2003/11/07 20:55:33 sinuhe Exp $' > kotest
-$ cvs add -kb -m"A test file" kotest
-$ cvs ci -m"First checkin; contains a keyword" kotest
-</PRE>
-
-<P>
-If a file accidentally gets added without <SAMP>`-kb'</SAMP>,
-one can use the <CODE>cvs admin</CODE> command to recover.
-For example:
-
-</P>
-
-<PRE>
-$ echo '$Id: cvs_81.html,v 1.1 2003/11/07 20:55:33 sinuhe Exp $' > kotest
-$ cvs add -m"A test file" kotest
-$ cvs ci -m"First checkin; contains a keyword" kotest
-$ cvs admin -kb kotest
-$ cvs update -A kotest
-$ cvs commit -m "make it binary" kotest # For non-unix systems
-</PRE>
-
-<P>
-When you check in the file <TT>`kotest'</TT> the keywords
-are expanded. (Try the above example, and do a
-<CODE>cat kotest</CODE> after every command). The <CODE>cvs
-admin -kb</CODE> command sets the default keyword
-substitution method for this file, but it does not
-alter the working copy of the file that you have. The
-easiest way to get the unexpanded version of
-<TT>`kotest'</TT> is <CODE>cvs update -A</CODE>. If you need to
-cope with line endings (that is, you are using a
-CVS client on a non-unix system), then you need to
-check in a new copy of the file, as shown by the
-<CODE>cvs commit</CODE> command above.
-
-</P>
-<P>
-However, in using <CODE>cvs admin -k</CODE> to change the
-keyword expansion, be aware that the keyword expansion
-mode is not version controlled. This means that, for
-example, that if you have a text file in old releases,
-and a binary file with the same name in new releases,
-CVS provides no way to check out the file in text
-or binary mode depending on what version you are
-checking out. There is no good workaround for this
-problem.
-
-</P>
-<P>
-You can also set a default for whether <CODE>cvs add</CODE>
-and <CODE>cvs import</CODE> treat a file as binary based on
-its name; for example you could say that files who
-names end in <SAMP>`.exe'</SAMP> are binary. See section <A
HREF="cvs_131.html#SEC138">The cvswrappers file</A>.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_80.html">previous</A>,
<A HREF="cvs_82.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_82.html
===================================================================
RCS file: manual/html_node/cvs_82.html
diff -N manual/html_node/cvs_82.html
--- manual/html_node/cvs_82.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,37 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Revision management</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_81.html">previous</A>,
<A HREF="cvs_83.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC84" HREF="cvs_toc.html#TOC84">Revision management</A></H1>
-<P>
-<A NAME="IDX289"></A>
-
-</P>
-
-<P>
-If you have read this far, you probably have a pretty
-good grasp on what CVS can do for you. This
-chapter talks a little about things that you still have
-to decide.
-
-</P>
-<P>
-If you are doing development on your own using CVS
-you could probably skip this chapter. The questions
-this chapter takes up become more important when more
-than one person is working in a repository.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_81.html">previous</A>,
<A HREF="cvs_83.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_83.html
===================================================================
RCS file: manual/html_node/cvs_83.html
diff -N manual/html_node/cvs_83.html
--- manual/html_node/cvs_83.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,52 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - When to commit</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_82.html">previous</A>,
<A HREF="cvs_84.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC85" HREF="cvs_toc.html#TOC85">When to commit?</A></H2>
-<P>
-<A NAME="IDX290"></A>
-<A NAME="IDX291"></A>
-<A NAME="IDX292"></A>
-
-</P>
-<P>
-Your group should decide which policy to use regarding
-commits. Several policies are possible, and as your
-experience with CVS grows you will probably find
-out what works for you.
-
-</P>
-<P>
-If you commit files too quickly you might commit files
-that do not even compile. If your partner updates his
-working sources to include your buggy file, he will be
-unable to compile the code. On the other hand, other
-persons will not be able to benefit from the
-improvements you make to the code if you commit very
-seldom, and conflicts will probably be more common.
-
-</P>
-<P>
-It is common to only commit files after making sure
-that they can be compiled. Some sites require that the
-files pass a test suite. Policies like this can be
-enforced using the commitinfo file
-(see section <A HREF="cvs_134.html#SEC141">Commitinfo</A>), but you should
think twice before
-you enforce such a convention. By making the
-development environment too controlled it might become
-too regimented and thus counter-productive to the real
-goal, which is to get software written.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_82.html">previous</A>,
<A HREF="cvs_84.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_84.html
===================================================================
RCS file: manual/html_node/cvs_84.html
diff -N manual/html_node/cvs_84.html
--- manual/html_node/cvs_84.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,32 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Invoking CVS</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_83.html">previous</A>,
<A HREF="cvs_85.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC86" HREF="cvs_toc.html#TOC86">Reference manual for CVS
commands</A></H1>
-<P>
-<A NAME="IDX293"></A>
-<A NAME="IDX294"></A>
-<A NAME="IDX295"></A>
-
-</P>
-
-<P>
-This appendix describes how to invoke CVS, and
-describes in detail those subcommands of CVS which
-are not fully described elsewhere. To look up a
-particular subcommand, see section <A HREF="cvs_148.html#SEC155">Index</A>.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_83.html">previous</A>,
<A HREF="cvs_85.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_85.html
===================================================================
RCS file: manual/html_node/cvs_85.html
diff -N manual/html_node/cvs_85.html
--- manual/html_node/cvs_85.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,73 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Structure</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_84.html">previous</A>,
<A HREF="cvs_86.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC87" HREF="cvs_toc.html#TOC87">Overall structure of CVS
commands</A></H2>
-<P>
-<A NAME="IDX296"></A>
-<A NAME="IDX297"></A>
-<A NAME="IDX298"></A>
-<A NAME="IDX299"></A>
-
-</P>
-<P>
-The overall format of all CVS commands is:
-
-</P>
-
-<PRE>
-cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
-</PRE>
-
-<DL COMPACT>
-
-<DT><CODE>cvs</CODE>
-<DD>
-The name of the CVS program.
-
-<DT><CODE>cvs_options</CODE>
-<DD>
-Some options that affect all sub-commands of CVS. These are
-described below.
-
-<DT><CODE>cvs_command</CODE>
-<DD>
-One of several different sub-commands. Some of the commands have
-aliases that can be used instead; those aliases are noted in the
-reference manual for that command. There are only two situations
-where you may omit <SAMP>`cvs_command'</SAMP>: <SAMP>`cvs -H'</SAMP> elicits a
-list of available commands, and <SAMP>`cvs -v'</SAMP> displays version
-information on CVS itself.
-
-<DT><CODE>command_options</CODE>
-<DD>
-Options that are specific for the command.
-
-<DT><CODE>command_args</CODE>
-<DD>
-Arguments to the commands.
-</DL>
-
-<P>
-There is unfortunately some confusion between
-<CODE>cvs_options</CODE> and <CODE>command_options</CODE>.
-<SAMP>`-l'</SAMP>, when given as a <CODE>cvs_option</CODE>, only
-affects some of the commands. When it is given as a
-<CODE>command_option</CODE> is has a different meaning, and
-is accepted by more commands. In other words, do not
-take the above categorization too seriously. Look at
-the documentation instead.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_84.html">previous</A>,
<A HREF="cvs_86.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_86.html
===================================================================
RCS file: manual/html_node/cvs_86.html
diff -N manual/html_node/cvs_86.html
--- manual/html_node/cvs_86.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,96 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - ~/.cvsrc</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_85.html">previous</A>,
<A HREF="cvs_87.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC88" HREF="cvs_toc.html#TOC88">Default options and the ~/.cvsrc
file</A></H2>
-<P>
-<A NAME="IDX300"></A>
-<A NAME="IDX301"></A>
-
-</P>
-<P>
-There are some <CODE>command_options</CODE> that are used so
-often that you might have set up an alias or some other
-means to make sure you always specify that option. One
-example (the one that drove the implementation of the
-.cvsrc support, actually) is that many people find the
-default output of the <SAMP>`diff'</SAMP> command to be very
-hard to read, and that either context diffs or unidiffs
-are much easier to understand.
-
-</P>
-<P>
-The <TT>`~/.cvsrc'</TT> file is a way that you can add
-default options to <CODE>cvs_commands</CODE> within cvs,
-instead of relying on aliases or other shell scripts.
-
-</P>
-<P>
-The format of the <TT>`~/.cvsrc'</TT> file is simple. The
-file is searched for a line that begins with the same
-name as the <CODE>cvs_command</CODE> being executed. If a
-match is found, then the remainder of the line is split
-up (at whitespace characters) into separate options and
-added to the command arguments <EM>before</EM> any
-options from the command line.
-
-</P>
-<P>
-If a command has two names (e.g., <CODE>checkout</CODE> and
-<CODE>co</CODE>), the official name, not necessarily the one
-used on the command line, will be used to match against
-the file. So if this is the contents of the user's
-<TT>`~/.cvsrc'</TT> file:
-
-</P>
-
-<PRE>
-log -N
-diff -u
-update -P
-co -P
-</PRE>
-
-<P>
-the command <SAMP>`cvs checkout foo'</SAMP> would have the
-<SAMP>`-P'</SAMP> option added to the arguments, as well as
-<SAMP>`cvs co foo'</SAMP>.
-
-</P>
-<P>
-With the example file above, the output from <SAMP>`cvs
-diff foobar'</SAMP> will be in unidiff format. <SAMP>`cvs diff
--c foobar'</SAMP> will provide context diffs, as usual.
-Getting "old" format diffs would be slightly more
-complicated, because <CODE>diff</CODE> doesn't have an option
-to specify use of the "old" format, so you would need
-<SAMP>`cvs -f diff foobar'</SAMP>.
-
-</P>
-<P>
-In place of the command name you can use <CODE>cvs</CODE> to
-specify global options (see section <A HREF="cvs_87.html#SEC89">Global
options</A>). For
-example the following line in <TT>`.cvsrc'</TT>
-
-</P>
-
-<PRE>
-cvs -z6
-</PRE>
-
-<P>
-causes CVS to use compression level 6
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_85.html">previous</A>,
<A HREF="cvs_87.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_87.html
===================================================================
RCS file: manual/html_node/cvs_87.html
diff -N manual/html_node/cvs_87.html
--- manual/html_node/cvs_87.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,155 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Global options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_86.html">previous</A>,
<A HREF="cvs_88.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC89" HREF="cvs_toc.html#TOC89">Global options</A></H2>
-<P>
-<A NAME="IDX302"></A>
-<A NAME="IDX303"></A>
-<A NAME="IDX304"></A>
-
-</P>
-<P>
-The available <SAMP>`cvs_options'</SAMP> (that are given to the
-left of <SAMP>`cvs_command'</SAMP>) are:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-b <VAR>bindir</VAR></CODE>
-<DD>
-<A NAME="IDX305"></A>
- <A NAME="IDX306"></A>
-
-Use <VAR>bindir</VAR> as the directory where RCS programs are
-located. Overrides the setting of the <CODE>$RCSBIN</CODE> environment
-variable and any precompiled directory. This parameter should be
-specified as an absolute pathname.
-
-<A NAME="IDX307"></A>
-<A NAME="IDX308"></A>
-<DT><CODE>-T <VAR>tempdir</VAR></CODE>
-<DD>
-Use <VAR>tempdir</VAR> as the directory where temporary files are
-located. Overrides the setting of the <CODE>$TMPDIR</CODE> environment
-variable and any precompiled directory. This parameter should be
-specified as an absolute pathname.
-
-<A NAME="IDX309"></A>
-<A NAME="IDX310"></A>
-<DT><CODE>-d <VAR>cvs_root_directory</VAR></CODE>
-<DD>
-Use <VAR>cvs_root_directory</VAR> as the root directory
-pathname of the repository. Overrides the setting of
-the <CODE>$CVSROOT</CODE> environment variable. See section <A
HREF="cvs_14.html#SEC15">The Repository</A>.
-
-<A NAME="IDX311"></A>
-<A NAME="IDX312"></A>
-<DT><CODE>-e <VAR>editor</VAR></CODE>
-<DD>
-Use <VAR>editor</VAR> to enter revision log information. Overrides the
-setting of the <CODE>$CVSEDITOR</CODE> and <CODE>$EDITOR</CODE> environment
variables.
-
-<DT><CODE>-f</CODE>
-<DD>
-Do not read the <TT>`~/.cvsrc'</TT> file. This
-option is most often used because of the
-non-orthogonality of the CVS option set. For
-example, the <SAMP>`cvs log'</SAMP> option <SAMP>`-N'</SAMP> (turn off
-display of tag names) does not have a corresponding
-option to turn the display on. So if you have
-<SAMP>`-N'</SAMP> in the <TT>`~/.cvsrc'</TT> entry for <SAMP>`log'</SAMP>,
-you may need to use <SAMP>`-f'</SAMP> to show the tag names.
-
-<DT><CODE>-H</CODE>
-<DD>
-Display usage information about the specified <SAMP>`cvs_command'</SAMP>
-(but do not actually execute the command). If you don't specify
-a command name, <SAMP>`cvs -H'</SAMP> displays a summary of all the
-commands available.
-
-<DT><CODE>-l</CODE>
-<DD>
-Do not log the cvs_command in the command history (but execute it
-anyway). See section <A HREF="cvs_103.html#SEC110">history--Show status of
files and users</A>, for information on command history.
-
-<A NAME="IDX313"></A>
-<DT><CODE>-n</CODE>
-<DD>
-Do not change any files. Attempt to execute the
-<SAMP>`cvs_command'</SAMP>, but only to issue reports; do not remove,
-update, or merge any existing files, or create any new files.
-
-<DT><CODE>-Q</CODE>
-<DD>
-Cause the command to be really quiet; the command will only
-generate output for serious problems.
-
-<DT><CODE>-q</CODE>
-<DD>
-Cause the command to be somewhat quiet; informational messages,
-such as reports of recursion through subdirectories, are
-suppressed.
-
-<A NAME="IDX314"></A>
-<DT><CODE>-r</CODE>
-<DD>
-Make new working files files read-only. Same effect
-as if the <CODE>$CVSREAD</CODE> environment variable is set
-(see section <A HREF="cvs_144.html#SEC151">All environment variables which
affect CVS</A>). The default is to
-make working files writable, unless watches are on
-(see section <A HREF="cvs_41.html#SEC43">Mechanisms to track who is editing
files</A>).
-
-<DT><CODE>-s <VAR>variable</VAR>=<VAR>value</VAR></CODE>
-<DD>
-Set a user variable (see section <A HREF="cvs_143.html#SEC150">Expansions in
administrative files</A>).
-
-<A NAME="IDX315"></A>
-<DT><CODE>-t</CODE>
-<DD>
-Trace program execution; display messages showing the steps of
-CVS activity. Particularly useful with <SAMP>`-n'</SAMP> to explore the
-potential impact of an unfamiliar command.
-
-<DT><CODE>-v</CODE>
-<DD>
-Display version and copyright information for CVS.
-
-<A NAME="IDX316"></A>
-<A NAME="IDX317"></A>
-<DT><CODE>-w</CODE>
-<DD>
-Make new working files read-write. Overrides the
-setting of the <CODE>$CVSREAD</CODE> environment variable.
-Files are created read-write by default, unless <CODE>$CVSREAD</CODE> is
-set or <SAMP>`-r'</SAMP> is given.
-
-<DT><CODE>-x</CODE>
-<DD>
-Encrypt all communication between the client and the
-server. Only has an effect on the CVS client. As
-of this writing, this is only implemented when using a
-Kerberos connection (see section <A HREF="cvs_28.html#SEC30">Direct connection
with kerberos</A>).
-Encryption support is not available by default; it must
-be enabled using a special configure option,
-<TT>`--enable-encryption'</TT>, when you build CVS.
-
-<DT><CODE>-z <VAR>gzip-level</VAR></CODE>
-<DD>
-Set the compression level. Only has an effect on the
-CVS client.
-
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_86.html">previous</A>,
<A HREF="cvs_88.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_88.html
===================================================================
RCS file: manual/html_node/cvs_88.html
diff -N manual/html_node/cvs_88.html
--- manual/html_node/cvs_88.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,231 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Common options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_87.html">previous</A>,
<A HREF="cvs_89.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC90" HREF="cvs_toc.html#TOC90">Common command options</A></H2>
-<P>
-<A NAME="IDX318"></A>
-<A NAME="IDX319"></A>
-
-</P>
-<P>
-This section describes the <SAMP>`command_options'</SAMP> that
-are available across several CVS commands. These
-options are always given to the right of
-<SAMP>`cvs_command'</SAMP>. Not all
-commands support all of these options; each option is
-only supported for commands where it makes sense.
-However, when a command has one of these options you
-can almost always count on the same behavior of the
-option as in other commands. (Other command options,
-which are listed with the individual commands, may have
-different behavior from one CVS command to the other).
-
-</P>
-<P>
-<STRONG>Warning:</STRONG> the <SAMP>`history'</SAMP> command is an exception;
it supports
-many options that conflict even with these standard options.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date_spec</VAR></CODE>
-<DD>
-<A NAME="IDX320"></A>
- <A NAME="IDX321"></A>
- <A NAME="IDX322"></A>
-
-Use the most recent revision no later than <VAR>date_spec</VAR>.
-<VAR>date_spec</VAR> is a single argument, a date description
-specifying a date in the past.
-
-The specification is <EM>sticky</EM> when you use it to make a
-private copy of a source file; that is, when you get a working
-file using <SAMP>`-D'</SAMP>, CVS records the date you specified, so that
-further updates in the same directory will use the same date
-(for more information on sticky tags/dates, see section <A
HREF="cvs_52.html#SEC54">Sticky tags</A>).
-
-<A NAME="IDX323"></A>
-<A NAME="IDX324"></A>
-A wide variety of date formats are supported by
-CVS. The <VAR>date_spec</VAR> is interpreted as being
-in the local timezone, unless a specific timezone is
-specified. Examples of valid date specifications
-include:
-
-
-<PRE>
- 1 month ago
- 2 hours ago
- 400000 seconds ago
- last year
- last Monday
- yesterday
- a fortnight ago
- 3/31/92 10:00:07 PST
- January 23, 1987 10:05pm
- 22:00 GMT
-</PRE>
-
-<SAMP>`-D'</SAMP> is available with the <CODE>checkout</CODE>,
-<CODE>diff</CODE>, <CODE>export</CODE>, <CODE>history</CODE>,
-<CODE>rdiff</CODE>, <CODE>rtag</CODE>, and <CODE>update</CODE> commands.
-(The <CODE>history</CODE> command uses this option in a
-slightly different way; see section <A HREF="cvs_104.html#SEC111">history
options</A>). Note
-that when specifying a date like <SAMP>`3/31/92'</SAMP> it is
-<CODE><VAR>month</VAR>/<VAR>day</VAR>/<VAR>year</VAR></CODE>. So
-<SAMP>`1/4/96'</SAMP> is January 4, not March 1.
-
-Remember to quote the argument to the <SAMP>`-D'</SAMP>
-flag so that your shell doesn't interpret spaces as
-argument separators. A command using the <SAMP>`-D'</SAMP>
-flag can look like this:
-
-
-<PRE>
-$ cvs diff -D "1 hour ago" cvs.texinfo
-</PRE>
-
-<A NAME="IDX325"></A>
-<DT><CODE>-f</CODE>
-<DD>
-When you specify a particular date or tag to CVS commands, they
-normally ignore files that do not contain the tag (or did not
-exist prior to the date) that you specified. Use the <SAMP>`-f'</SAMP> option
-if you want files retrieved even when there is no match for the
-tag or date. (The most recent revision of the file
-will be used).
-
-<SAMP>`-f'</SAMP> is available with these commands: <CODE>checkout</CODE>,
-<CODE>export</CODE>, <CODE>rdiff</CODE>, <CODE>rtag</CODE>, and
<CODE>update</CODE>.
-
-<STRONG>Warning:</STRONG> The <CODE>commit</CODE> command also has a
-<SAMP>`-f'</SAMP> option, but it has a different behavior for
-that command. See section <A HREF="cvs_96.html#SEC100">commit options</A>.
-
-<DT><CODE>-H</CODE>
-<DD>
-Help; describe the options available for this command. This is
-the only option supported for all CVS commands.
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Alter the default RCS processing of keywords.
-See section <A HREF="cvs_75.html#SEC77">Keyword substitution</A>, for the
meaning of
-<VAR>kflag</VAR>. Your <VAR>kflag</VAR> specification is
-<EM>sticky</EM> when you use it to create a private copy
-of a source file; that is, when you use this option
-with the <CODE>checkout</CODE> or <CODE>update</CODE> commands,
-CVS associates your selected <VAR>kflag</VAR> with the
-file, and continues to use it with future update
-commands on the same file until you specify otherwise.
-
-The <SAMP>`-k'</SAMP> option is available with the <CODE>add</CODE>,
-<CODE>checkout</CODE>, <CODE>diff</CODE> and
-<CODE>update</CODE> commands.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory, rather than
-recursing through subdirectories.
-
-<STRONG>Warning:</STRONG> this is not the same
-as the overall <SAMP>`cvs -l'</SAMP> option, which you can specify to the
-left of a cvs command!
-
-Available with the following commands: <CODE>checkout</CODE>,
-<CODE>commit</CODE>, <CODE>diff</CODE>, <CODE>export</CODE>, <CODE>log</CODE>,
-<CODE>remove</CODE>, <CODE>rdiff</CODE>, <CODE>rtag</CODE>,
-<CODE>status</CODE>, <CODE>tag</CODE>, and <CODE>update</CODE>.
-
-<A NAME="IDX326"></A>
-<A NAME="IDX327"></A>
-<DT><CODE>-m <VAR>message</VAR></CODE>
-<DD>
-Use <VAR>message</VAR> as log information, instead of
-invoking an editor.
-
-Available with the following commands: <CODE>add</CODE>,
-<CODE>commit</CODE> and <CODE>import</CODE>.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any checkout/commit/tag program. (A program can be
-specified to run on each of these activities, in the modules
-database (see section <A HREF="cvs_130.html#SEC137">The modules file</A>);
this option bypasses it).
-
-<STRONG>Warning:</STRONG> this is not the same as the overall <SAMP>`cvs
-n'</SAMP>
-option, which you can specify to the left of a cvs command!
-
-Available with the <CODE>checkout</CODE>, <CODE>commit</CODE>,
<CODE>export</CODE>,
-and <CODE>rtag</CODE> commands.
-
-<DT><CODE>-P</CODE>
-<DD>
-Prune (remove) directories that are empty after being updated, on
-<CODE>checkout</CODE>, or <CODE>update</CODE>. Normally, an empty directory
-(one that is void of revision-controlled files) is left alone.
-Specifying <SAMP>`-P'</SAMP> will cause these directories to be silently
-removed from your checked-out sources. This does not remove the
-directory from the repository, only from your checked out copy.
-Note that this option is implied by the <SAMP>`-r'</SAMP> or <SAMP>`-D'</SAMP>
-options of <CODE>checkout</CODE> and <CODE>export</CODE>.
-
-<DT><CODE>-p</CODE>
-<DD>
-Pipe the files retrieved from the repository to standard output,
-rather than writing them in the current directory. Available
-with the <CODE>checkout</CODE> and <CODE>update</CODE> commands.
-
-<DT><CODE>-W</CODE>
-<DD>
-Specify file names that should be filtered. You can
-use this option repeatedly. The spec can be a file
-name pattern of the same type that you can specify in
-the <TT>`.cvswrappers'</TT> file.
-Avaliable with the following commands: <CODE>import</CODE>,
-and <CODE>update</CODE>.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use the revision specified by the <VAR>tag</VAR> argument instead of the
-default <EM>head</EM> revision. As well as arbitrary tags defined
-with the <CODE>tag</CODE> or <CODE>rtag</CODE> command, two special tags are
-always available: <SAMP>`HEAD'</SAMP> refers to the most recent version
-available in the repository, and <SAMP>`BASE'</SAMP> refers to the
-revision you last checked out into the current working directory.
-
-The tag specification is sticky when you use this
-with <CODE>checkout</CODE> or <CODE>update</CODE> to make your own
-copy of a file: CVS remembers the tag and continues to use it on
-future update commands, until you specify otherwise (for more information
-on sticky tags/dates, see section <A HREF="cvs_52.html#SEC54">Sticky
tags</A>). The
-tag can be either a symbolic or numeric tag.
-See section <A HREF="cvs_49.html#SEC51">Tags--Symbolic revisions</A>.
-
-Specifying the <SAMP>`-q'</SAMP> global option along with the
-<SAMP>`-r'</SAMP> command option is often useful, to suppress
-the warning messages when the RCS history file
-does not contain the specified tag.
-
-<STRONG>Warning:</STRONG> this is not the same as the overall `cvs -r' option,
-which you can specify to the left of a cvs command!
-
-<SAMP>`-r'</SAMP> is available with the <CODE>checkout</CODE>,
<CODE>commit</CODE>,
-<CODE>diff</CODE>, <CODE>history</CODE>, <CODE>export</CODE>,
<CODE>rdiff</CODE>,
-<CODE>rtag</CODE>, and <CODE>update</CODE> commands.
-
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_87.html">previous</A>,
<A HREF="cvs_89.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_89.html
===================================================================
RCS file: manual/html_node/cvs_89.html
diff -N manual/html_node/cvs_89.html
--- manual/html_node/cvs_89.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,51 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - admin</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_88.html">previous</A>,
<A HREF="cvs_90.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC91" HREF="cvs_toc.html#TOC91">admin--Administration front end
for rcs</A></H2>
-<P>
-<A NAME="IDX328"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Requires: repository, working directory.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: rcs
-</UL>
-
-<P>
-This is the CVS interface to assorted administrative RCS
-facilities, documented in rcs(1). <CODE>admin</CODE> simply passes
-all its options and arguments to the <CODE>rcs</CODE> command; it does
-no filtering or other processing. This command <EM>does</EM> work
-recursively, however, so extreme care should be used.
-
-</P>
-<P>
-If there is a group whose name matches a compiled in
-value which defaults to <CODE>cvsadmin</CODE>, only members
-of that group can use <CODE>cvs admin</CODE>. To disallow
-<CODE>cvs admin</CODE> for all users, create a group with no
-users in it.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_88.html">previous</A>,
<A HREF="cvs_90.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_9.html
===================================================================
RCS file: manual/html_node/cvs_9.html
diff -N manual/html_node/cvs_9.html
--- manual/html_node/cvs_9.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,41 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - A sample session</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_8.html">previous</A>,
<A HREF="cvs_10.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H1><A NAME="SEC10" HREF="cvs_toc.html#TOC10">A sample session</A></H1>
-<P>
-<A NAME="IDX35"></A>
-<A NAME="IDX36"></A>
-<A NAME="IDX37"></A>
-<A NAME="IDX38"></A>
-<A NAME="IDX39"></A>
-<A NAME="IDX40"></A>
-
-</P>
-<P>
-This section describes a typical work-session using
-CVS. It assumes that a repository is set up
-(see section <A HREF="cvs_14.html#SEC15">The Repository</A>).
-
-</P>
-<P>
-Suppose you are working on a simple compiler. The source
-consists of a handful of C files and a <TT>`Makefile'</TT>.
-The compiler is called <SAMP>`tc'</SAMP> (Trivial Compiler),
-and the repository is set up so that there is a module
-called <SAMP>`tc'</SAMP>.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_8.html">previous</A>,
<A HREF="cvs_10.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_90.html
===================================================================
RCS file: manual/html_node/cvs_90.html
diff -N manual/html_node/cvs_90.html
--- manual/html_node/cvs_90.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,257 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - admin options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_89.html">previous</A>,
<A HREF="cvs_91.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC92" HREF="cvs_toc.html#TOC92">admin options</A></H3>
-
-<P>
-Not all valid <CODE>rcs</CODE> options are useful together
-with CVS. Some even makes it impossible to use
-CVS until you undo the effect!
-
-</P>
-<P>
-This description of the available options is based on
-the <SAMP>`rcs(1)'</SAMP> man page, but modified to suit
-readers that are more interrested in CVS than
-RCS.
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-A<VAR>oldfile</VAR></CODE>
-<DD>
-Might not work together with CVS. Append the
-access list of <VAR>oldfile</VAR> to the access list of the
-RCS file.
-
-<DT><CODE>-a<VAR>logins</VAR></CODE>
-<DD>
-Might not work together with CVS. Append the
-login names appearing in the comma-separated list
-<VAR>logins</VAR> to the access list of the RCS file.
-
-<DT><CODE>-b[<VAR>rev</VAR>]</CODE>
-<DD>
-When used with bare RCS, this
-option sets the default branch to <VAR>rev</VAR>; in
-CVS sticky tags (see section <A HREF="cvs_52.html#SEC54">Sticky tags</A>) are
a better
-way to decide which branch you want to work on. With
-CVS, this option can be used to control behavior
-with respect to the vendor branch.
-
-<DT><CODE>-c<VAR>string</VAR></CODE>
-<DD>
-Useful with CVS. Sets the comment leader to
-<VAR>string</VAR>. The comment leader is printed before
-every log message line generated by the keyword
-<CODE>$</CODE>Log$ (see section <A HREF="cvs_75.html#SEC77">Keyword
substitution</A>).
-This is useful for programming languages without
-multi-line comments. RCS initially guesses the
-value of the comment leader from the file name
-extension when the file is first committed.
-
-<DT><CODE>-e[<VAR>logins</VAR>]</CODE>
-<DD>
-Might not work together with CVS. Erase the login
-names appearing in the comma-separated list
-<VAR>logins</VAR> from the access list of the RCS file. If
-<VAR>logins</VAR> is omitted, erase the entire access list.
-
-<DT><CODE>-I</CODE>
-<DD>
-Run interactively, even if the standard input is not a
-terminal.
-
-<DT><CODE>-i</CODE>
-<DD>
-Useless with CVS. When using bare RCS, this
-is used to create and initialize a new RCS file,
-without depositing a revision.
-
-<DT><CODE>-k<VAR>subst</VAR></CODE>
-<DD>
-Useful with CVS. Set the default keyword
-substitution to <VAR>subst</VAR>. See section <A
HREF="cvs_75.html#SEC77">Keyword substitution</A>. Giving an explicit
<SAMP>`-k'</SAMP> option to
-<CODE>cvs update</CODE>, <CODE>cvs export</CODE>, or <CODE>cvs
-checkout</CODE> overrides this default.
-
-<DT><CODE>-l[<VAR>rev</VAR>]</CODE>
-<DD>
-Lock the revision with number <VAR>rev</VAR>. If a branch
-is given, lock the latest revision on that branch. If
-<VAR>rev</VAR> is omitted, lock the latest revision on the
-default branch.
-
-This can be used in conjunction with the
-<TT>`rcslock.pl'</TT> script in the <TT>`contrib'</TT>
-directory of the CVS source distribution to
-provide reserved checkouts (where only one user can be
-editing a given file at a time). See the comments in
-that file for details (and see the <TT>`README'</TT> file
-in that directory for disclaimers about the unsupported
-nature of contrib). According to comments in that
-file, locking must set to strict (which is the default).
-
-<DT><CODE>-L</CODE>
-<DD>
-Set locking to strict. Strict locking means that the
-owner of an RCS file is not exempt from locking for
-checkin. For use with CVS, strict locking must be
-set; see the discussion under the <SAMP>`-l'</SAMP> option above.
-
-<A NAME="IDX329"></A>
-<A NAME="IDX330"></A>
-<A NAME="IDX331"></A>
-<A NAME="IDX332"></A>
-<A NAME="IDX333"></A>
-<DT><CODE>-m<VAR>rev</VAR>:<VAR>msg</VAR></CODE>
-<DD>
-Replace the log message of revision <VAR>rev</VAR> with
-<VAR>msg</VAR>.
-
-<DT><CODE>-N<VAR>name</VAR>[:[<VAR>rev</VAR>]]</CODE>
-<DD>
-Act like <SAMP>`-n'</SAMP>, except override any previous
-assignment of <VAR>name</VAR>.
-
-<DT><CODE>-n<VAR>name</VAR>[:[<VAR>rev</VAR>]]</CODE>
-<DD>
-Associate the symbolic name <VAR>name</VAR> with the branch
-or revision <VAR>rev</VAR>. It is normally better to use
-<SAMP>`cvs tag'</SAMP> or <SAMP>`cvs rtag'</SAMP> instead. Delete the
-symbolic name if both <SAMP>`:'</SAMP> and <VAR>rev</VAR> are
-omitted; otherwise, print an error message if
-<VAR>name</VAR> is already associated with another number.
-If <VAR>rev</VAR> is symbolic, it is expanded before
-association. A <VAR>rev</VAR> consisting of a branch number
-followed by a <SAMP>`.'</SAMP> stands for the current latest
-revision in the branch. A <SAMP>`:'</SAMP> with an empty
-<VAR>rev</VAR> stands for the current latest revision on the
-default branch, normally the trunk. For example,
-<SAMP>`rcs -n<VAR>name</VAR>: RCS/*'</SAMP> associates <VAR>name</VAR> with the
-current latest revision of all the named RCS files;
-this contrasts with <SAMP>`rcs -n<VAR>name</VAR>:$ RCS/*'</SAMP> which
-associates <VAR>name</VAR> with the revision numbers
-extracted from keyword strings in the corresponding
-working files.
-
-<A NAME="IDX334"></A>
-<A NAME="IDX335"></A>
-<A NAME="IDX336"></A>
-<DT><CODE>-o<VAR>range</VAR></CODE>
-<DD>
-Potentially useful, but dangerous, with CVS (see below).
-Deletes (<EM>outdates</EM>) the revisions given by
-<VAR>range</VAR>. A range consisting of a single revision
-number means that revision. A range consisting of a
-branch number means the latest revision on that branch.
-A range of the form <SAMP>`<VAR>rev1</VAR>:<VAR>rev2</VAR>'</SAMP> means
-revisions <VAR>rev1</VAR> to <VAR>rev2</VAR> on the same branch,
-<SAMP>`:<VAR>rev</VAR>'</SAMP> means from the beginning of the
-branch containing <VAR>rev</VAR> up to and including
-<VAR>rev</VAR>, and <SAMP>`<VAR>rev</VAR>:'</SAMP> means from revision
-<VAR>rev</VAR> to the end of the branch containing
-<VAR>rev</VAR>. None of the outdated revisions may have
-branches or locks.
-
-Due to the way CVS handles branches <VAR>rev</VAR>
-cannot be specified symbolically if it is a branch.
-See section <A HREF="cvs_146.html#SEC153">Magic branch numbers</A>, for an
explanation.
-
-Make sure that no-one has checked out a copy of the
-revision you outdate. Strange things will happen if he
-starts to edit it and tries to check it back in. For
-this reason, this option is not a good way to take back
-a bogus commit; commit a new revision undoing the bogus
-change instead (see section <A HREF="cvs_56.html#SEC58">Merging differences
between any two revisions</A>).
-
-<DT><CODE>-q</CODE>
-<DD>
-Run quietly; do not print diagnostics.
-
-<DT><CODE>-s<VAR>state</VAR>[:<VAR>rev</VAR>]</CODE>
-<DD>
-Useful with CVS. Set the state attribute of the
-revision <VAR>rev</VAR> to <VAR>state</VAR>. If <VAR>rev</VAR> is a
-branch number, assume the latest revision on that
-branch. If <VAR>rev</VAR> is omitted, assume the latest
-revision on the default branch. Any identifier is
-acceptable for <VAR>state</VAR>. A useful set of states is
-<SAMP>`Exp'</SAMP> (for experimental), <SAMP>`Stab'</SAMP> (for
-stable), and <SAMP>`Rel'</SAMP> (for released). By default,
-the state of a new revision is set to <SAMP>`Exp'</SAMP> when
-it is created. The state is visible in the output from
-<VAR>cvs log</VAR> (see section <A HREF="cvs_109.html#SEC116">log--Print out
log information for files</A>), and in the
-<SAMP>`$'</SAMP>Log$ and <SAMP>`$'</SAMP>State$ keywords
-(see section <A HREF="cvs_75.html#SEC77">Keyword substitution</A>). Note that
CVS
-uses the <CODE>dead</CODE> state for its own purposes; to
-take a file to or from the <CODE>dead</CODE> state use
-commands like <CODE>cvs remove</CODE> and <CODE>cvs add</CODE>, not
-<CODE>cvs admin -s</CODE>.
-
-<DT><CODE>-t[<VAR>file</VAR>]</CODE>
-<DD>
-Useful with CVS. Write descriptive text from the
-contents of the named <VAR>file</VAR> into the RCS file,
-deleting the existing text. The <VAR>file</VAR> pathname
-may not begin with <SAMP>`-'</SAMP>. If <VAR>file</VAR> is omitted,
-obtain the text from standard input, terminated by
-end-of-file or by a line containing <SAMP>`.'</SAMP> by itself.
-Prompt for the text if interaction is possible; see
-<SAMP>`-I'</SAMP>. The descriptive text can be seen in the
-output from <SAMP>`cvs log'</SAMP> (see section <A
HREF="cvs_109.html#SEC116">log--Print out log information for files</A>).
-
-<DT><CODE>-t-<VAR>string</VAR></CODE>
-<DD>
-Similar to <SAMP>`-t<VAR>file</VAR>'</SAMP>. Write descriptive text
-from the <VAR>string</VAR> into the RCS file, deleting
-the existing text.
-
-<DT><CODE>-U</CODE>
-<DD>
-Set locking to non-strict. Non-strict locking means
-that the owner of a file need not lock a revision for
-checkin. For use with CVS, strict locking must be
-set; see the discussion under the <SAMP>`-l'</SAMP> option
-above.
-
-<DT><CODE>-u[<VAR>rev</VAR>]</CODE>
-<DD>
-See the option <SAMP>`-l'</SAMP> above, for a discussion of
-using this option with CVS. Unlock the revision
-with number <VAR>rev</VAR>. If a branch is given, unlock
-the latest revision on that branch. If <VAR>rev</VAR> is
-omitted, remove the latest lock held by the caller.
-Normally, only the locker of a revision may unlock it.
-Somebody else unlocking a revision breaks the lock.
-This causes a mail message to be sent to the original
-locker. The message contains a commentary solicited
-from the breaker. The commentary is terminated by
-end-of-file or by a line containing <CODE>.</CODE> by itself.
-
-<DT><CODE>-V<VAR>n</VAR></CODE>
-<DD>
-Emulate RCS version <VAR>n</VAR>. Use -V<VAR>n</VAR> to make
-an RCS file acceptable to RCS version <VAR>n</VAR>
-by discarding information that would confuse version
-<VAR>n</VAR>.
-
-<DT><CODE>-x<VAR>suffixes</VAR></CODE>
-<DD>
-Useless with CVS. Use <VAR>suffixes</VAR> to
-characterize RCS files.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_89.html">previous</A>,
<A HREF="cvs_91.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_91.html
===================================================================
RCS file: manual/html_node/cvs_91.html
diff -N manual/html_node/cvs_91.html
--- manual/html_node/cvs_91.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,87 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - admin examples</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_90.html">previous</A>,
<A HREF="cvs_92.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC93" HREF="cvs_toc.html#TOC93">admin examples</A></H3>
-
-
-
-<H4><A NAME="SEC94" HREF="cvs_toc.html#TOC94">Outdating is dangerous</A></H4>
-
-<P>
-First, an example of how <EM>not</EM> to use the
-<CODE>admin</CODE> command. It is included to stress the
-fact that this command can be quite dangerous unless
-you know <EM>exactly</EM> what you are doing.
-
-</P>
-<P>
-The <SAMP>`-o'</SAMP> option can be used to <EM>outdate</EM> old revisions
-from the history file. If you are short on disc this option
-might help you. But think twice before using it--there is no
-way short of restoring the latest backup to undo this command!
-
-</P>
-<P>
-The next line is an example of a command that you would
-<EM>not</EM> like to execute.
-
-</P>
-
-<PRE>
-$ cvs admin -o:R_1_02 .
-</PRE>
-
-<P>
-The above command will delete all revisions up to, and
-including, the revision that corresponds to the tag
-R_1_02. But beware! If there are files that have not
-changed between R_1_02 and R_1_03 the file will have
-<EM>the same</EM> numerical revision number assigned to
-the tags R_1_02 and R_1_03. So not only will it be
-impossible to retrieve R_1_02; R_1_03 will also have to
-be restored from the tapes!
-
-</P>
-
-
-<H4><A NAME="SEC95" HREF="cvs_toc.html#TOC95">Comment leaders</A></H4>
-<P>
-<A NAME="IDX337"></A>
-<A NAME="IDX338"></A>
-<A NAME="IDX339"></A>
-
-</P>
-<P>
-If you use the <CODE>$</CODE>Log$ keyword and you do
-not agree with the guess for comment leader that
-CVS has done, you can enforce your will with
-<CODE>cvs admin -c</CODE>. This might be suitable for
-<CODE>nroff</CODE> source:
-
-</P>
-
-<PRE>
-$ cvs admin -c'.\" ' *.man
-$ rm *.man
-$ cvs update
-</PRE>
-
-<P>
-The two last steps are to make sure that you get the
-versions with correct comment leaders in your working
-files.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_90.html">previous</A>,
<A HREF="cvs_92.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_92.html
===================================================================
RCS file: manual/html_node/cvs_92.html
diff -N manual/html_node/cvs_92.html
--- manual/html_node/cvs_92.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,103 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - checkout</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_91.html">previous</A>,
<A HREF="cvs_93.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC96" HREF="cvs_toc.html#TOC96">checkout--Check out sources for
editing</A></H2>
-<P>
-<A NAME="IDX340"></A>
-<A NAME="IDX341"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: checkout [options] modules...
-<LI>
-
-Requires: repository.
-<LI>
-
-Changes: working directory.
-<LI>
-
-Synonyms: co, get
-</UL>
-
-<P>
-Make a working directory containing copies of the
-source files specified by <VAR>modules</VAR>. You must execute
-<CODE>checkout</CODE> before using most of the other CVS
-commands, since most of them operate on your working
-directory.
-
-</P>
-<P>
-The <VAR>modules</VAR> part of the command are either
-symbolic names for some
-collection of source directories and files, or paths to
-directories or files in the repository. The symbolic
-names are defined in the <SAMP>`modules'</SAMP> file.
-See section <A HREF="cvs_130.html#SEC137">The modules file</A>.
-
-</P>
-<P>
-Depending on the modules you specify, <CODE>checkout</CODE> may
-recursively create directories and populate them with
-the appropriate source files. You can then edit these
-source files at any time (regardless of whether other
-software developers are editing their own copies of the
-sources); update them to include new changes applied by
-others to the source repository; or commit your work as
-a permanent change to the source repository.
-
-</P>
-<P>
-Note that <CODE>checkout</CODE> is used to create
-directories. The top-level directory created is always
-added to the directory where <CODE>checkout</CODE> is
-invoked, and usually has the same name as the specified
-module. In the case of a module alias, the created
-sub-directory may have a different name, but you can be
-sure that it will be a sub-directory, and that
-<CODE>checkout</CODE> will show the relative path leading to
-each file as it is extracted into your private work
-area (unless you specify the <SAMP>`-Q'</SAMP> global option).
-
-</P>
-<P>
-The files created by <CODE>checkout</CODE> are created
-read-write, unless the <SAMP>`-r'</SAMP> option to CVS
-(see section <A HREF="cvs_87.html#SEC89">Global options</A>) is specified, the
-<CODE>CVSREAD</CODE> environment variable is specified
-(see section <A HREF="cvs_144.html#SEC151">All environment variables which
affect CVS</A>), or a watch is in
-effect for that file (see section <A HREF="cvs_41.html#SEC43">Mechanisms to
track who is editing files</A>).
-
-</P>
-<P>
-Running <CODE>checkout</CODE> on a directory that was already
-built by a prior <CODE>checkout</CODE> is also permitted, and
-has the same effect as specifying the <SAMP>`-d'</SAMP> option
-to the <CODE>update</CODE> command, that is, any new
-directories that have been created in the repository
-will appear in your work area. See section <A
HREF="cvs_125.html#SEC132">update--Bring work tree in sync with repository</A>.
-
-</P>
-<P>
-For the output produced by the <CODE>checkout</CODE> command
-see section <A HREF="cvs_127.html#SEC134">update output</A>.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_91.html">previous</A>,
<A HREF="cvs_93.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_93.html
===================================================================
RCS file: manual/html_node/cvs_93.html
diff -N manual/html_node/cvs_93.html
--- manual/html_node/cvs_93.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,135 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - checkout options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_92.html">previous</A>,
<A HREF="cvs_94.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC97" HREF="cvs_toc.html#TOC97">checkout options</A></H3>
-
-<P>
-These standard options are supported by <CODE>checkout</CODE>
-(see section <A HREF="cvs_88.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-This option is sticky, and implies <SAMP>`-P'</SAMP>. See
-section <A HREF="cvs_52.html#SEC54">Sticky tags</A>, for more information on
sticky tags/dates.
-
-<DT><CODE>-f</CODE>
-<DD>
-Only useful with the <SAMP>`-D <VAR>date</VAR>'</SAMP> or <SAMP>`-r
-<VAR>tag</VAR>'</SAMP> flags. If no matching revision is found,
-retrieve the most recent revision (instead of ignoring
-the file).
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Process RCS keywords according to <VAR>kflag</VAR>. See
-co(1). This option is sticky; future updates of
-this file in this working directory will use the same
-<VAR>kflag</VAR>. The <CODE>status</CODE> command can be viewed
-to see the sticky options. See section <A
HREF="cvs_121.html#SEC128">status--Display status information on checked out
files</A>.
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any checkout program (as specified
-with the <SAMP>`-o'</SAMP> option in the modules file;
-see section <A HREF="cvs_130.html#SEC137">The modules file</A>).
-
-<DT><CODE>-P</CODE>
-<DD>
-Prune empty directories.
-
-<DT><CODE>-p</CODE>
-<DD>
-Pipe files to the standard output.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Use revision <VAR>tag</VAR>. This option is sticky, and implies
<SAMP>`-P'</SAMP>.
-See section <A HREF="cvs_52.html#SEC54">Sticky tags</A>, for more information
on sticky tags/dates.
-</DL>
-
-<P>
-In addition to those, you can use these special command
-options with <CODE>checkout</CODE>:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-A</CODE>
-<DD>
-Reset any sticky tags, dates, or <SAMP>`-k'</SAMP> options.
-See section <A HREF="cvs_52.html#SEC54">Sticky tags</A>, for more information
on sticky tags/dates.
-
-<DT><CODE>-c</CODE>
-<DD>
-Copy the module file, sorted, to the standard output,
-instead of creating or modifying any files or
-directories in your working directory.
-
-<DT><CODE>-d <VAR>dir</VAR></CODE>
-<DD>
-Create a directory called <VAR>dir</VAR> for the working
-files, instead of using the module name. Unless you
-also use <SAMP>`-N'</SAMP>, the paths created under <VAR>dir</VAR>
-will be as short as possible.
-
-<DT><CODE>-j <VAR>tag</VAR></CODE>
-<DD>
-With two <SAMP>`-j'</SAMP> options, merge changes from the
-revision specified with the first <SAMP>`-j'</SAMP> option to
-the revision specified with the second <SAMP>`j'</SAMP> option,
-into the working directory.
-
-With one <SAMP>`-j'</SAMP> option, merge changes from the
-ancestor revision to the revision specified with the
-<SAMP>`-j'</SAMP> option, into the working directory. The
-ancestor revision is the common ancestor of the
-revision which the working directory is based on, and
-the revision specified in the <SAMP>`-j'</SAMP> option.
-
-In addition, each -j option can contain an optional
-date specification which, when used with branches, can
-limit the chosen revision to one within a specific
-date. An optional date is specified by adding a colon
-(:) to the tag:
-<SAMP>`-j<VAR>Symbolic_Tag</VAR>:<VAR>Date_Specifier</VAR>'</SAMP>.
-
-See section <A HREF="cvs_53.html#SEC55">Merging</A>.
-
-<DT><CODE>-N</CODE>
-<DD>
-Only useful together with <SAMP>`-d <VAR>dir</VAR>'</SAMP>. With this
-option, CVS will not shorten module paths in your
-working directory. (Normally, CVS shortens paths as
-much as possible when you specify an explicit target
-directory).
-
-<DT><CODE>-s</CODE>
-<DD>
-Like <SAMP>`-c'</SAMP>, but include the status of all modules,
-and sort it by the status string. See section <A
HREF="cvs_130.html#SEC137">The modules file</A>, for
-info about the <SAMP>`-s'</SAMP> option that is used inside the
-modules file to set the module status.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_92.html">previous</A>,
<A HREF="cvs_94.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_94.html
===================================================================
RCS file: manual/html_node/cvs_94.html
diff -N manual/html_node/cvs_94.html
--- manual/html_node/cvs_94.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,37 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - checkout examples</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_93.html">previous</A>,
<A HREF="cvs_95.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC98" HREF="cvs_toc.html#TOC98">checkout examples</A></H3>
-
-<P>
-Get a copy of the module <SAMP>`tc'</SAMP>:
-
-</P>
-
-<PRE>
-$ cvs checkout tc
-</PRE>
-
-<P>
-Get a copy of the module <SAMP>`tc'</SAMP> as it looked one day
-ago:
-
-</P>
-
-<PRE>
-$ cvs checkout -D yesterday tc
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_93.html">previous</A>,
<A HREF="cvs_95.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_95.html
===================================================================
RCS file: manual/html_node/cvs_95.html
diff -N manual/html_node/cvs_95.html
--- manual/html_node/cvs_95.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,91 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - commit</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_94.html">previous</A>,
<A HREF="cvs_96.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC99" HREF="cvs_toc.html#TOC99">commit--Check files into the
repository</A></H2>
-<P>
-<A NAME="IDX342"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Version 1.3 Synopsis: commit [-lnR] [-m 'log_message' |
--f file] [-r revision] [files...]
-<LI>
-
-Version 1.3.1 Synopsis: commit [-lnRf] [-m 'log_message' |
--F file] [-r revision] [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: repository.
-<LI>
-
-Synonym: ci
-</UL>
-
-<P>
-<STRONG>Warning:</STRONG> The <SAMP>`-f <VAR>file</VAR>'</SAMP> option will
-probably be renamed to <SAMP>`-F <VAR>file</VAR>'</SAMP>, and <SAMP>`-f'</SAMP>
-will be given a new behavior in future releases of CVS.
-
-</P>
-<P>
-Use <CODE>commit</CODE> when you want to incorporate changes
-from your working source files into the source
-repository.
-
-</P>
-<P>
-If you don't specify particular files to commit, all of
-the files in your working current directory are
-examined. <CODE>commit</CODE> is careful to change in the
-repository only those files that you have really
-changed. By default (or if you explicitly specify the
-<SAMP>`-R'</SAMP> option), files in subdirectories are also
-examined and committed if they have changed; you can
-use the <SAMP>`-l'</SAMP> option to limit <CODE>commit</CODE> to the
-current directory only.
-
-</P>
-<P>
-<CODE>commit</CODE> verifies that the selected files are up
-to date with the current revisions in the source
-repository; it will notify you, and exit without
-committing, if any of the specified files must be made
-current first with <CODE>update</CODE> (see section <A
HREF="cvs_125.html#SEC132">update--Bring work tree in sync with repository</A>).
-<CODE>commit</CODE> does not call the <CODE>update</CODE> command
-for you, but rather leaves that for you to do when the
-time is right.
-
-</P>
-<P>
-When all is well, an editor is invoked to allow you to
-enter a log message that will be written to one or more
-logging programs (see section <A HREF="cvs_130.html#SEC137">The modules
file</A>, and see section <A HREF="cvs_137.html#SEC144">Loginfo</A>)
-and placed in the RCS history file inside the
-repository. This log message can be retrieved with the
-<CODE>log</CODE> command; See section <A HREF="cvs_109.html#SEC116">log--Print
out log information for files</A>. You can specify the
-log message on the command line with the <SAMP>`-m
-<VAR>message</VAR>'</SAMP> option, and thus avoid the editor invocation,
-or use the <SAMP>`-f <VAR>file</VAR>'</SAMP> option to specify
-that the argument file contains the log message.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_94.html">previous</A>,
<A HREF="cvs_96.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_96.html
===================================================================
RCS file: manual/html_node/cvs_96.html
diff -N manual/html_node/cvs_96.html
--- manual/html_node/cvs_96.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,90 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - commit options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_95.html">previous</A>,
<A HREF="cvs_97.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC100" HREF="cvs_toc.html#TOC100">commit options</A></H3>
-
-<P>
-These standard options are supported by <CODE>commit</CODE>
-(see section <A HREF="cvs_88.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-n</CODE>
-<DD>
-Do not run any module program.
-
-<DT><CODE>-R</CODE>
-<DD>
-Commit directories recursively. This is on by default.
-
-<DT><CODE>-r <VAR>revision</VAR></CODE>
-<DD>
-Commit to <VAR>revision</VAR>. <VAR>revision</VAR> must be
-either a branch, or a revision on the main trunk that
-is higher than any existing revision number. You
-cannot commit to a specific revision on a branch.
-</DL>
-
-<P>
-<CODE>commit</CODE> also supports these options:
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-F <VAR>file</VAR></CODE>
-<DD>
-This option is present in CVS releases 1.3-s3 and
-later. Read the log message from <VAR>file</VAR>, instead
-of invoking an editor.
-
-<DT><CODE>-f</CODE>
-<DD>
-This option is present in CVS 1.3-s3 and later releases
-of CVS. Note that this is not the standard behavior of
-the <SAMP>`-f'</SAMP> option as defined in See section <A
HREF="cvs_88.html#SEC90">Common command options</A>.
-
-Force CVS to commit a new revision even if you haven't
-made any changes to the file. If the current revision
-of <VAR>file</VAR> is 1.7, then the following two commands
-are equivalent:
-
-
-<PRE>
-$ cvs commit -f <VAR>file</VAR>
-$ cvs commit -r 1.8 <VAR>file</VAR>
-</PRE>
-
-<DT><CODE>-f <VAR>file</VAR></CODE>
-<DD>
-This option is present in CVS releases 1.3, 1.3-s1 and
-1.3-s2. Note that this is not the standard behavior of
-the <SAMP>`-f'</SAMP> option as defined in See section <A
HREF="cvs_88.html#SEC90">Common command options</A>.
-
-Read the log message from <VAR>file</VAR>, instead
-of invoking an editor.
-
-<DT><CODE>-m <VAR>message</VAR></CODE>
-<DD>
-Use <VAR>message</VAR> as the log message, instead of
-invoking an editor.
-</DL>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_95.html">previous</A>,
<A HREF="cvs_97.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_97.html
===================================================================
RCS file: manual/html_node/cvs_97.html
diff -N manual/html_node/cvs_97.html
--- manual/html_node/cvs_97.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,151 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - commit examples</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_96.html">previous</A>,
<A HREF="cvs_98.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC101" HREF="cvs_toc.html#TOC101">commit examples</A></H3>
-
-
-
-<H4><A NAME="SEC102" HREF="cvs_toc.html#TOC102">New major release
number</A></H4>
-
-<P>
-When you make a major release of your product, you
-might want the revision numbers to track your major
-release number. You should normally not care about
-the revision numbers, but this is a thing that many
-people want to do, and it can be done without doing any
-harm.
-
-</P>
-<P>
-To bring all your files up to the RCS revision 3.0
-(including those that haven't changed), you might do:
-
-</P>
-
-<PRE>
-$ cvs commit -r 3.0
-</PRE>
-
-<P>
-Note that it is generally a bad idea to try to make the
-RCS revision number equal to the current release number
-of your product. You should think of the revision
-number as an internal number that the CVS package
-maintains, and that you generally never need to care
-much about. Using the <CODE>tag</CODE> and <CODE>rtag</CODE>
-commands you can give symbolic names to the releases
-instead. See section <A HREF="cvs_123.html#SEC130">tag--Add a symbolic tag to
checked out versions of files</A> and See section <A
HREF="cvs_119.html#SEC126">rtag--Add a symbolic tag to a module</A>.
-
-</P>
-<P>
-Note that the number you specify with <SAMP>`-r'</SAMP> must be
-larger than any existing revision number. That is, if
-revision 3.0 exists, you cannot <SAMP>`cvs commit
--r 1.3'</SAMP>.
-
-</P>
-
-
-<H4><A NAME="SEC103" HREF="cvs_toc.html#TOC103">Committing to a branch</A></H4>
-
-<P>
-You can commit to a branch revision (one that has an
-even number of dots) with the <SAMP>`-r'</SAMP> option. To
-create a branch revision, use the <SAMP>`-b'</SAMP> option
-of the <CODE>rtag</CODE> or <CODE>tag</CODE> commands (see section <A
HREF="cvs_123.html#SEC130">tag--Add a symbolic tag to checked out versions of
files</A>
-or see section <A HREF="cvs_119.html#SEC126">rtag--Add a symbolic tag to a
module</A>). Then, either <CODE>checkout</CODE> or
-<CODE>update</CODE> can be used to base your sources on the
-newly created branch. From that point on, all
-<CODE>commit</CODE> changes made within these working sources
-will be automatically added to a branch revision,
-thereby not disturbing main-line development in any
-way. For example, if you had to create a patch to the
-1.2 version of the product, even though the 2.0 version
-is already under development, you might do:
-
-</P>
-
-<PRE>
-$ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
-$ cvs checkout -r FCS1_2_Patch product_module
-$ cd product_module
-[[ hack away ]]
-$ cvs commit
-</PRE>
-
-<P>
-This works automatically since the <SAMP>`-r'</SAMP> option is
-sticky.
-
-</P>
-
-
-<H4><A NAME="SEC104" HREF="cvs_toc.html#TOC104">Creating the branch after
editing</A></H4>
-
-<P>
-Say you have been working on some extremely
-experimental software, based on whatever revision you
-happened to checkout last week. If others in your
-group would like to work on this software with you, but
-without disturbing main-line development, you could
-commit your change to a new branch. Others can then
-checkout your experimental stuff and utilize the full
-benefit of CVS conflict resolution. The scenario might
-look like:
-
-</P>
-
-<PRE>
-[[ hacked sources are present ]]
-$ cvs tag -b EXPR1
-$ cvs update -r EXPR1
-$ cvs commit
-</PRE>
-
-<P>
-The <CODE>update</CODE> command will make the <SAMP>`-r
-EXPR1'</SAMP> option sticky on all files. Note that your
-changes to the files will never be removed by the
-<CODE>update</CODE> command. The <CODE>commit</CODE> will
-automatically commit to the correct branch, because the
-<SAMP>`-r'</SAMP> is sticky. You could also do like this:
-
-</P>
-
-<PRE>
-[[ hacked sources are present ]]
-$ cvs tag -b EXPR1
-$ cvs commit -r EXPR1
-</PRE>
-
-<P>
-but then, only those files that were changed by you
-will have the <SAMP>`-r EXPR1'</SAMP> sticky flag. If you hack
-away, and commit without specifying the <SAMP>`-r EXPR1'</SAMP>
-flag, some files may accidentally end up on the main
-trunk.
-
-</P>
-<P>
-To work with you on the experimental change, others
-would simply do
-
-</P>
-
-<PRE>
-$ cvs checkout -r EXPR1 whatever_module
-</PRE>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_96.html">previous</A>,
<A HREF="cvs_98.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_98.html
===================================================================
RCS file: manual/html_node/cvs_98.html
diff -N manual/html_node/cvs_98.html
--- manual/html_node/cvs_98.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,54 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - diff</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_97.html">previous</A>,
<A HREF="cvs_99.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H2><A NAME="SEC105" HREF="cvs_toc.html#TOC105">diff--Run diffs between
revisions</A></H2>
-<P>
-<A NAME="IDX343"></A>
-
-</P>
-
-<UL>
-<LI>
-
-Synopsis: diff [-l] [rcsdiff_options] [[-r rev1 | -D date1] [-r rev2 | -D
date2]] [files...]
-<LI>
-
-Requires: working directory, repository.
-<LI>
-
-Changes: nothing.
-</UL>
-
-<P>
-The <CODE>diff</CODE> command is used to compare different
-revisions of files. The default action is to compare
-your working files with the revisions they were based
-on, and report any differences that are found.
-
-</P>
-<P>
-If any file names are given, only those files are
-compared. If any directories are given, all files
-under them will be compared.
-
-</P>
-<P>
-The exit status will be 0 if no differences were found,
-1 if some differences were found, and 2 if any error
-occurred.
-
-</P>
-
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_97.html">previous</A>,
<A HREF="cvs_99.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_99.html
===================================================================
RCS file: manual/html_node/cvs_99.html
diff -N manual/html_node/cvs_99.html
--- manual/html_node/cvs_99.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,78 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - diff options</TITLE>
-</HEAD>
-<BODY>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_98.html">previous</A>,
<A HREF="cvs_100.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-<P><HR><P>
-
-
-<H3><A NAME="SEC106" HREF="cvs_toc.html#TOC106">diff options</A></H3>
-
-<P>
-These standard options are supported by <CODE>diff</CODE>
-(see section <A HREF="cvs_88.html#SEC90">Common command options</A>, for a
complete description of
-them):
-
-</P>
-<DL COMPACT>
-
-<DT><CODE>-D <VAR>date</VAR></CODE>
-<DD>
-Use the most recent revision no later than <VAR>date</VAR>.
-See <SAMP>`-r'</SAMP> for how this affects the comparison.
-
-CVS can be configured to pass the <SAMP>`-D'</SAMP> option
-through to <CODE>rcsdiff</CODE> (which in turn passes it on
-to <CODE>diff</CODE>. GNU diff uses <SAMP>`-D'</SAMP> as a way to
-put <CODE>cpp</CODE>-style <SAMP>`#define'</SAMP> statements around the output
-differences. There is no way short of testing to
-figure out how CVS was configured. In the default
-configuration CVS will use the <SAMP>`-D <VAR>date</VAR>'</SAMP> option.
-
-<DT><CODE>-k <VAR>kflag</VAR></CODE>
-<DD>
-Process RCS keywords according to <VAR>kflag</VAR>. See
-co(1).
-
-<DT><CODE>-l</CODE>
-<DD>
-Local; run only in current working directory.
-
-<DT><CODE>-R</CODE>
-<DD>
-Examine directories recursively. This option is on by
-default.
-
-<DT><CODE>-r <VAR>tag</VAR></CODE>
-<DD>
-Compare with revision <VAR>tag</VAR>. Zero, one or two
-<SAMP>`-r'</SAMP> options can be present. With no <SAMP>`-r'</SAMP>
-option, the working file will be compared with the
-revision it was based on. With one <SAMP>`-r'</SAMP>, that
-revision will be compared to your current working file.
-With two <SAMP>`-r'</SAMP> options those two revisions will be
-compared (and your working file will not affect the
-outcome in any way).
-
-One or both <SAMP>`-r'</SAMP> options can be replaced by a
-<SAMP>`-D <VAR>date</VAR>'</SAMP> option, described above.
-</DL>
-
-<P>
-Any other options that are found are passed through to
-<CODE>rcsdiff</CODE>, which in turn passes them to
-<CODE>diff</CODE>. The exact meaning of the options depends
-on which <CODE>diff</CODE> you are using. The long options
-introduced in GNU diff 2.0 are not yet supported in
-CVS. See the documentation for your <CODE>diff</CODE> to see
-which options are supported.
-
-</P>
-<P><HR><P>
-Go to the <A HREF="cvs_1.html">first</A>, <A HREF="cvs_98.html">previous</A>,
<A HREF="cvs_100.html">next</A>, <A HREF="cvs_148.html">last</A> section, <A
HREF="cvs_toc.html">table of contents</A>.
-</BODY>
-</HTML>
Index: manual/html_node/cvs_toc.html
===================================================================
RCS file: manual/html_node/cvs_toc.html
diff -N manual/html_node/cvs_toc.html
--- manual/html_node/cvs_toc.html 7 Nov 2003 20:55:33 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,258 +0,0 @@
-<HTML>
-<HEAD>
-<!-- This HTML file has been created by texi2html 1.52
- from ../texi/cvs.texinfo on 7 November 1998 -->
-
-<TITLE>CVS--Concurrent Versions System - Table of Contents</TITLE>
-</HEAD>
-<BODY>
-<H1>CVS--Concurrent Versions System</H1>
-<P>
-<P><HR><P>
-<UL>
-<LI><A NAME="TOC1" HREF="cvs_1.html#SEC1">About this manual</A>
-<UL>
-<LI><A NAME="TOC2" HREF="cvs_2.html#SEC2">Checklist for the impatient
reader</A>
-<LI><A NAME="TOC3" HREF="cvs_3.html#SEC3">Credits</A>
-<LI><A NAME="TOC4" HREF="cvs_4.html#SEC4">BUGS</A>
-</UL>
-<LI><A NAME="TOC5" HREF="cvs_5.html#SEC5">What is CVS?</A>
-<UL>
-<LI><A NAME="TOC6" HREF="cvs_5.html#SEC6">CVS is not...</A>
-</UL>
-<LI><A NAME="TOC7" HREF="cvs_6.html#SEC7">Basic concepts</A>
-<UL>
-<LI><A NAME="TOC8" HREF="cvs_7.html#SEC8">Revision numbers</A>
-<LI><A NAME="TOC9" HREF="cvs_8.html#SEC9">Versions, revisions and releases</A>
-</UL>
-<LI><A NAME="TOC10" HREF="cvs_9.html#SEC10">A sample session</A>
-<UL>
-<LI><A NAME="TOC11" HREF="cvs_10.html#SEC11">Getting the source</A>
-<LI><A NAME="TOC12" HREF="cvs_11.html#SEC12">Committing your changes</A>
-<LI><A NAME="TOC13" HREF="cvs_12.html#SEC13">Cleaning up</A>
-<LI><A NAME="TOC14" HREF="cvs_13.html#SEC14">Viewing differences</A>
-</UL>
-<LI><A NAME="TOC15" HREF="cvs_14.html#SEC15">The Repository</A>
-<UL>
-<LI><A NAME="TOC16" HREF="cvs_15.html#SEC16">Telling CVS where your repository
is</A>
-<LI><A NAME="TOC17" HREF="cvs_16.html#SEC17">How data is stored in the
repository</A>
-<UL>
-<LI><A NAME="TOC18" HREF="cvs_17.html#SEC18">Where files are stored within the
repository</A>
-<LI><A NAME="TOC19" HREF="cvs_18.html#SEC19">File permissions</A>
-</UL>
-<LI><A NAME="TOC20" HREF="cvs_19.html#SEC20">The administrative files</A>
-<UL>
-<LI><A NAME="TOC21" HREF="cvs_19.html#SEC21">Editing administrative files</A>
-</UL>
-<LI><A NAME="TOC22" HREF="cvs_20.html#SEC22">Multiple repositories</A>
-<LI><A NAME="TOC23" HREF="cvs_21.html#SEC23">Creating a repository</A>
-<LI><A NAME="TOC24" HREF="cvs_22.html#SEC24">Remote repositories</A>
-<UL>
-<LI><A NAME="TOC25" HREF="cvs_23.html#SEC25">Connecting with rsh</A>
-<LI><A NAME="TOC26" HREF="cvs_24.html#SEC26">Direct connection with password
authentication</A>
-<UL>
-<LI><A NAME="TOC27" HREF="cvs_25.html#SEC27">Setting up the server for
password authentication</A>
-<LI><A NAME="TOC28" HREF="cvs_26.html#SEC28">Using the client with password
authentication</A>
-<LI><A NAME="TOC29" HREF="cvs_27.html#SEC29">Security considerations with
password authentication</A>
-</UL>
-<LI><A NAME="TOC30" HREF="cvs_28.html#SEC30">Direct connection with
kerberos</A>
-</UL>
-</UL>
-<LI><A NAME="TOC31" HREF="cvs_29.html#SEC31">Starting a project with CVS</A>
-<UL>
-<LI><A NAME="TOC32" HREF="cvs_30.html#SEC32">Setting up the files</A>
-<UL>
-<LI><A NAME="TOC33" HREF="cvs_31.html#SEC33">Creating a directory tree from a
number of files</A>
-<LI><A NAME="TOC34" HREF="cvs_32.html#SEC34">Creating Files From Other Version
Control Systems</A>
-<LI><A NAME="TOC35" HREF="cvs_33.html#SEC35">Creating a directory tree from
scratch</A>
-</UL>
-<LI><A NAME="TOC36" HREF="cvs_34.html#SEC36">Defining the module</A>
-</UL>
-<LI><A NAME="TOC37" HREF="cvs_35.html#SEC37">Multiple developers</A>
-<UL>
-<LI><A NAME="TOC38" HREF="cvs_36.html#SEC38">File status</A>
-<LI><A NAME="TOC39" HREF="cvs_37.html#SEC39">Bringing a file up to date</A>
-<LI><A NAME="TOC40" HREF="cvs_38.html#SEC40">Conflicts example</A>
-<LI><A NAME="TOC41" HREF="cvs_39.html#SEC41">Informing others about commits</A>
-<LI><A NAME="TOC42" HREF="cvs_40.html#SEC42">Several developers simultaneously
attempting to run CVS</A>
-<LI><A NAME="TOC43" HREF="cvs_41.html#SEC43">Mechanisms to track who is
editing files</A>
-<UL>
-<LI><A NAME="TOC44" HREF="cvs_42.html#SEC44">Telling CVS to watch certain
files</A>
-<LI><A NAME="TOC45" HREF="cvs_43.html#SEC45">Telling CVS to notify you</A>
-<LI><A NAME="TOC46" HREF="cvs_44.html#SEC46">How to edit a file which is being
watched</A>
-<LI><A NAME="TOC47" HREF="cvs_45.html#SEC47">Information about who is watching
and editing</A>
-<LI><A NAME="TOC48" HREF="cvs_46.html#SEC48">Using watches with old versions
of CVS</A>
-</UL>
-<LI><A NAME="TOC49" HREF="cvs_47.html#SEC49">Choosing between reserved or
unreserved checkouts</A>
-</UL>
-<LI><A NAME="TOC50" HREF="cvs_48.html#SEC50">Branches</A>
-<UL>
-<LI><A NAME="TOC51" HREF="cvs_49.html#SEC51">Tags--Symbolic revisions</A>
-<LI><A NAME="TOC52" HREF="cvs_50.html#SEC52">What branches are good for</A>
-<LI><A NAME="TOC53" HREF="cvs_51.html#SEC53">Creating a branch</A>
-<LI><A NAME="TOC54" HREF="cvs_52.html#SEC54">Sticky tags</A>
-</UL>
-<LI><A NAME="TOC55" HREF="cvs_53.html#SEC55">Merging</A>
-<UL>
-<LI><A NAME="TOC56" HREF="cvs_54.html#SEC56">Merging an entire branch</A>
-<LI><A NAME="TOC57" HREF="cvs_55.html#SEC57">Merging from a branch several
times</A>
-<LI><A NAME="TOC58" HREF="cvs_56.html#SEC58">Merging differences between any
two revisions</A>
-<LI><A NAME="TOC59" HREF="cvs_57.html#SEC59">Merging can add or remove
files</A>
-</UL>
-<LI><A NAME="TOC60" HREF="cvs_58.html#SEC60">Recursive behavior</A>
-<LI><A NAME="TOC61" HREF="cvs_59.html#SEC61">Adding files to a directory</A>
-<LI><A NAME="TOC62" HREF="cvs_60.html#SEC62">Removing files from a module</A>
-<LI><A NAME="TOC63" HREF="cvs_61.html#SEC63">Tracking third-party sources</A>
-<UL>
-<LI><A NAME="TOC64" HREF="cvs_62.html#SEC64">Importing a module for the first
time</A>
-<LI><A NAME="TOC65" HREF="cvs_63.html#SEC65">Updating a module with the import
command</A>
-<LI><A NAME="TOC66" HREF="cvs_64.html#SEC66">How to handle binary files with
cvs import</A>
-</UL>
-<LI><A NAME="TOC67" HREF="cvs_65.html#SEC67">Moving and renaming files</A>
-<UL>
-<LI><A NAME="TOC68" HREF="cvs_66.html#SEC68">The Normal way to Rename</A>
-<LI><A NAME="TOC69" HREF="cvs_67.html#SEC69">Moving the history file</A>
-<LI><A NAME="TOC70" HREF="cvs_68.html#SEC70">Copying the history file</A>
-</UL>
-<LI><A NAME="TOC71" HREF="cvs_69.html#SEC71">Moving and renaming
directories</A>
-<LI><A NAME="TOC72" HREF="cvs_70.html#SEC72">History browsing</A>
-<UL>
-<LI><A NAME="TOC73" HREF="cvs_71.html#SEC73">Log messages</A>
-<LI><A NAME="TOC74" HREF="cvs_72.html#SEC74">The history database</A>
-<LI><A NAME="TOC75" HREF="cvs_73.html#SEC75">User-defined logging</A>
-<LI><A NAME="TOC76" HREF="cvs_74.html#SEC76">Annotate command</A>
-</UL>
-<LI><A NAME="TOC77" HREF="cvs_75.html#SEC77">Keyword substitution</A>
-<UL>
-<LI><A NAME="TOC78" HREF="cvs_76.html#SEC78">RCS Keywords</A>
-<LI><A NAME="TOC79" HREF="cvs_77.html#SEC79">Using keywords</A>
-<LI><A NAME="TOC80" HREF="cvs_78.html#SEC80">Avoiding substitution</A>
-<LI><A NAME="TOC81" HREF="cvs_79.html#SEC81">Substitution modes</A>
-<LI><A NAME="TOC82" HREF="cvs_80.html#SEC82">Problems with the address@hidden
keyword.</A>
-</UL>
-<LI><A NAME="TOC83" HREF="cvs_81.html#SEC83">Handling binary files</A>
-<LI><A NAME="TOC84" HREF="cvs_82.html#SEC84">Revision management</A>
-<UL>
-<LI><A NAME="TOC85" HREF="cvs_83.html#SEC85">When to commit?</A>
-</UL>
-<LI><A NAME="TOC86" HREF="cvs_84.html#SEC86">Reference manual for CVS
commands</A>
-<UL>
-<LI><A NAME="TOC87" HREF="cvs_85.html#SEC87">Overall structure of CVS
commands</A>
-<LI><A NAME="TOC88" HREF="cvs_86.html#SEC88">Default options and the ~/.cvsrc
file</A>
-<LI><A NAME="TOC89" HREF="cvs_87.html#SEC89">Global options</A>
-<LI><A NAME="TOC90" HREF="cvs_88.html#SEC90">Common command options</A>
-<LI><A NAME="TOC91" HREF="cvs_89.html#SEC91">admin--Administration front end
for rcs</A>
-<UL>
-<LI><A NAME="TOC92" HREF="cvs_90.html#SEC92">admin options</A>
-<LI><A NAME="TOC93" HREF="cvs_91.html#SEC93">admin examples</A>
-<UL>
-<LI><A NAME="TOC94" HREF="cvs_91.html#SEC94">Outdating is dangerous</A>
-<LI><A NAME="TOC95" HREF="cvs_91.html#SEC95">Comment leaders</A>
-</UL>
-</UL>
-<LI><A NAME="TOC96" HREF="cvs_92.html#SEC96">checkout--Check out sources for
editing</A>
-<UL>
-<LI><A NAME="TOC97" HREF="cvs_93.html#SEC97">checkout options</A>
-<LI><A NAME="TOC98" HREF="cvs_94.html#SEC98">checkout examples</A>
-</UL>
-<LI><A NAME="TOC99" HREF="cvs_95.html#SEC99">commit--Check files into the
repository</A>
-<UL>
-<LI><A NAME="TOC100" HREF="cvs_96.html#SEC100">commit options</A>
-<LI><A NAME="TOC101" HREF="cvs_97.html#SEC101">commit examples</A>
-<UL>
-<LI><A NAME="TOC102" HREF="cvs_97.html#SEC102">New major release number</A>
-<LI><A NAME="TOC103" HREF="cvs_97.html#SEC103">Committing to a branch</A>
-<LI><A NAME="TOC104" HREF="cvs_97.html#SEC104">Creating the branch after
editing</A>
-</UL>
-</UL>
-<LI><A NAME="TOC105" HREF="cvs_98.html#SEC105">diff--Run diffs between
revisions</A>
-<UL>
-<LI><A NAME="TOC106" HREF="cvs_99.html#SEC106">diff options</A>
-<LI><A NAME="TOC107" HREF="cvs_100.html#SEC107">diff examples</A>
-</UL>
-<LI><A NAME="TOC108" HREF="cvs_101.html#SEC108">export--Export sources from
CVS, similar to checkout</A>
-<UL>
-<LI><A NAME="TOC109" HREF="cvs_102.html#SEC109">export options</A>
-</UL>
-<LI><A NAME="TOC110" HREF="cvs_103.html#SEC110">history--Show status of files
and users</A>
-<UL>
-<LI><A NAME="TOC111" HREF="cvs_104.html#SEC111">history options</A>
-</UL>
-<LI><A NAME="TOC112" HREF="cvs_105.html#SEC112">import--Import sources into
CVS, using vendor branches</A>
-<UL>
-<LI><A NAME="TOC113" HREF="cvs_106.html#SEC113">import options</A>
-<LI><A NAME="TOC114" HREF="cvs_107.html#SEC114">import output</A>
-<LI><A NAME="TOC115" HREF="cvs_108.html#SEC115">import examples</A>
-</UL>
-<LI><A NAME="TOC116" HREF="cvs_109.html#SEC116">log--Print out log information
for files</A>
-<UL>
-<LI><A NAME="TOC117" HREF="cvs_110.html#SEC117">log options</A>
-<LI><A NAME="TOC118" HREF="cvs_111.html#SEC118">log examples</A>
-</UL>
-<LI><A NAME="TOC119" HREF="cvs_112.html#SEC119">rdiff---'patch' format diffs
between releases</A>
-<UL>
-<LI><A NAME="TOC120" HREF="cvs_113.html#SEC120">rdiff options</A>
-<LI><A NAME="TOC121" HREF="cvs_114.html#SEC121">rdiff examples</A>
-</UL>
-<LI><A NAME="TOC122" HREF="cvs_115.html#SEC122">release--Indicate that a
Module is no longer in use</A>
-<UL>
-<LI><A NAME="TOC123" HREF="cvs_116.html#SEC123">release options</A>
-<LI><A NAME="TOC124" HREF="cvs_117.html#SEC124">release output</A>
-<LI><A NAME="TOC125" HREF="cvs_118.html#SEC125">release examples</A>
-</UL>
-<LI><A NAME="TOC126" HREF="cvs_119.html#SEC126">rtag--Add a symbolic tag to a
module</A>
-<UL>
-<LI><A NAME="TOC127" HREF="cvs_120.html#SEC127">rtag options</A>
-</UL>
-<LI><A NAME="TOC128" HREF="cvs_121.html#SEC128">status--Display status
information on checked out files</A>
-<UL>
-<LI><A NAME="TOC129" HREF="cvs_122.html#SEC129">status options</A>
-</UL>
-<LI><A NAME="TOC130" HREF="cvs_123.html#SEC130">tag--Add a symbolic tag to
checked out versions of files</A>
-<UL>
-<LI><A NAME="TOC131" HREF="cvs_124.html#SEC131">tag options</A>
-</UL>
-<LI><A NAME="TOC132" HREF="cvs_125.html#SEC132">update--Bring work tree in
sync with repository</A>
-<UL>
-<LI><A NAME="TOC133" HREF="cvs_126.html#SEC133">update options</A>
-<LI><A NAME="TOC134" HREF="cvs_127.html#SEC134">update output</A>
-<LI><A NAME="TOC135" HREF="cvs_128.html#SEC135">update examples</A>
-</UL>
-</UL>
-<LI><A NAME="TOC136" HREF="cvs_129.html#SEC136">Reference manual for the
Administrative files</A>
-<UL>
-<LI><A NAME="TOC137" HREF="cvs_130.html#SEC137">The modules file</A>
-<LI><A NAME="TOC138" HREF="cvs_131.html#SEC138">The cvswrappers file</A>
-<LI><A NAME="TOC139" HREF="cvs_132.html#SEC139">The commit support files</A>
-<UL>
-<LI><A NAME="TOC140" HREF="cvs_133.html#SEC140">The common syntax</A>
-</UL>
-<LI><A NAME="TOC141" HREF="cvs_134.html#SEC141">Commitinfo</A>
-<LI><A NAME="TOC142" HREF="cvs_135.html#SEC142">Editinfo</A>
-<UL>
-<LI><A NAME="TOC143" HREF="cvs_136.html#SEC143">Editinfo example</A>
-</UL>
-<LI><A NAME="TOC144" HREF="cvs_137.html#SEC144">Loginfo</A>
-<UL>
-<LI><A NAME="TOC145" HREF="cvs_138.html#SEC145">Loginfo example</A>
-<LI><A NAME="TOC146" HREF="cvs_139.html#SEC146">Keeping a checked out copy</A>
-</UL>
-<LI><A NAME="TOC147" HREF="cvs_140.html#SEC147">Rcsinfo</A>
-<LI><A NAME="TOC148" HREF="cvs_141.html#SEC148">Ignoring files via
cvsignore</A>
-<LI><A NAME="TOC149" HREF="cvs_142.html#SEC149">The history file</A>
-<LI><A NAME="TOC150" HREF="cvs_143.html#SEC150">Expansions in administrative
files</A>
-</UL>
-<LI><A NAME="TOC151" HREF="cvs_144.html#SEC151">All environment variables
which affect CVS</A>
-<LI><A NAME="TOC152" HREF="cvs_145.html#SEC152">Troubleshooting</A>
-<UL>
-<LI><A NAME="TOC153" HREF="cvs_146.html#SEC153">Magic branch numbers</A>
-</UL>
-<LI><A NAME="TOC154" HREF="cvs_147.html#SEC154">GNU GENERAL PUBLIC LICENSE</A>
-<LI><A NAME="TOC155" HREF="cvs_148.html#SEC155">Index</A>
-</UL>
-<P><HR><P>
-This document was generated on 7 November 1998 using the
-<A HREF="http://wwwinfo.cern.ch/dis/texi2html/";>texi2html</A>
-translator version 1.52.</P>
-</BODY>
-</HTML>
Index: manual/info/cvs-infonfo.tar.gz
===================================================================
RCS file: manual/info/cvs-infonfo.tar.gz
diff -N manual/info/cvs-infonfo.tar.gz
Binary files /tmp/cvsv3Ss4C and /dev/null differ
Index: manual/ps/cvs.ps.gz
===================================================================
RCS file: manual/ps/cvs.ps.gz
diff -N manual/ps/cvs.ps.gz
Binary files /tmp/cvsuVpPhB and /dev/null differ
Index: manual/texi/cvs.texinfo.tar.gz
===================================================================
RCS file: manual/texi/cvs.texinfo.tar.gz
diff -N manual/texi/cvs.texinfo.tar.gz
Binary files /tmp/cvs6i485B and /dev/null differ
Index: manual/text/cvs.txt
===================================================================
RCS file: manual/text/cvs.txt
diff -N manual/text/cvs.txt
--- manual/text/cvs.txt 8 Jun 2009 20:47:05 -0000 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,6135 +0,0 @@
-Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
-Free Software Foundation, Inc.
-
- Permission is granted to make and distribute verbatim copies of this
-manual provided the copyright notice and this permission notice are
-preserved on all copies.
-
- Permission is granted to copy and distribute modified versions of
-this manual under the conditions for verbatim copying, provided also
-that the section entitled "GNU General Public License" is included
-exactly as in the original, and provided that the entire resulting
-derived work is distributed under the terms of a permission notice
-identical to this one.
-
- Permission is granted to copy and distribute translations of this
-manual into another language, under the above conditions for modified
-versions, except that the section entitled "GNU General Public License"
-and this permission notice may be included in translations approved by
-the Free Software Foundation instead of in the original English.
-
-
-
- This info manual describes how to use and administer CVS version
-1.9.
-
-About this manual
-*****************
-
- Up to this point, one of the weakest parts of CVS has been the
-documentation. CVS is a complex program. Previous versions of the
-manual were written in the manual page format, which is not really well
-suited for such a complex program.
-
- When writing this manual, I had several goals in mind:
-
- * No knowledge of RCS should be necessary.
-
- * No previous knowledge of revision control software should be
- necessary. All terms, such as "revision numbers", "revision
- trees" and "merging" are explained as they are introduced.
-
- * The manual should concentrate on the things CVS users want to do,
- instead of what the CVS commands can do. The first part of this
- manual leads you through things you might want to do while doing
- development, and introduces the relevant CVS commands as they are
- needed.
-
- * Information should be easy to find. In the reference manual in
- the appendices almost all information about every CVS command is
- gathered together. There is also an extensive index, and a lot of
- cross references.
-
- This manual was contributed by Signum Support AB in Sweden. Signum
-is yet another in the growing list of companies that support free
-software. You are free to copy both this manual and the CVS program.
-*Note Copying::, for the details. Signum Support offers support
-contracts and binary distribution for many programs, such as CVS, GNU
-Emacs, the GNU C compiler and others. Write to us for more information.
-
- Signum Support AB
- Box 2044
- S-580 02 Linkoping
- Sweden
-
- Email: address@hidden
- Phone: +46 (0)13 - 21 46 00
- Fax: +46 (0)13 - 21 47 00
-
- Another company selling support for CVS is Cyclic Software, web:
-`http://www.cyclic.com/', email: address@hidden'.
-
-Checklist for the impatient reader
-==================================
-
- CVS is a complex system. You will need to read the manual to be
-able to use all of its capabilities. There are dangers that can easily
-be avoided if you know about them, and this manual tries to warn you
-about them. This checklist is intended to help you avoid the dangers
-without reading the entire manual. If you intend to read the entire
-manual you can skip this table.
-
-Binary files
- CVS can handle binary files, but you must have RCS release 5.5 or
- later and a release of GNU diff that supports the `-a' flag
- (release 1.15 and later are OK). You must also configure both RCS
- and CVS to handle binary files when you install them.
-
- Keword substitution can be a source of trouble with binary files.
- *Note Keyword substitution::, for solutions.
-
-The `admin' command
- Careless use of the `admin' command can cause CVS to cease
- working. *Note admin::, before trying to use it.
-
-Credits
-=======
-
- Roland Pesch, Cygnus Support <address@hidden> wrote the manual
-pages which were distributed with CVS 1.3. Appendix A and B contain
-much text that was extracted from them. He also read an early draft of
-this manual and contributed many ideas and corrections.
-
- The mailing-list `info-cvs' is sometimes informative. I have
-included information from postings made by the following persons: David
-G. Grubbs <address@hidden>.
-
- Some text has been extracted from the man pages for RCS.
-
- The CVS FAQ by David G. Grubbs has provided useful material. The
-FAQ is no longer maintained, however, and this manual about the closest
-thing there is to a successor (with respect to documenting how to use
-CVS, at least).
-
- In addition, the following persons have helped by telling me about
-mistakes I've made: Roxanne Brunskill <address@hidden>, Kathy Dyer
-<address@hidden>, Karl Pingle <address@hidden>, Thomas A
-Peterson <address@hidden>, Inge Wallin <address@hidden>, Dirk
-Koschuetzki <address@hidden> and Michael Brown
-<address@hidden>.
-
-BUGS
-====
-
- This manual is known to have room for improvement. Here is a list
-of known deficiencies:
-
- * In the examples, the output from CVS is sometimes displayed,
- sometimes not.
-
- * The input that you are supposed to type in the examples should
- have a different font than the output from the computer.
-
- * This manual should be clearer about what file permissions you
- should set up in the repository, and about setuid/setgid.
-
- * Some of the chapters are not yet complete. They are noted by
- comments in the `cvs.texinfo' file.
-
- * This list is not complete. If you notice any error, omission, or
- something that is unclear, please send mail to
- address@hidden
-
- I hope that you will find this manual useful, despite the
-above-mentioned shortcomings.
-
-
- Linkoping, October 1993
- Per Cederqvist
-
-What is CVS?
-************
-
- CVS is a version control system. Using it, you can record the
-history of your source files.
-
- For example, bugs sometimes creep in when software is modified, and
-you might not detect the bug until a long time after you make the
-modification. With CVS, you can easily retrieve old versions to see
-exactly which change caused the bug. This can sometimes be a big help.
-
- You could of course save every version of every file you have ever
-created. This would however waste an enormous amount of disk space.
-CVS stores all the versions of a file in a single file in a clever way
-that only stores the differences between versions.
-
- CVS also helps you if you are part of a group of people working on
-the same project. It is all too easy to overwrite each others' changes
-unless you are extremely careful. Some editors, like GNU Emacs, try to
-make sure that the same file is never modified by two people at the
-same time. Unfortunately, if someone is using another editor, that
-safeguard will not work. CVS solves this problem by insulating the
-different developers from each other. Every developer works in his own
-directory, and CVS merges the work when each developer is done.
-
- CVS started out as a bunch of shell scripts written by Dick Grune,
-posted to `comp.sources.unix' in the volume 6 release of December,
-1986. While no actual code from these shell scripts is present in the
-current version of CVS much of the CVS conflict resolution algorithms
-come from them.
-
- In April, 1989, Brian Berliner designed and coded CVS. Jeff Polk
-later helped Brian with the design of the CVS module and vendor branch
-support.
-
- You can get CVS via anonymous ftp from a number of sites, for
-instance prep.ai.mit.edu in `pub/gnu'.
-
- There is a mailing list, known as `info-cvs', devoted to CVS. To
-subscribe or unsubscribe send a message to
address@hidden'. Please be specific about your
-email address. As of May 1996, subscription requests are handled by a
-busy human being, so you cannot expect to be added or removed
-immediately. The usenet group `comp.software.config-mgmt' is also a
-suitable place for CVS discussions (along with other configuration
-management systems).
-
-CVS is not...
-=============
-
- CVS can do a lot of things for you, but it does not try to be
-everything for everyone.
-
-CVS is not a build system.
- Though the structure of your repository and modules file interact
- with your build system (e.g. `Makefile's), they are essentially
- independent.
-
- CVS does not dictate how you build anything. It merely stores
- files for retrieval in a tree structure you devise.
-
- CVS does not dictate how to use disk space in the checked out
- working directories. If you write your `Makefile's or scripts in
- every directory so they have to know the relative positions of
- everything else, you wind up requiring the entire repository to be
- checked out.
-
- If you modularize your work, and construct a build system that
- will share files (via links, mounts, `VPATH' in `Makefile's,
- etc.), you can arrange your disk usage however you like.
-
- But you have to remember that *any* such system is a lot of work
- to construct and maintain. CVS does not address the issues
- involved.
-
- Of course, you should place the tools created to support such a
- build system (scripts, `Makefile's, etc) under CVS.
-
- Figuring out what files need to be rebuilt when something changes
- is, again, something to be handled outside the scope of CVS. One
- traditional approach is to use `make' for building, and use some
- automated tool for generating the depencies which `make' uses.
-
-CVS is not a substitute for management.
- Your managers and project leaders are expected to talk to you
- frequently enough to make certain you are aware of schedules,
- merge points, branch names and release dates. If they don't, CVS
- can't help.
-
- CVS is an instrument for making sources dance to your tune. But
- you are the piper and the composer. No instrument plays itself or
- writes its own music.
-
-CVS is not a substitute for developer communication.
- When faced with conflicts within a single file, most developers
- manage to resolve them without too much effort. But a more
- general definition of "conflict" includes problems too difficult
- to solve without communication between developers.
-
- CVS cannot determine when simultaneous changes within a single
- file, or across a whole collection of files, will logically
- conflict with one another. Its concept of a "conflict" is purely
- textual, arising when two changes to the same base file are near
- enough to spook the merge (i.e. `diff3') command.
-
- CVS does not claim to help at all in figuring out non-textual or
- distributed conflicts in program logic.
-
- For example: Say you change the arguments to function `X' defined
- in file `A'. At the same time, someone edits file `B', adding new
- calls to function `X' using the old arguments. You are outside
- the realm of CVS's competence.
-
- Acquire the habit of reading specs and talking to your peers.
-
-CVS does not have change control
- Change control refers to a number of things. First of all it can
- mean "bug-tracking", that is being able to keep a database of
- reported bugs and the status of each one (is it fixed? in what
- release? has the bug submitter agreed that it is fixed?). For
- interfacing CVS to an external bug-tracking system, see the
- `rcsinfo' and `editinfo' files (*note Administrative files::.).
-
- Another aspect of change control is keeping track of the fact that
- changes to several files were in fact changed together as one
- logical change. If you check in several files in a single `cvs
- commit' operation, CVS then forgets that those files were checked
- in together, and the fact that they have the same log message is
- the only thing tying them together. Keeping a GNU style
- `ChangeLog' can help somewhat.
-
- Another aspect of change control, in some systems, is the ability
- to keep track of the status of each change. Some changes have
- been written by a developer, others have been reviewed by a second
- developer, and so on. Generally, the way to do this with CVS is to
- generate a diff (using `cvs diff' or `diff') and email it to
- someone who can then apply it using the `patch' utility. This is
- very flexible, but depends on mechanisms outside CVS to make sure
- nothing falls through the cracks.
-
-CVS is not an automated testing program
- It should be possible to enforce mandatory use of a testsuite
- using the `commitinfo' file. I haven't heard a lot about projects
- trying to do that or whether there are subtle gotchas, however.
-
-CVS does not have a builtin process model
- Some systems provide ways to ensure that changes or releases go
- through various steps, with various approvals as needed.
- Generally, one can accomplish this with CVS but it might be a
- little more work. In some cases you'll want to use the
- `commitinfo', `loginfo', `rcsinfo', or `editinfo' files, to
- require that certain steps be performed before cvs will allow a
- checkin. Also consider whether features such as branches and tags
- can be used to perform tasks such as doing work in a development
- tree and then merging certain changes over to a stable tree only
- once they have been proven.
-
-Basic concepts
-**************
-
- CVS stores all files in a centralized "repository" (*note
-Repository::.).
-
- The repository contains directories and files, in an arbitrary tree.
-The "modules" feature can be used to group together a set of
-directories or files into a single entity (*note modules::.). A
-typical usage is to define one module per project.
-
-Revision numbers
-================
-
- Each version of a file has a unique "revision number". Revision
-numbers look like `1.1', `1.2', `1.3.2.2' or even `1.3.2.2.4.5'. A
-revision number always has an even number of period-separated decimal
-integers. By default revision 1.1 is the first revision of a file.
-Each successive revision is given a new number by increasing the
-rightmost number by one. The following figure displays a few
-revisions, with newer revisions to the right.
-
- +-----+ +-----+ +-----+ +-----+ +-----+
- ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
- +-----+ +-----+ +-----+ +-----+ +-----+
-
- CVS is not limited to linear development. The "revision tree" can
-be split into "branches", where each branch is a self-maintained line of
-development. Changes made on one branch can easily be moved back to
-the main trunk.
-
- Each branch has a "branch number", consisting of an odd number of
-period-separated decimal integers. The branch number is created by
-appending an integer to the revision number where the corresponding
-branch forked off. Having branch numbers allows more than one branch
-to be forked off from a certain revision.
-
- All revisions on a branch have revision numbers formed by appending
-an ordinal number to the branch number. The following figure
-illustrates branching with an example.
-
- +-------------+
- Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 !
- / +-------------+
- /
- /
- +---------+ +---------+ +---------+ +---------+
- Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !----! 1.2.2.4 !
- / +---------+ +---------+ +---------+ +---------+
- /
- /
- +-----+ +-----+ +-----+ +-----+ +-----+
- ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
- +-----+ +-----+ +-----+ +-----+ +-----+
- !
- !
- ! +---------+ +---------+ +---------+
- Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
- +---------+ +---------+ +---------+
-
- The exact details of how the branch number is constructed is not
-something you normally need to be concerned about, but here is how it
-works: When CVS creates a branch number it picks the first unused even
-integer, starting with 2. So when you want to create a branch from
-revision 6.4 it will be numbered 6.4.2. All branch numbers ending in a
-zero (such as 6.4.0) are used internally by CVS (*note Magic branch
-numbers::.). The branch 1.1.1 has a special meaning. *Note Tracking
-sources::.
-
-Versions, revisions and releases
-================================
-
- A file can have several versions, as described above. Likewise, a
-software product can have several versions. A software product is
-often given a version number such as `4.1.1'.
-
- Versions in the first sense are called "revisions" in this document,
-and versions in the second sense are called "releases". To avoid
-confusion, the word "version" is almost never used in this document.
-
-A sample session
-****************
-
- This section describes a typical work-session using CVS. It assumes
-that a repository is set up (*note Repository::.).
-
- Suppose you are working on a simple compiler. The source consists
-of a handful of C files and a `Makefile'. The compiler is called `tc'
-(Trivial Compiler), and the repository is set up so that there is a
-module called `tc'.
-
-Getting the source
-==================
-
- The first thing you must do is to get your own working copy of the
-source for `tc'. For this, you use the `checkout' command:
-
- $ cvs checkout tc
-
-This will create a new directory called `tc' and populate it with the
-source files.
-
- $ cd tc
- $ ls
- CVS Makefile backend.c driver.c frontend.c parser.c
-
- The `CVS' directory is used internally by CVS. Normally, you should
-not modify or remove any of the files in it.
-
- You start your favorite editor, hack away at `backend.c', and a
-couple of hours later you have added an optimization pass to the
-compiler. A note to RCS and SCCS users: There is no need to lock the
-files that you want to edit. *Note Multiple developers:: for an
-explanation.
-
-Committing your changes
-=======================
-
- When you have checked that the compiler is still compilable you
-decide to make a new version of `backend.c'.
-
- $ cvs commit backend.c
-
-CVS starts an editor, to allow you to enter a log message. You type in
-"Added an optimization pass.", save the temporary file, and exit the
-editor.
-
- The environment variable `$CVSEDITOR' determines which editor is
-started. If `$CVSEDITOR' is not set, then if the environment variable
-`$EDITOR' is set, it will be used. If both `$CVSEDITOR' and `$EDITOR'
-are not set then the editor defaults to `vi'. If you want to avoid the
-overhead of starting an editor you can specify the log message on the
-command line using the `-m' flag instead, like this:
-
- $ cvs commit -m "Added an optimization pass" backend.c
-
-Cleaning up
-===========
-
- Before you turn to other tasks you decide to remove your working
-copy of tc. One acceptable way to do that is of course
-
- $ cd ..
- $ rm -r tc
-
-but a better way is to use the `release' command (*note release::.):
-
- $ cd ..
- $ cvs release -d tc
- M driver.c
- ? tc
- You have [1] altered files in this repository.
- Are you sure you want to release (and delete) module `tc': n
- ** `release' aborted by user choice.
-
- The `release' command checks that all your modifications have been
-committed. If history logging is enabled it also makes a note in the
-history file. *Note history file::.
-
- When you use the `-d' flag with `release', it also removes your
-working copy.
-
- In the example above, the `release' command wrote a couple of lines
-of output. `? tc' means that the file `tc' is unknown to CVS. That is
-nothing to worry about: `tc' is the executable compiler, and it should
-not be stored in the repository. *Note cvsignore::, for information
-about how to make that warning go away. *Note release output::, for a
-complete explanation of all possible output from `release'.
-
- `M driver.c' is more serious. It means that the file `driver.c' has
-been modified since it was checked out.
-
- The `release' command always finishes by telling you how many
-modified files you have in your working copy of the sources, and then
-asks you for confirmation before deleting any files or making any note
-in the history file.
-
- You decide to play it safe and answer `n <RET>' when `release' asks
-for confirmation.
-
-Viewing differences
-===================
-
- You do not remember modifying `driver.c', so you want to see what
-has happened to that file.
-
- $ cd tc
- $ cvs diff driver.c
-
- This command runs `diff' to compare the version of `driver.c' that
-you checked out with your working copy. When you see the output you
-remember that you added a command line option that enabled the
-optimization pass. You check it in, and release the module.
-
- $ cvs commit -m "Added an optimization pass" driver.c
- Checking in driver.c;
- /usr/local/cvsroot/tc/driver.c,v <-- driver.c
- new revision: 1.2; previous revision: 1.1
- done
- $ cd ..
- $ cvs release -d tc
- ? tc
- You have [0] altered files in this repository.
- Are you sure you want to release (and delete) module `tc': y
-
-The Repository
-**************
-
- The CVS "repository" stores a complete copy of all the files and
-directories which are under version control.
-
- Normally, you never access any of the files in the repository
-directly. Instead, you use CVS commands to get your own copy of the
-files, and then work on that copy. When you've finished a set of
-changes, you check (or "commit") them back into the repository. The
-repository then contains the changes which you have made, as well as
-recording exactly what you changed, when you changed it, and other such
-information.
-
- CVS can access a repository by a variety of means. It might be on
-the local computer, or it might be on a computer across the room or
-across the world. To distinguish various ways to access a repository,
-the repository name can start with an "access method". For example,
-the access method `:local:' means to access a repository directory, so
-the repository `:local:/usr/local/cvsroot' means that the repository is
-in `/usr/local/cvsroot' on the computer running CVS. For information
-on other access methods, see *Note Remote repositories::.
-
- If the access method is omitted, then if the repository does not
-contain `:', then `:local:' is assumed. If it does contain `:' than
-either `:ext:' or `:server:' is assumed. For example, if you have a
-local repository in `/usr/local/cvsroot', you can use
-`/usr/local/cvsroot' instead of `:local:/usr/local/cvsroot'. But if
-(under Windows NT, for example) your local repository is
-`c:\src\cvsroot', then you must specify the access method, as in
-`:local:c:\src\cvsroot'.
-
- The repository is split in two parts. `$CVSROOT/CVSROOT' contains
-administrative files for CVS. The other directories contain the actual
-user-defined modules.
-
-Telling CVS where your repository is
-====================================
-
- There are a couple of different ways to tell CVS where to find the
-repository. You can name the repository on the command line
-explicitly, with the `-d' (for "directory") option:
-
- cvs -d /usr/local/cvsroot checkout yoyodyne/tc
-
- Or you can set the `$CVSROOT' environment variable to an absolute
-path to the root of the repository, `/usr/local/cvsroot' in this
-example. To set `$CVSROOT', all `csh' and `tcsh' users should have
-this line in their `.cshrc' or `.tcshrc' files:
-
- setenv CVSROOT /usr/local/cvsroot
-
-`sh' and `bash' users should instead have these lines in their
-`.profile' or `.bashrc':
-
- CVSROOT=/usr/local/cvsroot
- export CVSROOT
-
- A repository specified with `-d' will override the `$CVSROOT'
-environment variable. Once you've checked a working copy out from the
-repository, it will remember where its repository is (the information
-is recorded in the `CVS/Root' file in the working copy).
-
- The `-d' option and the `CVS/Root' file both override the `$CVSROOT'
-environment variable. If `-d' option differs from `CVS/Root', the
-former is used (and specifying `-d' will cause `CVS/Root' to be
-updated). Of course, for proper operation they should be two ways of
-referring to the same repository.
-
-How data is stored in the repository
-====================================
-
- For most purposes it isn't important *how* CVS stores information in
-the repository. In fact, the format has changed in the past, and is
-likely to change in the future. Since in almost all cases one accesses
-the repository via CVS commands; such changes need not be disruptive.
-
- However, in some cases it may be necessary to understand how CVS
-stores data in the repository, for example you might need to track down
-CVS locks (*note Concurrency::.) or you might need to deal with the
-file permissions appropriate for the repository.
-
-Where files are stored within the repository
---------------------------------------------
-
- The overall structure of the repository is a directory tree
-corresponding to the directories in the working directory. For
-example, supposing the repository is in `/usr/local/cvsroot', here is a
-possible directory tree (showing only the directories):
-
- /usr
- |
- +--local
- | |
- | +--cvsroot
- | | |
- | | +--CVSROOT
- | (administrative files)
- |
- +--gnu
- | |
- | +--diff
- | | (source code to GNU diff)
- | |
- | +--rcs
- | | (source code to RCS)
- | |
- | +--cvs
- | (source code to CVS)
- |
- +--yoyodyne
- |
- +--tc
- | |
- | +--man
- | |
- | +--testing
- |
- +--(other Yoyodyne software)
-
- With the directories are "history files" for each file under version
-control. The name of the history file is the name of the corresponding
-file with `,v' appended to the end. Here is what the repository for
-the `yoyodyne/tc' directory might look like:
-
- `$CVSROOT'
- |
- +--yoyodyne
- | |
- | +--tc
- | | |
- +--Makefile,v
- +--backend.c,v
- +--driver.c,v
- +--frontend.c,v
- +--parser.c,v
- +--man
- | |
- | +--tc.1,v
- |
- +--testing
- |
- +--testpgm.t,v
- +--test2.t,v
-
- The history files contain, among other things, enough information to
-recreate any revision of the file, a log of all commit messages and the
-user-name of the person who committed the revision. The history files
-are known as "RCS files", because the first program to store files in
-that format was a version control system known as RCS. For a full
-description of the file format, see the `man' page `rcsfile(5)',
-distributed with RCS. This file format has become very common--many
-systems other than CVS or RCS can at least import history files in this
-format.
-
-File permissions
-----------------
-
- All `,v' files are created read-only, and you should not change the
-permission of those files. The directories inside the repository
-should be writable by the persons that have permission to modify the
-files in each directory. This normally means that you must create a
-UNIX group (see group(5)) consisting of the persons that are to edit
-the files in a project, and set up the repository so that it is that
-group that owns the directory.
-
- This means that you can only control access to files on a
-per-directory basis.
-
- Note that users must also have write access to check out files,
-because CVS needs to create lock files (*note Concurrency::.).
-
- Also note that users must have write access to the
-`CVSROOT/val-tags' file. CVS uses it to keep track of what tags are
-valid tag names (it is sometimes updated when tags are used, as well as
-when they are created, though).
-
- CVS tries to set up reasonable file permissions for new directories
-that are added inside the tree, but you must fix the permissions
-manually when a new directory should have different permissions than its
-parent directory. If you set the `CVSUMASK' environment variable that
-will control the file permissions which CVS uses in creating directories
-and/or files in the repository. `CVSUMASK' does not affect the file
-permissions in the working directory; such files have the permissions
-which are typical for newly created files, except that sometimes CVS
-creates them read-only (see the sections on watches, *Note Setting a
-watch::; -r, *Note Global options::; or CVSREAD, *Note Environment
-variables::).
-
- Since CVS was not written to be run setuid, it is unsafe to try to
-run it setuid. You cannot use the setuid features of RCS together with
-CVS.
-
-The administrative files
-========================
-
- The directory `$CVSROOT/CVSROOT' contains some "administrative
-files". *Note Administrative files::, for a complete description. You
-can use CVS without any of these files, but some commands work better
-when at least the `modules' file is properly set up.
-
- The most important of these files is the `modules' file. It defines
-all modules in the repository. This is a sample `modules' file.
-
- CVSROOT CVSROOT
- modules CVSROOT modules
- cvs gnu/cvs
- rcs gnu/rcs
- diff gnu/diff
- tc yoyodyne/tc
-
- The `modules' file is line oriented. In its simplest form each line
-contains the name of the module, whitespace, and the directory where
-the module resides. The directory is a path relative to `$CVSROOT'.
-The last four lines in the example above are examples of such lines.
-
- The line that defines the module called `modules' uses features that
-are not explained here. *Note modules::, for a full explanation of all
-the available features.
-
-Editing administrative files
-----------------------------
-
- You edit the administrative files in the same way that you would edit
-any other module. Use `cvs checkout CVSROOT' to get a working copy,
-edit it, and commit your changes in the normal way.
-
- It is possible to commit an erroneous administrative file. You can
-often fix the error and check in a new revision, but sometimes a
-particularly bad error in the administrative file makes it impossible
-to commit new revisions.
-
-Multiple repositories
-=====================
-
- In some situations it is a good idea to have more than one
-repository, for instance if you have two development groups that work
-on separate projects without sharing any code. All you have to do to
-have several repositories is to specify the appropriate repository,
-using the `CVSROOT' environment variable, the `-d' option to CVS, or
-(once you have checked out a working directory) by simply allowing CVS
-to use the repository that was used to check out the working directory
-(*note Specifying a repository::.).
-
- The big advantage of having multiple repositories is that they can
-reside on different servers. The big disadvantage is that you cannot
-have a single CVS command recurse into directories which comes from
-different repositories. Generally speaking, if you are thinking of
-setting up several repositories on the same machine, you might want to
-consider using several directories within the same repository.
-
- None of the examples in this manual show multiple repositories.
-
-Creating a repository
-=====================
-
- To set up a CVS repository, choose a directory with ample disk space
-available for the revision history of the source files. It should be
-accessable (directly or via a networked file system) from all machines
-which want to use CVS in server or local mode; the client machines need
-not have any access to it other than via the CVS protocol. It is not
-possible to use CVS to read from a repository which one only has read
-access to; CVS needs to be able to create lock files (*note
-Concurrency::.).
-
- To create a repository, run the `cvs init' command. It will set up
-an empty repository in the CVS root specified in the usual way (*note
-Repository::.). For example,
-
- cvs -d /usr/local/cvsroot init
-
- `cvs init' is careful to never overwrite any existing files in the
-repository, so no harm is done if you run `cvs init' on an already
-set-up repository.
-
- `cvs init' will enable history logging; if you don't want that,
-remove the history file after running `cvs init'. *Note history file::.
-
-Remote repositories
-===================
-
- Your working copy of the sources can be on a different machine than
-the repository. Generally, using a remote repository is just like
-using a local one, except that the format of the repository name is:
-
- :METHOD:address@hidden:/path/to/repository
-
- The details of exactly what needs to be set up depend on how you are
-connecting to the server.
-
- If METHOD is not specified, and the repository name contains `:',
-then the default is `ext' or `server', depending on your platform; both
-are described in *Note Connecting via rsh::.
-
-Connecting with rsh
--------------------
-
- CVS uses the `rsh' protocol to perform these operations, so the
-remote user host needs to have a `.rhosts' file which grants access to
-the local user.
-
- For example, suppose you are the user `mozart' on the local machine
-`anklet.grunge.com', and the server machine is
-`chainsaw.brickyard.com'. On chainsaw, put the following line into the
-file `.rhosts' in `bach''s home directory:
-
- anklet.grunge.com mozart
-
- Then test that `rsh' is working with
-
- rsh -l bach chainsaw.brickyard.com 'echo $PATH'
-
- Next you have to make sure that `rsh' will be able to find the
-server. Make sure that the path which `rsh' printed in the above
-example includes the directory containing a program named `cvs' which
-is the server. You need to set the path in `.bashrc', `.cshrc', etc.,
-not `.login' or `.profile'. Alternately, you can set the environment
-variable `CVS_SERVER' on the client machine to the filename of the
-server you want to use, for example `/usr/local/bin/cvs-1.6'.
-
- There is no need to edit `inetd.conf' or start a CVS server daemon.
-
- There are two access methods that you use in CVSROOT for rsh.
-`:server:' specifies an internal rsh client, which is supported only by
-some CVS ports. `:ext:' specifies an external rsh program. By default
-this is `rsh' but you may set the `CVS_RSH' environment variable to
-invoke another program which can access the remote server (for example,
-`remsh' on HP-UX 9 because `rsh' is something different). It must be a
-program which can transmit data to and from the server without modifying
-it; for example the Windows NT `rsh' is not suitable since it by
-default translates between CRLF and LF. The OS/2 CVS port has a hack
-to pass `-b' to `rsh' to get around this, but since this could
-potentially cause programs for programs other than the standard `rsh',
-it may change in the future. If you set `CVS_RSH' to `SSH' or some
-other rsh replacement, the instructions in the rest of this section
-concerning `.rhosts' and so on are likely to be incorrect; consult the
-documentation for your rsh replacement.
-
- Continuing our example, supposing you want to access the module
-`foo' in the repository `/usr/local/cvsroot/', on machine
-`chainsaw.brickyard.com', you are ready to go:
-
- cvs -d :ext:address@hidden:/usr/local/cvsroot checkout foo
-
- (The `bach@' can be omitted if the username is the same on both the
-local and remote hosts.)
-
-Direct connection with password authentication
-----------------------------------------------
-
- The CVS client can also connect to the server using a password
-protocol. This is particularly useful if using `rsh' is not feasible
-(for example, the server is behind a firewall), and Kerberos also is
-not available.
-
- To use this method, it is necessary to make some adjustments on both
-the server and client sides.
-
-Setting up the server for password authentication
-.................................................
-
- On the server side, the file `/etc/inetd.conf' needs to be edited so
-`inetd' knows to run the command `cvs pserver' when it receives a
-connection on the right port. By default, the port number is 2401; it
-would be different if your client were compiled with `CVS_AUTH_PORT'
-defined to something else, though.
-
- If your `inetd' allows raw port numbers in `/etc/inetd.conf', then
-the following (all on a single line in `inetd.conf') should be
-sufficient:
-
- 2401 stream tcp nowait root /usr/local/bin/cvs
- cvs -b /usr/local/bin pserver
-
- The `-b' option specifies the directory which contains the RCS
-binaries on the server. You could also use the `-T' option to specify
-a temporary directory.
-
- If your `inetd' wants a symbolic service name instead of a raw port
-number, then put this in `/etc/services':
-
- cvspserver 2401/tcp
-
- and put `cvspserver' instead of `2401' in `inetd.conf'.
-
- Once the above is taken care of, restart your `inetd', or do
-whatever is necessary to force it to reread its initialization files.
-
- Because the client stores and transmits passwords in cleartext
-(almost--see *Note Password authentication security:: for details), a
-separate CVS password file may be used, so people don't compromise their
-regular passwords when they access the repository. This file is
-`$CVSROOT/CVSROOT/passwd' (*note Intro administrative files::.). Its
-format is similar to `/etc/passwd', except that it only has two fields,
-username and password. For example:
-
- bach:ULtgRLXo7NRxs
- cwang:1sOp854gDF3DY
-
- The password is encrypted according to the standard Unix `crypt()'
-function, so it is possible to paste in passwords directly from regular
-Unix `passwd' files.
-
- When authenticating a password, the server first checks for the user
-in the CVS `passwd' file. If it finds the user, it compares against
-that password. If it does not find the user, or if the CVS `passwd'
-file does not exist, then the server tries to match the password using
-the system's user-lookup routine. When using the CVS `passwd' file,
-the server runs under as the username specified in the the third
-argument in the entry, or as the first argument if there is no third
-argument (in this way CVS allows imaginary usernames provided the CVS
-`passwd' file indicates corresponding valid system usernames). In any
-case, CVS will have no privileges which the (valid) user would not have.
-
- Right now, the only way to put a password in the CVS `passwd' file
-is to paste it there from somewhere else. Someday, there may be a `cvs
-passwd' command.
-
-Using the client with password authentication
-.............................................
-
- Before connecting to the server, the client must "log in" with the
-command `cvs login'. Logging in verifies a password with the server,
-and also records the password for later transactions with the server.
-The `cvs login' command needs to know the username, server hostname,
-and full repository path, and it gets this information from the
-repository argument or the `CVSROOT' environment variable.
-
- `cvs login' is interactive -- it prompts for a password:
-
- cvs -d :pserver:address@hidden:/usr/local/cvsroot login
- CVS password:
-
- The password is checked with the server; if it is correct, the
-`login' succeeds, else it fails, complaining that the password was
-incorrect.
-
- Once you have logged in, you can force CVS to connect directly to
-the server and authenticate with the stored password:
-
- cvs -d :pserver:address@hidden:/usr/local/cvsroot checkout foo
-
- The `:pserver:' is necessary because without it, CVS will assume it
-should use `rsh' to connect with the server (*note Connecting via
-rsh::.). (Once you have a working copy checked out and are running CVS
-commands from within it, there is no longer any need to specify the
-repository explicitly, because CVS records it in the working copy's
-`CVS' subdirectory.)
-
- Passwords are stored by default in the file `$HOME/.cvspass'. Its
-format is human-readable, but don't edit it unless you know what you
-are doing. The passwords are not stored in cleartext, but are
-trivially encoded to protect them from "innocent" compromise (i.e.,
-inadvertently being seen by a system administrator who happens to look
-at that file).
-
- The `CVS_PASSFILE' environment variable overrides this default. If
-you use this variable, make sure you set it *before* `cvs login' is
-run. If you were to set it after running `cvs login', then later CVS
-commands would be unable to look up the password for transmission to
-the server.
-
- The `CVS_PASSWORD' environment variable overrides *all* stored
-passwords. If it is set, CVS will use it for all password-authenticated
-connections.
-
-Security considerations with password authentication
-....................................................
-
- The passwords are stored on the client side in a trivial encoding of
-the cleartext, and transmitted in the same encoding. The encoding is
-done only to prevent inadvertent password compromises (i.e., a system
-administrator accidentally looking at the file), and will not prevent
-even a naive attacker from gaining the password.
-
- The separate CVS password file (*note Password authentication
-server::.) allows people to use a different password for repository
-access than for login access. On the other hand, once a user has
-access to the repository, she can execute programs on the server system
-through a variety of means. Thus, repository access implies fairly
-broad system access as well. It might be possible to modify CVS to
-prevent that, but no one has done so as of this writing. Furthermore,
-there may be other ways in which having access to CVS allows people to
-gain more general access to the system; noone has done a careful audit.
-
- In summary, anyone who gets the password gets repository access, and
-some measure of general system access as well. The password is
-available to anyone who can sniff network packets or read a protected
-(i.e., user read-only) file. If you want real security, get Kerberos.
-
-Direct connection with kerberos
--------------------------------
-
- The main disadvantage of using rsh is that all the data needs to
-pass through additional programs, so it may be slower. So if you have
-kerberos installed you can connect via a direct TCP connection,
-authenticating with kerberos.
-
- To do this, CVS needs to be compiled with kerberos support; when
-configuring CVS it tries to detect whether kerberos is present or you
-can use the `--with-krb4' flag to configure.
-
- The data transmitted is *not* encrypted by default. Encryption
-support must be compiled into both the client and server; use the
-`--enable-encryption' configure option to turn it on. You must then
-use the `-x' global option to request encryption.
-
- You need to edit `inetd.conf' on the server machine to run `cvs
-kserver'. The client uses port 1999 by default; if you want to use
-another port specify it in the `CVS_CLIENT_PORT' environment variable
-on the client.
-
- When you want to use CVS, get a ticket in the usual way (generally
-`kinit'); it must be a ticket which allows you to log into the server
-machine. Then you are ready to go:
-
- cvs -d :kserver:chainsaw.brickyard.com:/user/local/cvsroot checkout foo
-
- Previous versions of CVS would fall back to a connection via rsh;
-this version will not do so.
-
-Starting a project with CVS
-***************************
-
- Because renaming files and moving them between directories is
-somewhat inconvenient, the first thing you do when you start a new
-project should be to think through your file organization. It is not
-impossible to rename or move files, but it does increase the potential
-for confusion and CVS does have some quirks particularly in the area of
-renaming directories. *Note Moving files::.
-
- What to do next depends on the situation at hand.
-
-Setting up the files
-====================
-
- The first step is to create the files inside the repository. This
-can be done in a couple of different ways.
-
-Creating a directory tree from a number of files
-------------------------------------------------
-
- When you begin using CVS, you will probably already have several
-projects that can be put under CVS control. In these cases the easiest
-way is to use the `import' command. An example is probably the easiest
-way to explain how to use it. If the files you want to install in CVS
-reside in `WDIR', and you want them to appear in the repository as
-`$CVSROOT/yoyodyne/RDIR', you can do this:
-
- $ cd WDIR
- $ cvs import -m "Imported sources" yoyodyne/RDIR yoyo start
-
- Unless you supply a log message with the `-m' flag, CVS starts an
-editor and prompts for a message. The string `yoyo' is a "vendor tag",
-and `start' is a "release tag". They may fill no purpose in this
-context, but since CVS requires them they must be present. *Note
-Tracking sources::, for more information about them.
-
- You can now verify that it worked, and remove your original source
-directory.
-
- $ cd ..
- $ mv DIR DIR.orig
- $ cvs checkout yoyodyne/DIR # Explanation below
- $ ls -R yoyodyne
- $ rm -r DIR.orig
-
-Erasing the original sources is a good idea, to make sure that you do
-not accidentally edit them in DIR, bypassing CVS. Of course, it would
-be wise to make sure that you have a backup of the sources before you
-remove them.
-
- The `checkout' command can either take a module name as argument (as
-it has done in all previous examples) or a path name relative to
-`$CVSROOT', as it did in the example above.
-
- It is a good idea to check that the permissions CVS sets on the
-directories inside `$CVSROOT' are reasonable, and that they belong to
-the proper groups. *Note File permissions::.
-
- If some of the files you want to import are binary, you may want to
-use the wrappers features to specify which files are binary and which
-are not. *Note Wrappers::.
-
-Creating Files From Other Version Control Systems
--------------------------------------------------
-
- If you have a project which you are maintaining with another version
-control system, such as RCS, you may wish to put the files from that
-project into CVS, and preserve the revision history of the files.
-
-From RCS
- If you have been using RCS, find the RCS files--usually a file
- named `foo.c' will have its RCS file in `RCS/foo.c,v' (but it
- could be other places; consult the RCS documentation for details).
- Then create the appropriate directories in CVS if they do not
- already exist. Then copy the files into the appropriate
- directories in the CVS repository (the name in the repository must
- be the name of the source file with `,v' added; the files go
- directly in the appopriate directory of the repository, not in an
- `RCS' subdirectory). This is one of the few times when it is a
- good idea to access the CVS repository directly, rather than using
- CVS commands. Then you are ready to check out a new working
- directory.
-
- The RCS file should not be locked when you move it into CVS; if it
- is, CVS will have trouble letting you operate on it.
-
-From another version control system
- Many version control systems have the ability to export RCS files
- in the standard format. If yours does, export the RCS files and
- then follow the above instructions.
-
-From SCCS
- There is a script in the `contrib' directory of the CVS source
- distribution called `sccs2rcs' which converts SCCS files to RCS
- files. Note: you must run it on a machine which has both SCCS and
- RCS installed, and like everything else in contrib it is
- unsupported (your mileage may vary).
-
-Creating a directory tree from scratch
---------------------------------------
-
- For a new project, the easiest thing to do is probably to create an
-empty directory structure, like this:
-
- $ mkdir tc
- $ mkdir tc/man
- $ mkdir tc/testing
-
- After that, you use the `import' command to create the corresponding
-(empty) directory structure inside the repository:
-
- $ cd tc
- $ cvs import -m "Created directory structure" yoyodyne/DIR yoyo start
-
- Then, use `add' to add files (and new directories) as they appear.
-
- Check that the permissions CVS sets on the directories inside
-`$CVSROOT' are reasonable.
-
-Defining the module
-===================
-
- The next step is to define the module in the `modules' file. This
-is not strictly necessary, but modules can be convenient in grouping
-together related files and directories.
-
- In simple cases these steps are sufficient to define a module.
-
- 1. Get a working copy of the modules file.
-
- $ cvs checkout CVSROOT/modules
- $ cd CVSROOT
-
- 2. Edit the file and insert a line that defines the module. *Note
- Intro administrative files::, for an introduction. *Note
- modules::, for a full description of the modules file. You can
- use the following line to define the module `tc':
-
- tc yoyodyne/tc
-
- 3. Commit your changes to the modules file.
-
- $ cvs commit -m "Added the tc module." modules
-
- 4. Release the modules module.
-
- $ cd ..
- $ cvs release -d CVSROOT
-
-Multiple developers
-*******************
-
- When more than one person works on a software project things often
-get complicated. Often, two people try to edit the same file
-simultaneously. One solution, known as "file locking" or "reserved
-checkouts", is to allow only one person to edit each file at a time.
-This is the only solution with some version control systems, including
-RCS and SCCS. CVS doesn't have a very nice implementation of reserved
-checkouts (yet) but there are ways to get it working (for example, see
-the `cvs admin -l' command in *Note admin options::). It also may be
-possible to use the watches features described below, together with
-suitable procedures (not enforced by software), to avoid having two
-people edit at the same time.
-
- The default model with CVS is known as "unreserved checkouts". In
-this model, developers can edit their own "working copy" of a file
-simultaneously. The first person that commits his changes has no
-automatic way of knowing that another has started to edit it. Others
-will get an error message when they try to commit the file. They must
-then use CVS commands to bring their working copy up to date with the
-repository revision. This process is almost automatic.
-
- CVS also supports mechanisms which facilitate various kinds of
-communcation, without actually enforcing rules like reserved checkouts
-do.
-
- The rest of this chapter describes how these various models work,
-and some of the issues involved in choosing between them.
-
-File status
-===========
-
- Based on what operations you have performed on a checked out file,
-and what operations others have performed to that file in the
-repository, one can classify a file in a number of states. The states,
-as reported by the `status' command, are:
-
-Up-to-date
- The file is identical with the latest revision in the repository
- for the branch in use.
-
-Locally Modified
- You have edited the file, and not yet committed your changes.
-
-Locally Added
- You have added the file with `add', and not yet committed your
- changes.
-
-Locally Removed
- You have removed the file with `remove', and not yet committed
- your changes.
-
-Needs Checkout
- Someone else has committed a newer revision to the repository.
- The name is slightly misleading; you will ordinarily use `update'
- rather than `checkout' to get that newer revision.
-
-Needs Patch
- Like Needs Checkout, but the CVS server will send a patch rather
- than the entire file. Sending a patch or sending an entire file
- accomplishes the same thing.
-
-Needs Merge
- Someone else has committed a newer revision to the repository, and
- you have also made modifications to the file.
-
-Unresolved Conflict
- This is like Locally Modified, except that a previous `update'
- command gave a conflict. You need to resolve the conflict as
- described in *Note Conflicts example::.
-
-Unknown
- CVS doesn't know anything about this file. For example, you have
- created a new file and have not run `add'.
-
- To help clarify the file status, `status' also reports the `Working
-revision' which is the revision that the file in the working directory
-derives from, and the `Repository revision' which is the latest
-revision in the repository for the branch in use.
-
- For information on the options to `status', see *Note status::. For
-information on its `Sticky tag' and `Sticky date' output, see *Note
-Sticky tags::. For information on its `Sticky options' output, see the
-`-k' option in *Note update options::.
-
-Bringing a file up to date
-==========================
-
- When you want to update or merge a file, use the `update' command.
-For files that are not up to date this is roughly equivalent to a
-`checkout' command: the newest revision of the file is extracted from
-the repository and put in your working copy of the module.
-
- Your modifications to a file are never lost when you use `update'.
-If no newer revision exists, running `update' has no effect. If you
-have edited the file, and a newer revision is available, CVS will merge
-all changes into your working copy.
-
- For instance, imagine that you checked out revision 1.4 and started
-editing it. In the meantime someone else committed revision 1.5, and
-shortly after that revision 1.6. If you run `update' on the file now,
-CVS will incorporate all changes between revision 1.4 and 1.6 into your
-file.
-
- If any of the changes between 1.4 and 1.6 were made too close to any
-of the changes you have made, an "overlap" occurs. In such cases a
-warning is printed, and the resulting file includes both versions of
-the lines that overlap, delimited by special markers. *Note update::,
-for a complete description of the `update' command.
-
-Conflicts example
-=================
-
- Suppose revision 1.4 of `driver.c' contains this:
-
- #include <stdio.h>
-
- void main()
- {
- parse();
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? 0 : 1);
- }
-
-Revision 1.6 of `driver.c' contains this:
-
- #include <stdio.h>
-
- int main(int argc,
- char **argv)
- {
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(!!nerr);
- }
-
-Your working copy of `driver.c', based on revision 1.4, contains this
-before you run `cvs update':
-
- #include <stdlib.h>
- #include <stdio.h>
-
- void main()
- {
- init_scanner();
- parse();
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
- }
-
-You run `cvs update':
-
- $ cvs update driver.c
- RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
- retrieving revision 1.4
- retrieving revision 1.6
- Merging differences between 1.4 and 1.6 into driver.c
- rcsmerge warning: overlaps during merge
- cvs update: conflicts found in driver.c
- C driver.c
-
-CVS tells you that there were some conflicts. Your original working
-file is saved unmodified in `.#driver.c.1.4'. The new version of
-`driver.c' contains this:
-
- #include <stdlib.h>
- #include <stdio.h>
-
- int main(int argc,
- char **argv)
- {
- init_scanner();
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- <<<<<<< driver.c
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
- =======
- exit(!!nerr);
- >>>>>>> 1.6
- }
-
-Note how all non-overlapping modifications are incorporated in your
-working copy, and that the overlapping section is clearly marked with
-`<<<<<<<', `=======' and `>>>>>>>'.
-
- You resolve the conflict by editing the file, removing the markers
-and the erroneous line. Suppose you end up with this file:
- #include <stdlib.h>
- #include <stdio.h>
-
- int main(int argc,
- char **argv)
- {
- init_scanner();
- parse();
- if (argc != 1)
- {
- fprintf(stderr, "tc: No args expected.\n");
- exit(1);
- }
- if (nerr == 0)
- gencode();
- else
- fprintf(stderr, "No code generated.\n");
- exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
- }
-
-You can now go ahead and commit this as revision 1.7.
-
- $ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
- Checking in driver.c;
- /usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
- new revision: 1.7; previous revision: 1.6
- done
-
- For your protection, CVS will refuse to check in a file if a
-conflict occurred and you have not resolved the conflict. Currently to
-resolve a conflict, you must change the timestamp on the file, and must
-also insure that the file contains no conflict markers. If your file
-legitimately contains conflict markers (that is, occurrences of
-`>>>>>>> ' at the start of a line that don't mark a conflict), then CVS
-has trouble handling this and you need to start hacking on the
-`CVS/Entries' file or other such workarounds.
-
- If you use release 1.04 or later of pcl-cvs (a GNU Emacs front-end
-for CVS) you can use an Emacs package called emerge to help you resolve
-conflicts. See the documentation for pcl-cvs.
-
-Informing others about commits
-==============================
-
- It is often useful to inform others when you commit a new revision
-of a file. The `-i' option of the `modules' file, or the `loginfo'
-file, can be used to automate this process. *Note modules::. *Note
-loginfo::. You can use these features of CVS to, for instance,
-instruct CVS to mail a message to all developers, or post a message to
-a local newsgroup.
-
-Several developers simultaneously attempting to run CVS
-=======================================================
-
- If several developers try to run CVS at the same time, one may get
-the following message:
-
- [11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
-
- CVS will try again every 30 seconds, and either continue with the
-operation or print the message again, if it still needs to wait. If a
-lock seems to stick around for an undue amount of time, find the person
-holding the lock and ask them about the cvs command they are running.
-If they aren't running a cvs command, look for and remove files
-starting with `#cvs.tfl', `#cvs.rfl', or `#cvs.wfl' from the repository.
-
- Note that these locks are to protect CVS's internal data structures
-and have no relationship to the word "lock" in the sense used by
-RCS--which refers to reserved checkouts (*note Multiple developers::.).
-
- Any number of people can be reading from a given repository at a
-time; only when someone is writing do the locks prevent other people
-from reading or writing.
-
- One might hope for the following property
-
- If someone commits some changes in one cvs command,
- then an update by someone else will either get all the
- changes, or none of them.
-
- but CVS does *not* have this property. For example, given the files
-
- a/one.c
- a/two.c
- b/three.c
- b/four.c
-
- if someone runs
-
- cvs ci a/two.c b/three.c
-
- and someone else runs `cvs update' at the same time, the person
-running `update' might get only the change to `b/three.c' and not the
-change to `a/two.c'.
-
-Mechanisms to track who is editing files
-========================================
-
- For many groups, use of CVS in its default mode is perfectly
-satisfactory. Users may sometimes go to check in a modification only
-to find that another modification has intervened, but they deal with it
-and proceed with their check in. Other groups prefer to be able to
-know who is editing what files, so that if two people try to edit the
-same file they can choose to talk about who is doing what when rather
-than be surprised at check in time. The features in this section allow
-such coordination, while retaining the ability of two developers to
-edit the same file at the same time.
-
- For maximum benefit developers should use `cvs edit' (not `chmod')
-to make files read-write to edit them, and `cvs release' (not `rm') to
-discard a working directory which is no longer in use, but CVS is not
-able to enforce this behavior.
-
-Telling CVS to watch certain files
-----------------------------------
-
- To enable the watch features, you first specify that certain files
-are to be watched.
-
- - Command: cvs watch on [`-l'] FILES ...
- Specify that developers should run `cvs edit' before editing
- FILES. CVS will create working copies of FILES read-only, to
- remind developers to run the `cvs edit' command before working on
- them.
-
- If FILES includes the name of a directory, CVS arranges to watch
- all files added to the corresponding repository directory, and
- sets a default for files added in the future; this allows the user
- to set notification policies on a per-directory basis. The
- contents of the directory are processed recursively, unless the
- `-l' option is given.
-
- If FILES is omitted, it defaults to the current directory.
-
-
- - Command: cvs watch off [`-l'] FILES ...
- Do not provide notification about work on FILES. CVS will create
- working copies of FILES read-write.
-
- The FILES and `-l' arguments are processed as for `cvs watch on'.
-
-
-Telling CVS to notify you
--------------------------
-
- You can tell CVS that you want to receive notifications about
-various actions taken on a file. You can do this without using `cvs
-watch on' for the file, but generally you will want to use `cvs watch
-on', so that developers use the `cvs edit' command.
-
- - Command: cvs watch add [`-a' ACTION] [`-l'] FILES ...
- Add the current user to the list of people to receive notification
- of work done on FILES.
-
- The `-a' option specifies what kinds of events CVS should notify
- the user about. ACTION is one of the following:
-
- `edit'
- Another user has applied the `cvs edit' command (described
- below) to a file.
-
- `unedit'
- Another user has applied the `cvs unedit' command (described
- below) or the `cvs release' command to a file, or has deleted
- the file and allowed `cvs update' to recreate it.
-
- `commit'
- Another user has committed changes to a file.
-
- `all'
- All of the above.
-
- `none'
- None of the above. (This is useful with `cvs edit',
- described below.)
-
- The `-a' option may appear more than once, or not at all. If
- omitted, the action defaults to `all'.
-
- The FILES and `-l' option are processed as for the `cvs watch'
- commands.
-
-
- - Command: cvs watch remove [`-a' ACTION] [`-l'] FILES ...
- Remove a notification request established using `cvs watch add';
- the arguments are the same. If the `-a' option is present, only
- watches for the specified actions are removed.
-
-
- When the conditions exist for notification, CVS calls the `notify'
-administrative file. Edit `notify' as one edits the other
-administrative files (*note Intro administrative files::.). This file
-follows the usual conventions for administrative files (*note
-syntax::.), where each line is a regular expression followed by a
-command to execute. The command should contain a single ocurrence of
-`%s' which will be replaced by the user to notify; the rest of the
-information regarding the notification will be supplied to the command
-on standard input. The standard thing to put in the `notify' file is
-the single line:
-
- ALL mail %s -s \"CVS notification\"
-
- This causes users to be notified by electronic mail.
-
- Note that if you set this up in the straightforward way, users
-receive notifications on the server machine. One could of course write
-a `notify' script which directed notifications elsewhere, but to make
-this easy, CVS allows you to associate a notification address for each
-user. To do so create a file `users' in `CVSROOT' with a line for each
-user in the format USER:VALUE. Then instead of passing the name of the
-user to be notified to `notify', CVS will pass the VALUE (normally an
-email address on some other machine).
-
-How to edit a file which is being watched
------------------------------------------
-
- Since a file which is being watched is checked out read-only, you
-cannot simply edit it. To make it read-write, and inform others that
-you are planning to edit it, use the `cvs edit' command. Some systems
-call this a "checkout", but CVS uses that term for obtaining a copy of
-the sources (*note Getting the source::.), an operation which those
-systems call a "get" or a "fetch".
-
- - Command: cvs edit [OPTIONS] FILES ...
- Prepare to edit the working files FILES. CVS makes the FILES
- read-write, and notifies users who have requested `edit'
- notification for any of FILES.
-
- The `cvs edit' command accepts the same OPTIONS as the `cvs watch
- add' command, and establishes a temporary watch for the user on
- FILES; CVS will remove the watch when FILES are `unedit'ed or
- `commit'ted. If the user does not wish to receive notifications,
- she should specify `-a none'.
-
- The FILES and `-l' option are processed as for the `cvs watch'
- commands.
-
-
- Normally when you are done with a set of changes, you use the `cvs
-commit' command, which checks in your changes and returns the watched
-files to their usual read-only state. But if you instead decide to
-abandon your changes, or not to make any changes, you can use the `cvs
-unedit' command.
-
- - Command: cvs unedit [`-l'] FILES ...
- Abandon work on the working files FILES, and revert them to the
- repository versions on which they are based. CVS makes those
- FILES read-only for which users have requested notification using
- `cvs watch on'. CVS notifies users who have requested `unedit'
- notification for any of FILES.
-
- The FILES and `-l' option are processed as for the `cvs watch'
- commands.
-
- If watches are not in use, the `unedit' command probably does not
- work, and the way to revert to the repository version is to remove
- the file and then use `cvs update' to get a new copy. The meaning
- is not precisely the same; removing and updating may also bring in
- some changes which have been made in the repository since the last
- time you updated.
-
- When using client/server CVS, you can use the `cvs edit' and `cvs
-unedit' commands even if CVS is unable to succesfully communicate with
-the server; the notifications will be sent upon the next successful CVS
-command.
-
-Information about who is watching and editing
----------------------------------------------
-
- - Command: cvs watchers [`-l'] FILES ...
- List the users currently watching changes to FILES. The report
- includes the files being watched, and the mail address of each
- watcher.
-
- The FILES and `-l' arguments are processed as for the `cvs watch'
- commands.
-
-
- - Command: cvs editors [`-l'] FILES ...
- List the users currently working on FILES. The report includes
- the mail address of each user, the time when the user began
- working with the file, and the host and path of the working
- directory containing the file.
-
- The FILES and `-l' arguments are processed as for the `cvs watch'
- commands.
-
-
-Using watches with old versions of CVS
---------------------------------------
-
- If you use the watch features on a repository, it creates `CVS'
-directories in the repository and stores the information about watches
-in that directory. If you attempt to use CVS 1.6 or earlier with the
-repository, you get an error message such as
-
- cvs update: cannot open CVS/Entries for reading: No such file or directory
-
- and your operation will likely be aborted. To use the watch
-features, you must upgrade all copies of CVS which use that repository
-in local or server mode. If you cannot upgrade, use the `watch off' and
-`watch remove' commands to remove all watches, and that will restore
-the repository to a state which CVS 1.6 can cope with.
-
-Choosing between reserved or unreserved checkouts
-=================================================
-
- Reserved and unreserved checkouts each have pros and cons. Let it
-be said that a lot of this is a matter of opinion or what works given
-different groups' working styles, but here is an attempt to briefly
-describe the issues. There are many ways to organize a team of
-developers. CVS does not try to enforce a certain organization. It is
-a tool that can be used in several ways.
-
- Reserved checkouts can be very counter-productive. If two persons
-want to edit different parts of a file, there may be no reason to
-prevent either of them from doing so. Also, it is common for someone
-to take out a lock on a file, because they are planning to edit it, but
-then forget to release the lock.
-
- People, especially people who are familiar with reserved checkouts,
-often wonder how often conflicts occur if unreserved checkouts are
-used, and how difficult they are to resolve. The experience with many
-groups is that they occur rarely and usually are relatively
-straightforward to resolve.
-
- The rarity of serious conflicts may be surprising, until one realizes
-that they occur only when two developers disagree on the proper design
-for a given section of code; such a disagreement suggests that the team
-has not been communicating properly in the first place. In order to
-collaborate under *any* source management regimen, developers must
-agree on the general design of the system; given this agreement,
-overlapping changes are usually straightforward to merge.
-
- In some cases unreserved checkouts are clearly inappropriate. If no
-merge tool exists for the kind of file you are managing (for example
-word processor files or files edited by Computer Aided Design
-programs), and it is not desirable to change to a program which uses a
-mergeable data format, then resolving conflicts is going to be
-unpleasant enough that you generally will be better off to simply avoid
-the conflicts instead, by using reserved checkouts.
-
- The watches features described above in *Note Watches:: can be
-considered to be an intermediate model between reserved checkouts and
-unreserved checkouts. When you go to edit a file, it is possible to
-find out who else is editing it. And rather than having the system
-simply forbid both people editing the file, it can tell you what the
-situation is and let you figure out whether it is a problem in that
-particular case or not. Therefore, for some groups it can be
-considered the best of both the reserved checkout and unreserved
-checkout worlds.
-
-Branches
-********
-
- So far, all revisions shown in this manual have been on the "main
-trunk" of the revision tree, i.e., all revision numbers have been of
-the form X.Y. One useful feature, especially when maintaining several
-releases of a software product at once, is the ability to make branches
-on the revision tree. "Tags", symbolic names for revisions, will also
-be introduced in this chapter.
-
-Tags-Symbolic revisions
-=======================
-
- The revision numbers live a life of their own. They need not have
-anything at all to do with the release numbers of your software
-product. Depending on how you use CVS the revision numbers might
-change several times between two releases. As an example, some of the
-source files that make up RCS 5.6 have the following revision numbers:
-
- ci.c 5.21
- co.c 5.9
- ident.c 5.3
- rcs.c 5.12
- rcsbase.h 5.11
- rcsdiff.c 5.10
- rcsedit.c 5.11
- rcsfcmp.c 5.9
- rcsgen.c 5.10
- rcslex.c 5.11
- rcsmap.c 5.2
- rcsutil.c 5.10
-
- You can use the `tag' command to give a symbolic name to a certain
-revision of a file. You can use the `-v' flag to the `status' command
-to see all tags that a file has, and which revision numbers they
-represent. Tag names can contain uppercase and lowercase letters,
-digits, `-', and `_'. The two tag names `BASE' and `HEAD' are reserved
-for use by CVS. It is expected that future names which are special to
-CVS will contain characters such as `%' or `=', rather than being named
-analogously to `BASE' and `HEAD', to avoid conflicts with actual tag
-names.
-
- The following example shows how you can add a tag to a file. The
-commands must be issued inside your working copy of the module. That
-is, you should issue the command in the directory where `backend.c'
-resides.
-
- $ cvs tag release-0-4 backend.c
- T backend.c
- $ cvs status -v backend.c
- ===================================================================
- File: backend.c Status: Up-to-date
-
- Version: 1.4 Tue Dec 1 14:39:01 1992
- RCS Version: 1.4 /usr/local/cvsroot/yoyodyne/tc/backend.c,v
- Sticky Tag: (none)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-0-4 (revision: 1.4)
-
- There is seldom reason to tag a file in isolation. A more common
-use is to tag all the files that constitute a module with the same tag
-at strategic points in the development life-cycle, such as when a
-release is made.
-
- $ cvs tag release-1-0 .
- cvs tag: Tagging .
- T Makefile
- T backend.c
- T driver.c
- T frontend.c
- T parser.c
-
- (When you give CVS a directory as argument, it generally applies the
-operation to all the files in that directory, and (recursively), to any
-subdirectories that it may contain. *Note Recursive behavior::.)
-
- The `checkout' command has a flag, `-r', that lets you check out a
-certain revision of a module. This flag makes it easy to retrieve the
-sources that make up release 1.0 of the module `tc' at any time in the
-future:
-
- $ cvs checkout -r release-1-0 tc
-
-This is useful, for instance, if someone claims that there is a bug in
-that release, but you cannot find the bug in the current working copy.
-
- You can also check out a module as it was at any given date. *Note
-checkout options::.
-
- When you tag more than one file with the same tag you can think
-about the tag as "a curve drawn through a matrix of filename vs.
-revision number." Say we have 5 files with the following revisions:
-
- file1 file2 file3 file4 file5
-
- 1.1 1.1 1.1 1.1 /--1.1* <-*- TAG
- 1.2*- 1.2 1.2 -1.2*-
- 1.3 \- 1.3*- 1.3 / 1.3
- 1.4 \ 1.4 / 1.4
- \-1.5*- 1.5
- 1.6
-
- At some time in the past, the `*' versions were tagged. You can
-think of the tag as a handle attached to the curve drawn through the
-tagged revisions. When you pull on the handle, you get all the tagged
-revisions. Another way to look at it is that you "sight" through a set
-of revisions that is "flat" along the tagged revisions, like this:
-
- file1 file2 file3 file4 file5
-
- 1.1
- 1.2
- 1.1 1.3 _
- 1.1 1.2 1.4 1.1 /
- 1.2*----1.3*----1.5*----1.2*----1.1 (--- <--- Look here
- 1.3 1.6 1.3 \_
- 1.4 1.4
- 1.5
-
-What branches are good for
-==========================
-
- Suppose that release 1.0 of tc has been made. You are continuing to
-develop tc, planning to create release 1.1 in a couple of months.
-After a while your customers start to complain about a fatal bug. You
-check out release 1.0 (*note Tags::.) and find the bug (which turns out
-to have a trivial fix). However, the current revision of the sources
-are in a state of flux and are not expected to be stable for at least
-another month. There is no way to make a bugfix release based on the
-newest sources.
-
- The thing to do in a situation like this is to create a "branch" on
-the revision trees for all the files that make up release 1.0 of tc.
-You can then make modifications to the branch without disturbing the
-main trunk. When the modifications are finished you can select to
-either incorporate them on the main trunk, or leave them on the branch.
-
-Creating a branch
-=================
-
- The `rtag' command can be used to create a branch. The `rtag'
-command is much like `tag', but it does not require that you have a
-working copy of the module. *Note rtag::. (You can also use the `tag'
-command; *note tag::.).
-
- $ cvs rtag -b -r release-1-0 release-1-0-patches tc
-
- The `-b' flag makes `rtag' create a branch (rather than just a
-symbolic revision name). `-r release-1-0' says that this branch should
-be rooted at the node (in the revision tree) that corresponds to the tag
-`release-1-0'. Note that the numeric revision number that matches
-`release-1-0' will probably be different from file to file. The name
-of the new branch is `release-1-0-patches', and the module affected is
-`tc'.
-
- To fix the problem in release 1.0, you need a working copy of the
-branch you just created.
-
- $ cvs checkout -r release-1-0-patches tc
- $ cvs status -v driver.c backend.c
- ===================================================================
- File: driver.c Status: Up-to-date
-
- Version: 1.7 Sat Dec 5 18:25:54 1992
- RCS Version: 1.7 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
- Sticky Tag: release-1-0-patches (branch: 1.7.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.7.2)
- release-1-0 (revision: 1.7)
-
- ===================================================================
- File: backend.c Status: Up-to-date
-
- Version: 1.4 Tue Dec 1 14:39:01 1992
- RCS Version: 1.4 /usr/local/cvsroot/yoyodyne/tc/backend.c,v
- Sticky Tag: release-1-0-patches (branch: 1.4.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.4.2)
- release-1-0 (revision: 1.4)
- release-0-4 (revision: 1.4)
-
- As the output from the `status' command shows the branch number is
-created by adding a digit at the tail of the revision number it is
-based on. (If `release-1-0' corresponds to revision 1.4, the branch's
-revision number will be 1.4.2. For obscure reasons CVS always gives
-branches even numbers, starting at 2. *Note Revision numbers::).
-
-Sticky tags
-===========
-
- The `-r release-1-0-patches' flag that was given to `checkout' in
-the previous example is "sticky", that is, it will apply to subsequent
-commands in this directory. If you commit any modifications, they are
-committed on the branch. You can later merge the modifications into
-the main trunk. *Note Merging::.
-
- You can use the `status' command to see what sticky tags or dates
-are set:
-
- $ vi driver.c # Fix the bugs
- $ cvs commit -m "Fixed initialization bug" driver.c
- Checking in driver.c;
- /usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
- new revision: 1.7.2.1; previous revision: 1.7
- done
- $ cvs status -v driver.c
- ===================================================================
- File: driver.c Status: Up-to-date
-
- Version: 1.7.2.1 Sat Dec 5 19:35:03 1992
- RCS Version: 1.7.2.1 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
- Sticky Tag: release-1-0-patches (branch: 1.7.2)
- Sticky Date: (none)
- Sticky Options: (none)
-
- Existing Tags:
- release-1-0-patches (branch: 1.7.2)
- release-1-0 (revision: 1.7)
-
- The sticky tags will remain on your working files until you delete
-them with `cvs update -A'. The `-A' option retrieves the version of
-the file from the head of the trunk, and forgets any sticky tags,
-dates, or options.
-
- Sticky tags are not just for branches. For example, suppose that
-you want to avoid updating your working directory, to isolate yourself
-from possibly destabilizing changes other people are making. You can,
-of course, just refrain from running `cvs update'. But if you want to
-avoid updating only a portion of a larger tree, then sticky tags can
-help. If you check out a certain revision (such as 1.4) it will become
-sticky. Subsequent `cvs update' will not retrieve the latest revision
-until you reset the tag with `cvs update -A'. Likewise, use of the
-`-D' option to `update' or `checkout' sets a "sticky date", which,
-similarly, causes that date to be used for future retrievals.
-
- Many times you will want to retrieve an old version of a file
-without setting a sticky tag. The way to do that is with the `-p'
-option to `checkout' or `update', which sends the contents of the file
-to standard output. For example, suppose you have a file named `file1'
-which existed as revision 1.1, and you then removed it (thus adding a
-dead revision 1.2). Now suppose you want to add it again, with the same
-contents it had previously. Here is how to do it:
-
- $ cvs update -p -r 1.1 file1 >file1
- ===================================================================
- Checking out file1
- RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
- VERS: 1.1
- ***************
- $ cvs add file1
- cvs add: re-adding file file1 (in place of dead revision 1.2)
- cvs add: use 'cvs commit' to add this file permanently
- $ cvs commit -m test
- Checking in file1;
- /tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1
- new revision: 1.3; previous revision: 1.2
- done
- $
-
-Merging
-*******
-
- You can include the changes made between any two revisions into your
-working copy, by "merging". You can then commit that revision, and
-thus effectively copy the changes onto another branch.
-
-Merging an entire branch
-========================
-
- You can merge changes made on a branch into your working copy by
-giving the `-j BRANCH' flag to the `update' command. With one `-j
-BRANCH' option it merges the changes made between the point where the
-branch forked and newest revision on that branch (into your working
-copy).
-
- The `-j' stands for "join".
-
- Consider this revision tree:
-
- +-----+ +-----+ +-----+ +-----+
- ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- The main trunk
- +-----+ +-----+ +-----+ +-----+
- !
- !
- ! +---------+ +---------+
- Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
- +---------+ +---------+
-
-The branch 1.2.2 has been given the tag (symbolic name) `R1fix'. The
-following example assumes that the module `mod' contains only one file,
-`m.c'.
-
- $ cvs checkout mod # Retrieve the latest revision, 1.4
-
- $ cvs update -j R1fix m.c # Merge all changes made on the branch,
- # i.e. the changes between revision 1.2
- # and 1.2.2.2, into your working copy
- # of the file.
-
- $ cvs commit -m "Included R1fix" # Create revision 1.5.
-
- A conflict can result from a merge operation. If that happens, you
-should resolve it before committing the new revision. *Note Conflicts
-example::.
-
- The `checkout' command also supports the `-j BRANCH' flag. The same
-effect as above could be achieved with this:
-
- $ cvs checkout -j R1fix mod
- $ cvs commit -m "Included R1fix"
-
-Merging from a branch several times
-===================================
-
- Continuing our example, the revision tree now looks like this:
-
- +-----+ +-----+ +-----+ +-----+ +-----+
- ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
- +-----+ +-----+ +-----+ +-----+ +-----+
- ! *
- ! *
- ! +---------+ +---------+
- Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
- +---------+ +---------+
-
- where the starred line represents the merge from the `R1fix' branch
-to the main trunk, as just discussed.
-
- Now suppose that development continues on the `R1fix' branch:
-
- +-----+ +-----+ +-----+ +-----+ +-----+
- ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
- +-----+ +-----+ +-----+ +-----+ +-----+
- ! *
- ! *
- ! +---------+ +---------+ +---------+
- Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
- +---------+ +---------+ +---------+
-
- and then you want to merge those new changes onto the main trunk.
-If you just use the `cvs update -j R1fix m.c' command again, CVS will
-attempt to merge again the changes which you have already merged, which
-can have undesirable side effects.
-
- So instead you need to specify that you only want to merge the
-changes on the branch which have not yet been merged into the trunk.
-To do that you specify two `-j' options, and CVS merges the changes from
-the first revision to the second revision. For example, in this case
-the simplest way would be
-
- cvs update -j 1.2.2.2 -j R1fix m.c # Merge changes from 1.2.2.2 to the
- # head of the R1fix branch
-
- The problem with this is that you need to specify the 1.2.2.2
-revision manually. A slightly better approach might be to use the date
-the last merge was done:
-
- cvs update -j R1fix:yesterday -j R1fix m.c
-
- Better yet, tag the R1fix branch after every merge into the trunk,
-and then use that tag for subsequent merges:
-
- cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
-
-Merging differences between any two revisions
-=============================================
-
- With two `-j REVISION' flags, the `update' (and `checkout') command
-can merge the differences between any two revisions into your working
-file.
-
- $ cvs update -j 1.5 -j 1.3 backend.c
-
-will *remove* all changes made between revision 1.3 and 1.5. Note the
-order of the revisions!
-
- If you try to use this option when operating on multiple files,
-remember that the numeric revisions will probably be very different
-between the various files that make up a module. You almost always use
-symbolic tags rather than revision numbers when operating on multiple
-files.
-
-Merging can add or remove files
-===============================
-
- If the changes which you are merging involve removing or adding some
-files, `update -j' will reflect such additions or removals.
-
- For example:
- cvs update -A
- touch a b c
- cvs add a b c ; cvs ci -m "added" a b c
- cvs tag -b branchtag
- cvs update -r branchtag
- touch d ; cvs add d
- rm a ; cvs rm a
- cvs ci -m "added d, removed a"
- cvs update -A
- cvs update -jbranchtag
-
-Recursive behavior
-******************
-
- Almost all of the subcommands of CVS work recursively when you
-specify a directory as an argument. For instance, consider this
-directory structure:
-
- `$HOME'
- |
- +--tc
- | |
- +--CVS
- | (internal CVS files)
- +--Makefile
- +--backend.c
- +--driver.c
- +--frontend.c
- +--parser.c
- +--man
- | |
- | +--CVS
- | | (internal CVS files)
- | +--tc.1
- |
- +--testing
- |
- +--CVS
- | (internal CVS files)
- +--testpgm.t
- +--test2.t
-
-If `tc' is the current working directory, the following is true:
-
- * `cvs update testing' is equivalent to `cvs update
- testing/testpgm.t testing/test2.t'
-
- * `cvs update testing man' updates all files in the subdirectories
-
- * `cvs update .' or just `cvs update' updates all files in the `tc'
- module
-
- If no arguments are given to `update' it will update all files in
-the current working directory and all its subdirectories. In other
-words, `.' is a default argument to `update'. This is also true for
-most of the CVS subcommands, not only the `update' command.
-
- The recursive behavior of the CVS subcommands can be turned off with
-the `-l' option.
-
- $ cvs update -l # Don't update files in subdirectories
-
-Adding files to a directory
-***************************
-
- To add a new file to a directory, follow these steps.
-
- * You must have a working copy of the directory. *Note Getting the
- source::.
-
- * Create the new file inside your working copy of the directory.
-
- * Use `cvs add FILENAME' to tell CVS that you want to version
- control the file. If the file contains binary data, specify `-kb'
- (*note Binary files::.).
-
- * Use `cvs commit FILENAME' to actually check in the file into the
- repository. Other developers cannot see the file until you
- perform this step.
-
- You can also use the `add' command to add a new directory.
-
- Unlike most other commands, the `add' command is not recursive. You
-cannot even type `cvs add foo/bar'! Instead, you have to
-
- $ cd foo
- $ cvs add bar
-
- - Command: cvs add [`-k' KFLAG] [`-m' MESSAGE] FILES ...
- Schedule FILES to be added to the repository. The files or
- directories specified with `add' must already exist in the current
- directory. To add a whole new directory hierarchy to the source
- repository (for example, files received from a third-party
- vendor), use the `import' command instead. *Note import::.
-
- The added files are not placed in the source repository until you
- use `commit' to make the change permanent. Doing an `add' on a
- file that was removed with the `remove' command will undo the
- effect of the `remove', unless a `commit' command intervened.
- *Note Removing files::, for an example.
-
- The `-k' option specifies the default way that this file will be
- checked out; for more information see *Note Substitution modes::.
-
- The `-m' option specifies a description for the file. This
- description appears in the history log (if it is enabled, *note
- history file::.). It will also be saved in the version history
- inside the repository when the file is committed. The `log'
- command displays this description. The description can be changed
- using `admin -t'. *Note admin::. If you omit the `-m
- DESCRIPTION' flag, an empty string will be used. You will not be
- prompted for a description.
-
- For example, the following commands add the file `backend.c' to the
-repository:
-
- $ cvs add backend.c
- $ cvs commit -m "Early version. Not yet compilable." backend.c
-
- When you add a file it is added only on the branch which you are
-working on (*note Branches::.). You can later merge the additions to
-another branch if you want (*note Merging adds and removals::.).
-
-Removing files from a module
-****************************
-
- Modules change. New files are added, and old files disappear.
-Still, you want to be able to retrieve an exact copy of old releases of
-the module.
-
- Here is what you can do to remove a file from a module, but remain
-able to retrieve old revisions:
-
- * Make sure that you have not made any uncommitted modifications to
- the file. *Note Viewing differences::, for one way to do that.
- You can also use the `status' or `update' command. If you remove
- the file without committing your changes, you will of course not
- be able to retrieve the file as it was immediately before you
- deleted it.
-
- * Remove the file from your working copy of the module. You can for
- instance use `rm'.
-
- * Use `cvs remove FILENAME' to tell CVS that you really want to
- delete the file.
-
- * Use `cvs commit FILENAME' to actually perform the removal of the
- file from the repository.
-
- When you commit the removal of the file, CVS records the fact that
-the file no longer exists. It is possible for a file to exist on only
-some branches and not on others, or to re-add another file with the same
-name later. CVS will correctly create or not create the file, based on
-the `-r' and `-D' options specified to `checkout' or `update'.
-
- - Command: cvs remove [`-lR'] FILES ...
- Schedule file(s) to be removed from the repository (files which
- have not already been removed from the working directory are not
- processed). This command does not actually remove the file from
- the repository until you commit the removal. The `-R' option (the
- default) specifies that it will recurse into subdirectories; `-l'
- specifies that it will not.
-
- Here is an example of removing several files:
-
- $ cd test
- $ rm ?.c
- $ cvs remove
- cvs remove: Removing .
- cvs remove: scheduling a.c for removal
- cvs remove: scheduling b.c for removal
- cvs remove: use 'cvs commit' to remove these files permanently
- $ cvs ci -m "Removed unneeded files"
- cvs commit: Examining .
- cvs commit: Committing .
-
- If you change your mind you can easily resurrect the file before you
-commit it, using the `add' command.
-
- $ ls
- CVS ja.h oj.c
- $ rm oj.c
- $ cvs remove oj.c
- cvs remove: scheduling oj.c for removal
- cvs remove: use 'cvs commit' to remove this file permanently
- $ cvs add oj.c
- U oj.c
- cvs add: oj.c, version 1.1.1.1, resurrected
-
- If you realize your mistake before you run the `remove' command you
-can use `update' to resurrect the file:
-
- $ rm oj.c
- $ cvs update oj.c
- cvs update: warning: oj.c was lost
- U oj.c
-
- When you remove a file it is added only on the branch which you are
-working on (*note Branches::.). You can later merge the additions to
-another branch if you want (*note Merging adds and removals::.).
-
-Tracking third-party sources
-****************************
-
- If you modify a program to better fit your site, you probably want
-to include your modifications when the next release of the program
-arrives. CVS can help you with this task.
-
- In the terminology used in CVS, the supplier of the program is
-called a "vendor". The unmodified distribution from the vendor is
-checked in on its own branch, the "vendor branch". CVS reserves branch
-1.1.1 for this use.
-
- When you modify the source and commit it, your revision will end up
-on the main trunk. When a new release is made by the vendor, you
-commit it on the vendor branch and copy the modifications onto the main
-trunk.
-
- Use the `import' command to create and update the vendor branch.
-After a successful `import' the vendor branch is made the `head'
-revision, so anyone that checks out a copy of the file gets that
-revision. When a local modification is committed it is placed on the
-main trunk, and made the `head' revision.
-
-Importing a module for the first time
-=====================================
-
- Use the `import' command to check in the sources for the first time.
-When you use the `import' command to track third-party sources, the
-"vendor tag" and "release tags" are useful. The "vendor tag" is a
-symbolic name for the branch (which is always 1.1.1, unless you use the
-`-b BRANCH' flag--*Note import options::). The "release tags" are
-symbolic names for a particular release, such as `FSF_0_04'.
-
- Suppose you use `wdiff' (a variant of `diff' that ignores changes
-that only involve whitespace), and are going to make private
-modifications that you want to be able to use even when new releases
-are made in the future. You start by importing the source to your
-repository:
-
- $ tar xfz wdiff-0.04.tar.gz
- $ cd wdiff-0.04
- $ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
-
- The vendor tag is named `FSF_DIST' in the above example, and the
-only release tag assigned is `WDIFF_0_04'.
-
-Updating a module with the import command
-=========================================
-
- When a new release of the source arrives, you import it into the
-repository with the same `import' command that you used to set up the
-repository in the first place. The only difference is that you specify
-a different release tag this time.
-
- $ tar xfz wdiff-0.05.tar.gz
- $ cd wdiff-0.05
- $ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
-
- For files that have not been modified locally, the newly created
-revision becomes the head revision. If you have made local changes,
-`import' will warn you that you must merge the changes into the main
-trunk, and tell you to use `checkout -j' to do so.
-
- $ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
-
-The above command will check out the latest revision of `wdiff',
-merging the changes made on the vendor branch `FSF_DIST' since
-yesterday into the working copy. If any conflicts arise during the
-merge they should be resolved in the normal way (*note Conflicts
-example::.). Then, the modified files may be committed.
-
- Using a date, as suggested above, assumes that you do not import
-more than one release of a product per day. If you do, you can always
-use something like this instead:
-
- $ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
-
-In this case, the two above commands are equivalent.
-
-How to handle binary files with cvs import
-==========================================
-
- Use the `-k' wrapper option to tell import which files are binary.
-*Note Wrappers::.
-
-Moving and renaming files
-*************************
-
- Moving files to a different directory or renaming them is not
-difficult, but some of the ways in which this works may be non-obvious.
-(Moving or renaming a directory is even harder. *Note Moving
-directories::).
-
- The examples below assume that the file OLD is renamed to NEW.
-
-The Normal way to Rename
-========================
-
- The normal way to move a file is to copy OLD to NEW, and then issue
-the normal CVS commands to remove OLD from the repository, and add NEW
-to it. (Both OLD and NEW could contain relative paths, for example
-`foo/bar.c').
-
- $ mv OLD NEW
- $ cvs remove OLD
- $ cvs add NEW
- $ cvs commit -m "Renamed OLD to NEW" OLD NEW
-
- This is the simplest way to move a file, it is not error-prone, and
-it preserves the history of what was done. Note that to access the
-history of the file you must specify the old or the new name, depending
-on what portion of the history you are accessing. For example, `cvs
-log OLD' will give the log up until the time of the rename.
-
- When NEW is committed its revision numbers will start at 1.0 again,
-so if that bothers you, use the `-r rev' option to commit (*note commit
-options::.)
-
-Moving the history file
-=======================
-
- This method is more dangerous, since it involves moving files inside
-the repository. Read this entire section before trying it out!
-
- $ cd $CVSROOT/MODULE
- $ mv OLD,v NEW,v
-
-Advantages:
-
- * The log of changes is maintained intact.
-
- * The revision numbers are not affected.
-
-Disadvantages:
-
- * Old releases of the module cannot easily be fetched from the
- repository. (The file will show up as NEW even in revisions from
- the time before it was renamed).
-
- * There is no log information of when the file was renamed.
-
- * Nasty things might happen if someone accesses the history file
- while you are moving it. Make sure no one else runs any of the CVS
- commands while you move it.
-
-Copying the history file
-========================
-
- This way also involves direct modifications to the repository. It
-is safe, but not without drawbacks.
-
- # Copy the RCS file inside the repository
- $ cd $CVSROOT/MODULE
- $ cp OLD,v NEW,v
- # Remove the old file
- $ cd ~/MODULE
- $ rm OLD
- $ cvs remove OLD
- $ cvs commit OLD
- # Remove all tags from NEW
- $ cvs update NEW
- $ cvs log NEW # Remember the non-branch tag names
- $ cvs tag -d TAG1 NEW
- $ cvs tag -d TAG2 NEW
- ...
-
- By removing the tags you will be able to check out old revisions of
-the module.
-
-Advantages:
-
- * Checking out old revisions works correctly, as long as you use
- `-rTAG' and not `-DDATE' to retrieve the revisions.
-
- * The log of changes is maintained intact.
-
- * The revision numbers are not affected.
-
-Disadvantages:
-
- * You cannot easily see the history of the file across the rename.
-
- * Unless you use the `-r rev' (*note commit options::.) flag when
- NEW is committed its revision numbers will start at 1.0 again.
-
-Moving and renaming directories
-*******************************
-
- If you want to be able to retrieve old versions of the module, you
-must move each file in the directory with the CVS commands. *Note
-Outside::. The old, empty directory will remain inside the repository,
-but it will not appear in your workspace when you check out the module
-in the future.
-
- If you really want to rename or delete a directory, you can do it
-like this:
-
- 1. Inform everyone who has a copy of the module that the directory
- will be renamed. They should commit all their changes, and remove
- their working copies of the module, before you take the steps
- below.
-
- 2. Rename the directory inside the repository.
-
- $ cd $CVSROOT/MODULE
- $ mv OLD-DIR NEW-DIR
-
- 3. Fix the CVS administrative files, if necessary (for instance if
- you renamed an entire module).
-
- 4. Tell everyone that they can check out the module and continue
- working.
-
-
- If someone had a working copy of the module the CVS commands will
-cease to work for him, until he removes the directory that disappeared
-inside the repository.
-
- It is almost always better to move the files in the directory
-instead of moving the directory. If you move the directory you are
-unlikely to be able to retrieve old releases correctly, since they
-probably depend on the name of the directories.
-
-History browsing
-****************
-
- Once you have used CVS to store a version control history--what
-files have changed when, how, and by whom, there are a variety of
-mechanisms for looking through the history.
-
-Log messages
-============
-
- Whenever you commit a file you specify a log message.
-
- To look through the log messages which have been specified for every
-revision which has been committed, use the `cvs log' command (*note
-log::.).
-
-The history database
-====================
-
- You can use the history file (*note history file::.) to log various
-CVS actions. To retrieve the information from the history file, use
-the `cvs history' command (*note history::.).
-
-User-defined logging
-====================
-
- You can customize CVS to log various kinds of actions, in whatever
-manner you choose. These mechanisms operate by executing a script at
-various times. The script might append a message to a file listing the
-information and the programmer who created it, or send mail to a group
-of developers, or, perhaps, post a message to a particular newsgroup.
-To log commits, use the `loginfo' file (*note loginfo::.). To log
-commits, checkouts, exports, and tags, respectively, you can also use
-the `-i', `-o', `-e', and `-t' options in the modules file. For a more
-flexible way of giving notifications to various users, which requires
-less in the way of keeping centralized scripts up to date, use the `cvs
-watch add' command (*note Getting Notified::.); this command is useful
-even if you are not using `cvs watch on'.
-
- The `taginfo' file defines programs to execute when someone executes
-a `tag' or `rtag' command. The `taginfo' file has the standard form
-for administrative files (*note Administrative files::.), where each
-line is a regular expression followed by a command to execute. The
-arguments passed to the command are, in order, the TAGNAME, OPERATION
-(`add' for `tag', `mov' for `tag -F', and `del' for `tag -d'),
-REPOSITORY, and any remaining are pairs of FILENAME REVISION. A
-non-zero exit of the filter program will cause the tag to be aborted.
-
-Annotate command
-================
-
- - Command: cvs annotate [`-lf'] [`-r rev'|`-D date'] FILES ...
- For each file in FILES, print the head revision of the trunk,
- together with information on the last modification for each line.
- For example:
-
- $ cvs annotate ssfile
- Annotations for ssfile
- ***************
- 1.1 (mary 27-Mar-96): ssfile line 1
- 1.2 (joe 28-Mar-96): ssfile line 2
-
- The file `ssfile' currently contains two lines. The `ssfile line
- 1' line was checked in by `mary' on March 27. Then, on March 28,
- `joe' added a line `ssfile line 2', without modifying the `ssfile
- line 1' line. This report doesn't tell you anything about lines
- which have been deleted or replaced; you need to use `cvs diff'
- for that (*note diff::.).
-
-
- These standard options are available with `annotate' (*note Common
-options::., for a complete description of them):
-
-`-D DATE'
- Annotate the most recent revision no later than DATE.
-
-`-f'
- Only useful with the `-D DATE' or `-r TAG' flags. If no matching
- revision is found, annotate the most recent revision (instead of
- ignoring the file).
-
-`-l'
- Local; run only in current working directory. *Note Recursive
- behavior::.
-
-`-r TAG'
- Annotate revision TAG.
-
-Keyword substitution
-********************
-
- As long as you edit source files inside your working copy of a
-module you can always find out the state of your files via `cvs status'
-and `cvs log'. But as soon as you export the files from your
-development environment it becomes harder to identify which revisions
-they are.
-
- RCS uses a mechanism known as "keyword substitution" (or "keyword
-expansion") to help identifying the files. Embedded strings of the form
-`$KEYWORD$' and `$KEYWORD:...$' in a file are replaced with strings of
-the form `$KEYWORD:VALUE$' whenever you obtain a new revision of the
-file.
-
-RCS Keywords
-============
-
- This is a list of the keywords that RCS currently (in release
-5.6.0.1) supports:
-
-`$Author: ward $'
- The login name of the user who checked in the revision.
-
-`$Date: 2009/06/08 20:47:05 $'
- The date and time (UTC) the revision was checked in.
-
-`$Header: /web/www/www/software/cvs/manual/text/Attic/cvs.txt,v 1.2 2009/06/08
20:47:05 ward Exp $'
- A standard header containing the full pathname of the RCS file,
- the revision number, the date (UTC), the author, the state, and
- the locker (if locked). Files will normally never be locked when
- you use CVS.
-
-`$Id: cvs.txt,v 1.2 2009/06/08 20:47:05 ward Exp $'
- Same as `$Header: /web/www/www/software/cvs/manual/text/Attic/cvs.txt,v
1.2 2009/06/08 20:47:05 ward Exp $', except that the RCS filename is without a
path.
-
-`$Name: $'
- Tag name used to check out this file.
-
-`$Locker: $'
- The login name of the user who locked the revision (empty if not
- locked, and thus almost always useless when you are using CVS).
-
-`$Log: cvs.txt,v $
-`Revision 1.2 2009/06/08 20:47:05 ward
-`changes that were lost from the CVS tree due to the savannah crash of
2009/05/29
-`
-`Revision 1.1 2003/11/07 20:55:33 sinuhe
-`Add manual.
-`'
- The log message supplied during commit, preceded by a header
- containing the RCS filename, the revision number, the author, and
- the date (UTC). Existing log messages are *not* replaced.
- Instead, the new log message is inserted after `$Log: cvs.txt,v $
- Instead, the new log message is inserted after `Revision 1.1 2003/11/07
20:55:33 sinuhe
- Instead, the new log message is inserted after `Add manual.
- Instead, the new log message is inserted after `'. Each
- new line is prefixed with a "comment leader" which RCS guesses
- from the file name extension. It can be changed with `cvs admin
- -c'. *Note admin options::. This keyword is useful for
- accumulating a complete change log in a source file, but for
- several reasons it can be problematic. *Note Log keyword::.
-
-`$RCSfile: cvs.txt,v $'
- The name of the RCS file without a path.
-
-`$Revision: 1.2 $'
- The revision number assigned to the revision.
-
-`$Source: /web/www/www/software/cvs/manual/text/Attic/cvs.txt,v $'
- The full pathname of the RCS file.
-
-`$State: Exp $'
- The state assigned to the revision. States can be assigned with
- `cvs admin -s'--*Note admin options::.
-
-Using keywords
-==============
-
- To include a keyword string you simply include the relevant text
-string, such as `$Id: cvs.txt,v 1.2 2009/06/08 20:47:05 ward Exp $', inside
the file, and commit the file. CVS will
-automatically expand the string as part of the commit operation.
-
- It is common to embed `$Id: cvs.txt,v 1.2 2009/06/08 20:47:05 ward Exp $'
string in the C source code. This
-example shows the first few lines of a typical file, after keyword
-substitution has been performed:
-
- static char *rcsid="$Id: cvs.txt,v 1.2 2009/06/08 20:47:05 ward Exp $";
- /* The following lines will prevent `gcc' version 2.X
- from issuing an "unused variable" warning. */
- #if __GNUC__ == 2
- #define USE(var) static void * use_##var = (&use_##var, (void *) &var)
- USE (rcsid);
- #endif
-
- Even though a clever optimizing compiler could remove the unused
-variable `rcsid', most compilers tend to include the string in the
-binary. Some compilers have a `#pragma' directive to include literal
-text in the binary.
-
- The `ident' command (which is part of the RCS package) can be used
-to extract keywords and their values from a file. This can be handy
-for text files, but it is even more useful for extracting keywords from
-binary files.
-
- $ ident samp.c
- samp.c:
- $Id: cvs.txt,v 1.2 2009/06/08 20:47:05 ward Exp $
- $ gcc samp.c
- $ ident a.out
- a.out:
- $Id: cvs.txt,v 1.2 2009/06/08 20:47:05 ward Exp $
-
- SCCS is another popular revision control system. It has a command,
-`what', which is very similar to `ident' and used for the same purpose.
-Many sites without RCS have SCCS. Since `what' looks for the
-character sequence `@(#)' it is easy to include keywords that are
-detected by either command. Simply prefix the RCS keyword with the
-magic SCCS phrase, like this:
-
- static char *id="@(#) $Id: cvs.txt,v 1.2 2009/06/08 20:47:05 ward Exp $";
-
-Avoiding substitution
-=====================
-
- Keyword substitution has its disadvantages. Sometimes you might
-want the literal text string `$Author: ward $' to appear inside a file without
-RCS interpreting it as a keyword and expanding it into something like
-`$Author: ward $'.
-
- There is unfortunately no way to selectively turn off keyword
-substitution. You can use `-ko' (*note Substitution modes::.) to turn
-off keyword substitution entirely.
-
- In many cases you can avoid using RCS keywords in the source, even
-though they appear in the final product. For example, the source for
-this manual contains address@hidden' whenever the text `$Author: ward $'
-should appear. In `nroff' and `troff' you can embed the null-character
-`\&' inside the keyword for a similar effect.
-
-Substitution modes
-==================
-
- Each file has a stored default substitution mode, and each working
-directory copy of a file also has a substitution mode. The former is
-set by the `-k' option to `cvs add' and `cvs admin'; the latter is set
-by the -k or -A options to `cvs checkout' or `cvs update'. `cvs diff'
-also has a `-k' option. For some examples, *Note Binary files::.
-
- The modes available are:
-
-`-kkv'
- Generate keyword strings using the default form, e.g. `$Revision:
- 5.7 $' for the `Revision' keyword.
-
-`-kkvl'
- Like `-kkv', except that a locker's name is always inserted if the
- given revision is currently locked. This option is normally not
- useful when CVS is used.
-
-`-kk'
- Generate only keyword names in keyword strings; omit their values.
- For example, for the `Revision' keyword, generate the string
- `$Revision: 1.2 $' instead of `$Revision: 1.2 $'. This option is useful
- to ignore differences due to keyword substitution when comparing
- different revisions of a file.
-
-`-ko'
- Generate the old keyword string, present in the working file just
- before it was checked in. For example, for the `Revision'
- keyword, generate the string `$Revision: 1.2 $' instead of
- `$Revision: 1.2 $' if that is how the string appeared when the
- file was checked in.
-
-`-kb'
- Like `-ko', but also inhibit conversion of line endings between
- the canonical form in which they are stored in the repository
- (linefeed only), and the form appropriate to the operating system
- in use on the client. For systems, like unix, which use linefeed
- only to terminate lines, this is the same as `-ko'. For more
- information on binary files, see *Note Binary files::.
-
-`-kv'
- Generate only keyword values for keyword strings. For example,
- for the `Revision' keyword, generate the string `5.7' instead of
- `$Revision: 1.2 $'. This can help generate files in programming
- languages where it is hard to strip keyword delimiters like
- `$Revision: 1.2 $' from a string. However, further keyword
- substitution cannot be performed once the keyword names are
- removed, so this option should be used with care.
-
- One often would like to use `-kv' with `cvs export'--*note
- export::.. But be aware that doesn't handle an export containing
- binary files correctly.
-
-Problems with the $Log: cvs.txt,v $
-Problems with the Revision 1.2 2009/06/08 20:47:05 ward
-Problems with the changes that were lost from the CVS tree due to the savannah
crash of 2009/05/29
-Problems with the
-Problems with the Revision 1.1 2003/11/07 20:55:33 sinuhe
-Problems with the Add manual.
-Problems with the keyword.
-================================
-
- The `$Log: cvs.txt,v $
- The `Revision 1.2 2009/06/08 20:47:05 ward
- The `changes that were lost from the CVS tree due to the savannah crash of
2009/05/29
- The `
- The `Revision 1.1 2003/11/07 20:55:33 sinuhe
- The `Add manual.
- The `' keyword is somewhat controversial. As long as you are
-working on your development system the information is easily accessible
-even if you do not use the `$Log: cvs.txt,v $
-even if you do not use the `Revision 1.1 2003/11/07 20:55:33 sinuhe
-even if you do not use the `Add manual.
-even if you do not use the `' keyword--just do a `cvs log'. Once
-you export the file the history information might be useless anyhow.
-
- A more serious concern is that RCS is not good at handling `$Log: cvs.txt,v
$
- A more serious concern is that RCS is not good at handling `Revision 1.1
2003/11/07 20:55:33 sinuhe
- A more serious concern is that RCS is not good at handling `Add manual.
- A more serious concern is that RCS is not good at handling `'
-entries when a branch is merged onto the main trunk. Conflicts often
-result from the merging operation.
-
- People also tend to "fix" the log entries in the file (correcting
-spelling mistakes and maybe even factual errors). If that is done the
-information from `cvs log' will not be consistent with the information
-inside the file. This may or may not be a problem in real life.
-
- It has been suggested that the `$Log: cvs.txt,v $
- It has been suggested that the `Revision 1.1 2003/11/07 20:55:33 sinuhe
- It has been suggested that the `Add manual.
- It has been suggested that the `' keyword should be inserted
-*last* in the file, and not in the files header, if it is to be used at
-all. That way the long list of change messages will not interfere with
-everyday source file browsing.
-
-Handling binary files
-*********************
-
- There are two issues with using CVS to store binary files. The
-first is that CVS by default convert line endings between the canonical
-form in which they are stored in the repository (linefeed only), and
-the form appropriate to the operating system in use on the client (for
-example, carriage return followed by line feed for Windows NT).
-
- The second is that a binary file might happen to contain data which
-looks like a keyword (*note Keyword substitution::.), so keyword
-expansion must be turned off.
-
- The `-kb' option available with some CVS commands insures that
-neither line ending conversion nor keyword expansion will be done. If
-you are using an old version of RCS without this option, and you are
-using an operating system, such as unix, which terminates lines with
-linefeeds only, you can use `-ko' instead; if you are on another
-operating system, upgrade to a version of RCS, such as 5.7 or later,
-which supports `-kb'.
-
- Here is an example of how you can create a new file using the `-kb'
-flag:
-
- $ echo '$Id: cvs.txt,v 1.2 2009/06/08 20:47:05 ward Exp $' > kotest
- $ cvs add -kb -m"A test file" kotest
- $ cvs ci -m"First checkin; contains a keyword" kotest
-
- If a file accidentally gets added without `-kb', one can use the
-`cvs admin' command to recover. For example:
-
- $ echo '$Id: cvs.txt,v 1.2 2009/06/08 20:47:05 ward Exp $' > kotest
- $ cvs add -m"A test file" kotest
- $ cvs ci -m"First checkin; contains a keyword" kotest
- $ cvs admin -kb kotest
- $ cvs update -A kotest
- $ cvs commit -m "make it binary" kotest # For non-unix systems
-
- When you check in the file `kotest' the keywords are expanded. (Try
-the above example, and do a `cat kotest' after every command). The `cvs
-admin -kb' command sets the default keyword substitution method for
-this file, but it does not alter the working copy of the file that you
-have. The easiest way to get the unexpanded version of `kotest' is
-`cvs update -A'. If you need to cope with line endings (that is, you
-are using a CVS client on a non-unix system), then you need to check in
-a new copy of the file, as shown by the `cvs commit' command above.
-
- However, in using `cvs admin -k' to change the keyword expansion, be
-aware that the keyword expansion mode is not version controlled. This
-means that, for example, that if you have a text file in old releases,
-and a binary file with the same name in new releases, CVS provides no
-way to check out the file in text or binary mode depending on what
-version you are checking out. There is no good workaround for this
-problem.
-
- You can also set a default for whether `cvs add' and `cvs import'
-treat a file as binary based on its name; for example you could say
-that files who names end in `.exe' are binary. *Note Wrappers::.
-
-Revision management
-*******************
-
- If you have read this far, you probably have a pretty good grasp on
-what CVS can do for you. This chapter talks a little about things that
-you still have to decide.
-
- If you are doing development on your own using CVS you could
-probably skip this chapter. The questions this chapter takes up become
-more important when more than one person is working in a repository.
-
-When to commit?
-===============
-
- Your group should decide which policy to use regarding commits.
-Several policies are possible, and as your experience with CVS grows
-you will probably find out what works for you.
-
- If you commit files too quickly you might commit files that do not
-even compile. If your partner updates his working sources to include
-your buggy file, he will be unable to compile the code. On the other
-hand, other persons will not be able to benefit from the improvements
-you make to the code if you commit very seldom, and conflicts will
-probably be more common.
-
- It is common to only commit files after making sure that they can be
-compiled. Some sites require that the files pass a test suite.
-Policies like this can be enforced using the commitinfo file (*note
-commitinfo::.), but you should think twice before you enforce such a
-convention. By making the development environment too controlled it
-might become too regimented and thus counter-productive to the real
-goal, which is to get software written.
-
-Reference manual for CVS commands
-*********************************
-
- This appendix describes how to invoke CVS, and describes in detail
-those subcommands of CVS which are not fully described elsewhere. To
-look up a particular subcommand, see *Note Index::.
-
-Overall structure of CVS commands
-=================================
-
- The overall format of all CVS commands is:
-
- cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
-
-`cvs'
- The name of the CVS program.
-
-`cvs_options'
- Some options that affect all sub-commands of CVS. These are
- described below.
-
-`cvs_command'
- One of several different sub-commands. Some of the commands have
- aliases that can be used instead; those aliases are noted in the
- reference manual for that command. There are only two situations
- where you may omit `cvs_command': `cvs -H' elicits a list of
- available commands, and `cvs -v' displays version information on
- CVS itself.
-
-`command_options'
- Options that are specific for the command.
-
-`command_args'
- Arguments to the commands.
-
- There is unfortunately some confusion between `cvs_options' and
-`command_options'. `-l', when given as a `cvs_option', only affects
-some of the commands. When it is given as a `command_option' is has a
-different meaning, and is accepted by more commands. In other words,
-do not take the above categorization too seriously. Look at the
-documentation instead.
-
-Default options and the ~/.cvsrc file
-=====================================
-
- There are some `command_options' that are used so often that you
-might have set up an alias or some other means to make sure you always
-specify that option. One example (the one that drove the
-implementation of the .cvsrc support, actually) is that many people
-find the default output of the `diff' command to be very hard to read,
-and that either context diffs or unidiffs are much easier to understand.
-
- The `~/.cvsrc' file is a way that you can add default options to
-`cvs_commands' within cvs, instead of relying on aliases or other shell
-scripts.
-
- The format of the `~/.cvsrc' file is simple. The file is searched
-for a line that begins with the same name as the `cvs_command' being
-executed. If a match is found, then the remainder of the line is split
-up (at whitespace characters) into separate options and added to the
-command arguments *before* any options from the command line.
-
- If a command has two names (e.g., `checkout' and `co'), the official
-name, not necessarily the one used on the command line, will be used to
-match against the file. So if this is the contents of the user's
-`~/.cvsrc' file:
-
- log -N
- diff -u
- update -P
- co -P
-
-the command `cvs checkout foo' would have the `-P' option added to the
-arguments, as well as `cvs co foo'.
-
- With the example file above, the output from `cvs diff foobar' will
-be in unidiff format. `cvs diff -c foobar' will provide context diffs,
-as usual. Getting "old" format diffs would be slightly more
-complicated, because `diff' doesn't have an option to specify use of
-the "old" format, so you would need `cvs -f diff foobar'.
-
- In place of the command name you can use `cvs' to specify global
-options (*note Global options::.). For example the following line in
-`.cvsrc'
-
- cvs -z6
-
- causes CVS to use compression level 6
-
-Global options
-==============
-
- The available `cvs_options' (that are given to the left of
-`cvs_command') are:
-
-`-b BINDIR'
- Use BINDIR as the directory where RCS programs are located.
- Overrides the setting of the `$RCSBIN' environment variable and
- any precompiled directory. This parameter should be specified as
- an absolute pathname.
-
-`-T TEMPDIR'
- Use TEMPDIR as the directory where temporary files are located.
- Overrides the setting of the `$TMPDIR' environment variable and
- any precompiled directory. This parameter should be specified as
- an absolute pathname.
-
-`-d CVS_ROOT_DIRECTORY'
- Use CVS_ROOT_DIRECTORY as the root directory pathname of the
- repository. Overrides the setting of the `$CVSROOT' environment
- variable. *Note Repository::.
-
-`-e EDITOR'
- Use EDITOR to enter revision log information. Overrides the
- setting of the `$CVSEDITOR' and `$EDITOR' environment variables.
-
-`-f'
- Do not read the `~/.cvsrc' file. This option is most often used
- because of the non-orthogonality of the CVS option set. For
- example, the `cvs log' option `-N' (turn off display of tag names)
- does not have a corresponding option to turn the display on. So
- if you have `-N' in the `~/.cvsrc' entry for `log', you may need
- to use `-f' to show the tag names.
-
-`-H'
- Display usage information about the specified `cvs_command' (but
- do not actually execute the command). If you don't specify a
- command name, `cvs -H' displays a summary of all the commands
- available.
-
-`-l'
- Do not log the cvs_command in the command history (but execute it
- anyway). *Note history::, for information on command history.
-
-`-n'
- Do not change any files. Attempt to execute the `cvs_command',
- but only to issue reports; do not remove, update, or merge any
- existing files, or create any new files.
-
-`-Q'
- Cause the command to be really quiet; the command will only
- generate output for serious problems.
-
-`-q'
- Cause the command to be somewhat quiet; informational messages,
- such as reports of recursion through subdirectories, are
- suppressed.
-
-`-r'
- Make new working files files read-only. Same effect as if the
- `$CVSREAD' environment variable is set (*note Environment
- variables::.). The default is to make working files writable,
- unless watches are on (*note Watches::.).
-
-`-s VARIABLE=VALUE'
- Set a user variable (*note Variables::.).
-
-`-t'
- Trace program execution; display messages showing the steps of CVS
- activity. Particularly useful with `-n' to explore the potential
- impact of an unfamiliar command.
-
-`-v'
- Display version and copyright information for CVS.
-
-`-w'
- Make new working files read-write. Overrides the setting of the
- `$CVSREAD' environment variable. Files are created read-write by
- default, unless `$CVSREAD' is set or `-r' is given.
-
-`-x'
- Encrypt all communication between the client and the server. Only
- has an effect on the CVS client. As of this writing, this is only
- implemented when using a Kerberos connection (*note Kerberos
- authenticated::.). Encryption support is not available by
- default; it must be enabled using a special configure option,
- `--enable-encryption', when you build CVS.
-
-`-z GZIP-LEVEL'
- Set the compression level. Only has an effect on the CVS client.
-
-Common command options
-======================
-
- This section describes the `command_options' that are available
-across several CVS commands. These options are always given to the
-right of `cvs_command'. Not all commands support all of these options;
-each option is only supported for commands where it makes sense.
-However, when a command has one of these options you can almost always
-count on the same behavior of the option as in other commands. (Other
-command options, which are listed with the individual commands, may have
-different behavior from one CVS command to the other).
-
- *Warning:* the `history' command is an exception; it supports many
-options that conflict even with these standard options.
-
-`-D DATE_SPEC'
- Use the most recent revision no later than DATE_SPEC. DATE_SPEC
- is a single argument, a date description specifying a date in the
- past.
-
- The specification is "sticky" when you use it to make a private
- copy of a source file; that is, when you get a working file using
- `-D', CVS records the date you specified, so that further updates
- in the same directory will use the same date (for more information
- on sticky tags/dates, *note Sticky tags::.).
-
- A wide variety of date formats are supported by CVS. The
- DATE_SPEC is interpreted as being in the local timezone, unless a
- specific timezone is specified. Examples of valid date
- specifications include:
-
- 1 month ago
- 2 hours ago
- 400000 seconds ago
- last year
- last Monday
- yesterday
- a fortnight ago
- 3/31/92 10:00:07 PST
- January 23, 1987 10:05pm
- 22:00 GMT
-
- `-D' is available with the `checkout', `diff', `export', `history',
- `rdiff', `rtag', and `update' commands. (The `history' command
- uses this option in a slightly different way; *note history
- options::.). Note that when specifying a date like `3/31/92' it is
- `MONTH/DAY/YEAR'. So `1/4/96' is January 4, not March 1.
-
- Remember to quote the argument to the `-D' flag so that your shell
- doesn't interpret spaces as argument separators. A command using
- the `-D' flag can look like this:
-
- $ cvs diff -D "1 hour ago" cvs.texinfo
-
-`-f'
- When you specify a particular date or tag to CVS commands, they
- normally ignore files that do not contain the tag (or did not
- exist prior to the date) that you specified. Use the `-f' option
- if you want files retrieved even when there is no match for the
- tag or date. (The most recent revision of the file will be used).
-
- `-f' is available with these commands: `checkout', `export',
- `rdiff', `rtag', and `update'.
-
- *Warning:* The `commit' command also has a `-f' option, but it
- has a different behavior for that command. *Note commit options::.
-
-`-H'
- Help; describe the options available for this command. This is
- the only option supported for all CVS commands.
-
-`-k KFLAG'
- Alter the default RCS processing of keywords. *Note Keyword
- substitution::, for the meaning of KFLAG. Your KFLAG
- specification is "sticky" when you use it to create a private copy
- of a source file; that is, when you use this option with the
- `checkout' or `update' commands, CVS associates your selected
- KFLAG with the file, and continues to use it with future update
- commands on the same file until you specify otherwise.
-
- The `-k' option is available with the `add', `checkout', `diff' and
- `update' commands.
-
-`-l'
- Local; run only in current working directory, rather than
- recursing through subdirectories.
-
- *Warning:* this is not the same as the overall `cvs -l' option,
- which you can specify to the left of a cvs command!
-
- Available with the following commands: `checkout', `commit',
- `diff', `export', `log', `remove', `rdiff', `rtag', `status',
- `tag', and `update'.
-
-`-m MESSAGE'
- Use MESSAGE as log information, instead of invoking an editor.
-
- Available with the following commands: `add', `commit' and
- `import'.
-
-`-n'
- Do not run any checkout/commit/tag program. (A program can be
- specified to run on each of these activities, in the modules
- database (*note modules::.); this option bypasses it).
-
- *Warning:* this is not the same as the overall `cvs -n' option,
- which you can specify to the left of a cvs command!
-
- Available with the `checkout', `commit', `export', and `rtag'
- commands.
-
-`-P'
- Prune (remove) directories that are empty after being updated, on
- `checkout', or `update'. Normally, an empty directory (one that
- is void of revision-controlled files) is left alone. Specifying
- `-P' will cause these directories to be silently removed from your
- checked-out sources. This does not remove the directory from the
- repository, only from your checked out copy. Note that this
- option is implied by the `-r' or `-D' options of `checkout' and
- `export'.
-
-`-p'
- Pipe the files retrieved from the repository to standard output,
- rather than writing them in the current directory. Available with
- the `checkout' and `update' commands.
-
-`-W'
- Specify file names that should be filtered. You can use this
- option repeatedly. The spec can be a file name pattern of the
- same type that you can specify in the `.cvswrappers' file.
- Avaliable with the following commands: `import', and `update'.
-
-`-r TAG'
- Use the revision specified by the TAG argument instead of the
- default "head" revision. As well as arbitrary tags defined with
- the `tag' or `rtag' command, two special tags are always
- available: `HEAD' refers to the most recent version available in
- the repository, and `BASE' refers to the revision you last checked
- out into the current working directory.
-
- The tag specification is sticky when you use this with `checkout'
- or `update' to make your own copy of a file: CVS remembers the tag
- and continues to use it on future update commands, until you
- specify otherwise (for more information on sticky tags/dates,
- *note Sticky tags::.). The tag can be either a symbolic or
- numeric tag. *Note Tags::.
-
- Specifying the `-q' global option along with the `-r' command
- option is often useful, to suppress the warning messages when the
- RCS history file does not contain the specified tag.
-
- *Warning:* this is not the same as the overall `cvs -r' option,
- which you can specify to the left of a cvs command!
-
- `-r' is available with the `checkout', `commit', `diff',
- `history', `export', `rdiff', `rtag', and `update' commands.
-
-admin--Administration front end for rcs
-=======================================
-
- * Requires: repository, working directory.
-
- * Changes: repository.
-
- * Synonym: rcs
-
- This is the CVS interface to assorted administrative RCS facilities,
-documented in rcs(1). `admin' simply passes all its options and
-arguments to the `rcs' command; it does no filtering or other
-processing. This command *does* work recursively, however, so extreme
-care should be used.
-
- If there is a group whose name matches a compiled in value which
-defaults to `cvsadmin', only members of that group can use `cvs admin'.
-To disallow `cvs admin' for all users, create a group with no users in
-it.
-
-admin options
--------------
-
- Not all valid `rcs' options are useful together with CVS. Some even
-makes it impossible to use CVS until you undo the effect!
-
- This description of the available options is based on the `rcs(1)'
-man page, but modified to suit readers that are more interrested in CVS
-than RCS.
-
-`-AOLDFILE'
- Might not work together with CVS. Append the access list of
- OLDFILE to the access list of the RCS file.
-
-`-aLOGINS'
- Might not work together with CVS. Append the login names
- appearing in the comma-separated list LOGINS to the access list of
- the RCS file.
-
-`-b[REV]'
- When used with bare RCS, this option sets the default branch to
- REV; in CVS sticky tags (*note Sticky tags::.) are a better way to
- decide which branch you want to work on. With CVS, this option
- can be used to control behavior with respect to the vendor branch.
-
-`-cSTRING'
- Useful with CVS. Sets the comment leader to STRING. The comment
- leader is printed before every log message line generated by the
- keyword `$Log: cvs.txt,v $
- keyword `Revision 1.2 2009/06/08 20:47:05 ward
- keyword `changes that were lost from the CVS tree due to the savannah
crash of 2009/05/29
- keyword `
- keyword `Revision 1.1 2003/11/07 20:55:33 sinuhe
- keyword `Add manual.
- keyword `' (*note Keyword substitution::.). This is useful
- for programming languages without multi-line comments. RCS
- initially guesses the value of the comment leader from the file
- name extension when the file is first committed.
-
-`-e[LOGINS]'
- Might not work together with CVS. Erase the login names appearing
- in the comma-separated list LOGINS from the access list of the RCS
- file. If LOGINS is omitted, erase the entire access list.
-
-`-I'
- Run interactively, even if the standard input is not a terminal.
-
-`-i'
- Useless with CVS. When using bare RCS, this is used to create and
- initialize a new RCS file, without depositing a revision.
-
-`-kSUBST'
- Useful with CVS. Set the default keyword substitution to SUBST.
- *Note Keyword substitution::. Giving an explicit `-k' option to
- `cvs update', `cvs export', or `cvs checkout' overrides this
- default.
-
-`-l[REV]'
- Lock the revision with number REV. If a branch is given, lock the
- latest revision on that branch. If REV is omitted, lock the
- latest revision on the default branch.
-
- This can be used in conjunction with the `rcslock.pl' script in
- the `contrib' directory of the CVS source distribution to provide
- reserved checkouts (where only one user can be editing a given
- file at a time). See the comments in that file for details (and
- see the `README' file in that directory for disclaimers about the
- unsupported nature of contrib). According to comments in that
- file, locking must set to strict (which is the default).
-
-`-L'
- Set locking to strict. Strict locking means that the owner of an
- RCS file is not exempt from locking for checkin. For use with
- CVS, strict locking must be set; see the discussion under the `-l'
- option above.
-
-`-mREV:MSG'
- Replace the log message of revision REV with MSG.
-
-`-NNAME[:[REV]]'
- Act like `-n', except override any previous assignment of NAME.
-
-`-nNAME[:[REV]]'
- Associate the symbolic name NAME with the branch or revision REV.
- It is normally better to use `cvs tag' or `cvs rtag' instead.
- Delete the symbolic name if both `:' and REV are omitted;
- otherwise, print an error message if NAME is already associated
- with another number. If REV is symbolic, it is expanded before
- association. A REV consisting of a branch number followed by a
- `.' stands for the current latest revision in the branch. A `:'
- with an empty REV stands for the current latest revision on the
- default branch, normally the trunk. For example, `rcs -nNAME:
- RCS/*' associates NAME with the current latest revision of all the
- named RCS files; this contrasts with `rcs -nNAME:$ RCS/*' which
- associates NAME with the revision numbers extracted from keyword
- strings in the corresponding working files.
-
-`-oRANGE'
- Potentially useful, but dangerous, with CVS (see below). Deletes
- ("outdates") the revisions given by RANGE. A range consisting of
- a single revision number means that revision. A range consisting
- of a branch number means the latest revision on that branch. A
- range of the form `REV1:REV2' means revisions REV1 to REV2 on the
- same branch, `:REV' means from the beginning of the branch
- containing REV up to and including REV, and `REV:' means from
- revision REV to the end of the branch containing REV. None of the
- outdated revisions may have branches or locks.
-
- Due to the way CVS handles branches REV cannot be specified
- symbolically if it is a branch. *Note Magic branch numbers::, for
- an explanation.
-
- Make sure that no-one has checked out a copy of the revision you
- outdate. Strange things will happen if he starts to edit it and
- tries to check it back in. For this reason, this option is not a
- good way to take back a bogus commit; commit a new revision
- undoing the bogus change instead (*note Merging two revisions::.).
-
-`-q'
- Run quietly; do not print diagnostics.
-
-`-sSTATE[:REV]'
- Useful with CVS. Set the state attribute of the revision REV to
- STATE. If REV is a branch number, assume the latest revision on
- that branch. If REV is omitted, assume the latest revision on the
- default branch. Any identifier is acceptable for STATE. A useful
- set of states is `Exp' (for experimental), `Stab' (for stable),
- and `Rel' (for released). By default, the state of a new revision
- is set to `Exp' when it is created. The state is visible in the
- output from CVS LOG (*note log::.), and in the `$Log: cvs.txt,v $
- output from CVS LOG (*note log::.), and in the `Revision 1.1 2003/11/07
20:55:33 sinuhe
- output from CVS LOG (*note log::.), and in the `Add manual.
- output from CVS LOG (*note log::.), and in the `' and
- `$State: Exp $' keywords (*note Keyword substitution::.). Note that CVS
- uses the `dead' state for its own purposes; to take a file to or
- from the `dead' state use commands like `cvs remove' and `cvs
- add', not `cvs admin -s'.
-
-`-t[FILE]'
- Useful with CVS. Write descriptive text from the contents of the
- named FILE into the RCS file, deleting the existing text. The
- FILE pathname may not begin with `-'. If FILE is omitted, obtain
- the text from standard input, terminated by end-of-file or by a
- line containing `.' by itself. Prompt for the text if interaction
- is possible; see `-I'. The descriptive text can be seen in the
- output from `cvs log' (*note log::.).
-
-`-t-STRING'
- Similar to `-tFILE'. Write descriptive text from the STRING into
- the RCS file, deleting the existing text.
-
-`-U'
- Set locking to non-strict. Non-strict locking means that the
- owner of a file need not lock a revision for checkin. For use
- with CVS, strict locking must be set; see the discussion under the
- `-l' option above.
-
-`-u[REV]'
- See the option `-l' above, for a discussion of using this option
- with CVS. Unlock the revision with number REV. If a branch is
- given, unlock the latest revision on that branch. If REV is
- omitted, remove the latest lock held by the caller. Normally,
- only the locker of a revision may unlock it. Somebody else
- unlocking a revision breaks the lock. This causes a mail message
- to be sent to the original locker. The message contains a
- commentary solicited from the breaker. The commentary is
- terminated by end-of-file or by a line containing `.' by itself.
-
-`-VN'
- Emulate RCS version N. Use -VN to make an RCS file acceptable to
- RCS version N by discarding information that would confuse version
- N.
-
-`-xSUFFIXES'
- Useless with CVS. Use SUFFIXES to characterize RCS files.
-
-admin examples
---------------
-
-Outdating is dangerous
-......................
-
- First, an example of how *not* to use the `admin' command. It is
-included to stress the fact that this command can be quite dangerous
-unless you know *exactly* what you are doing.
-
- The `-o' option can be used to "outdate" old revisions from the
-history file. If you are short on disc this option might help you.
-But think twice before using it--there is no way short of restoring the
-latest backup to undo this command!
-
- The next line is an example of a command that you would *not* like
-to execute.
-
- $ cvs admin -o:R_1_02 .
-
- The above command will delete all revisions up to, and including,
-the revision that corresponds to the tag R_1_02. But beware! If there
-are files that have not changed between R_1_02 and R_1_03 the file will
-have *the same* numerical revision number assigned to the tags R_1_02
-and R_1_03. So not only will it be impossible to retrieve R_1_02;
-R_1_03 will also have to be restored from the tapes!
-
-Comment leaders
-...............
-
- If you use the `$Log: cvs.txt,v $
- If you use the `Revision 1.2 2009/06/08 20:47:05 ward
- If you use the `changes that were lost from the CVS tree due to the
savannah crash of 2009/05/29
- If you use the `
- If you use the `Revision 1.1 2003/11/07 20:55:33 sinuhe
- If you use the `Add manual.
- If you use the `' keyword and you do not agree with the guess
-for comment leader that CVS has done, you can enforce your will with
-`cvs admin -c'. This might be suitable for `nroff' source:
-
- $ cvs admin -c'.\" ' *.man
- $ rm *.man
- $ cvs update
-
- The two last steps are to make sure that you get the versions with
-correct comment leaders in your working files.
-
-checkout--Check out sources for editing
-=======================================
-
- * Synopsis: checkout [options] modules...
-
- * Requires: repository.
-
- * Changes: working directory.
-
- * Synonyms: co, get
-
- Make a working directory containing copies of the source files
-specified by MODULES. You must execute `checkout' before using most of
-the other CVS commands, since most of them operate on your working
-directory.
-
- The MODULES part of the command are either symbolic names for some
-collection of source directories and files, or paths to directories or
-files in the repository. The symbolic names are defined in the
-`modules' file. *Note modules::.
-
- Depending on the modules you specify, `checkout' may recursively
-create directories and populate them with the appropriate source files.
-You can then edit these source files at any time (regardless of
-whether other software developers are editing their own copies of the
-sources); update them to include new changes applied by others to the
-source repository; or commit your work as a permanent change to the
-source repository.
-
- Note that `checkout' is used to create directories. The top-level
-directory created is always added to the directory where `checkout' is
-invoked, and usually has the same name as the specified module. In the
-case of a module alias, the created sub-directory may have a different
-name, but you can be sure that it will be a sub-directory, and that
-`checkout' will show the relative path leading to each file as it is
-extracted into your private work area (unless you specify the `-Q'
-global option).
-
- The files created by `checkout' are created read-write, unless the
-`-r' option to CVS (*note Global options::.) is specified, the
-`CVSREAD' environment variable is specified (*note Environment
-variables::.), or a watch is in effect for that file (*note Watches::.).
-
- Running `checkout' on a directory that was already built by a prior
-`checkout' is also permitted, and has the same effect as specifying the
-`-d' option to the `update' command, that is, any new directories that
-have been created in the repository will appear in your work area.
-*Note update::.
-
- For the output produced by the `checkout' command see *Note update
-output::.
-
-checkout options
-----------------
-
- These standard options are supported by `checkout' (*note Common
-options::., for a complete description of them):
-
-`-D DATE'
- Use the most recent revision no later than DATE. This option is
- sticky, and implies `-P'. See *Note Sticky tags::, for more
- information on sticky tags/dates.
-
-`-f'
- Only useful with the `-D DATE' or `-r TAG' flags. If no matching
- revision is found, retrieve the most recent revision (instead of
- ignoring the file).
-
-`-k KFLAG'
- Process RCS keywords according to KFLAG. See co(1). This option
- is sticky; future updates of this file in this working directory
- will use the same KFLAG. The `status' command can be viewed to
- see the sticky options. *Note status::.
-
-`-l'
- Local; run only in current working directory.
-
-`-n'
- Do not run any checkout program (as specified with the `-o' option
- in the modules file; *note modules::.).
-
-`-P'
- Prune empty directories.
-
-`-p'
- Pipe files to the standard output.
-
-`-r TAG'
- Use revision TAG. This option is sticky, and implies `-P'. See
- *Note Sticky tags::, for more information on sticky tags/dates.
-
- In addition to those, you can use these special command options with
-`checkout':
-
-`-A'
- Reset any sticky tags, dates, or `-k' options. See *Note Sticky
- tags::, for more information on sticky tags/dates.
-
-`-c'
- Copy the module file, sorted, to the standard output, instead of
- creating or modifying any files or directories in your working
- directory.
-
-`-d DIR'
- Create a directory called DIR for the working files, instead of
- using the module name. Unless you also use `-N', the paths
- created under DIR will be as short as possible.
-
-`-j TAG'
- With two `-j' options, merge changes from the revision specified
- with the first `-j' option to the revision specified with the
- second `j' option, into the working directory.
-
- With one `-j' option, merge changes from the ancestor revision to
- the revision specified with the `-j' option, into the working
- directory. The ancestor revision is the common ancestor of the
- revision which the working directory is based on, and the revision
- specified in the `-j' option.
-
- In addition, each -j option can contain an optional date
- specification which, when used with branches, can limit the chosen
- revision to one within a specific date. An optional date is
- specified by adding a colon (:) to the tag:
- `-jSYMBOLIC_TAG:DATE_SPECIFIER'.
-
- *Note Merging::.
-
-`-N'
- Only useful together with `-d DIR'. With this option, CVS will
- not shorten module paths in your working directory. (Normally,
- CVS shortens paths as much as possible when you specify an
- explicit target directory).
-
-`-s'
- Like `-c', but include the status of all modules, and sort it by
- the status string. *Note modules::, for info about the `-s'
- option that is used inside the modules file to set the module
- status.
-
-checkout examples
------------------
-
- Get a copy of the module `tc':
-
- $ cvs checkout tc
-
- Get a copy of the module `tc' as it looked one day ago:
-
- $ cvs checkout -D yesterday tc
-
-commit--Check files into the repository
-=======================================
-
- * Version 1.3 Synopsis: commit [-lnR] [-m 'log_message' | -f file]
- [-r revision] [files...]
-
- * Version 1.3.1 Synopsis: commit [-lnRf] [-m 'log_message' | -F
- file] [-r revision] [files...]
-
- * Requires: working directory, repository.
-
- * Changes: repository.
-
- * Synonym: ci
-
- *Warning:* The `-f FILE' option will probably be renamed to `-F
-FILE', and `-f' will be given a new behavior in future releases of CVS.
-
- Use `commit' when you want to incorporate changes from your working
-source files into the source repository.
-
- If you don't specify particular files to commit, all of the files in
-your working current directory are examined. `commit' is careful to
-change in the repository only those files that you have really changed.
-By default (or if you explicitly specify the `-R' option), files in
-subdirectories are also examined and committed if they have changed;
-you can use the `-l' option to limit `commit' to the current directory
-only.
-
- `commit' verifies that the selected files are up to date with the
-current revisions in the source repository; it will notify you, and
-exit without committing, if any of the specified files must be made
-current first with `update' (*note update::.). `commit' does not call
-the `update' command for you, but rather leaves that for you to do when
-the time is right.
-
- When all is well, an editor is invoked to allow you to enter a log
-message that will be written to one or more logging programs (*note
-modules::., and *note loginfo::.) and placed in the RCS history file
-inside the repository. This log message can be retrieved with the
-`log' command; *Note log::. You can specify the log message on the
-command line with the `-m MESSAGE' option, and thus avoid the editor
-invocation, or use the `-f FILE' option to specify that the argument
-file contains the log message.
-
-commit options
---------------
-
- These standard options are supported by `commit' (*note Common
-options::., for a complete description of them):
-
-`-l'
- Local; run only in current working directory.
-
-`-n'
- Do not run any module program.
-
-`-R'
- Commit directories recursively. This is on by default.
-
-`-r REVISION'
- Commit to REVISION. REVISION must be either a branch, or a
- revision on the main trunk that is higher than any existing
- revision number. You cannot commit to a specific revision on a
- branch.
-
- `commit' also supports these options:
-
-`-F FILE'
- This option is present in CVS releases 1.3-s3 and later. Read the
- log message from FILE, instead of invoking an editor.
-
-`-f'
- This option is present in CVS 1.3-s3 and later releases of CVS.
- Note that this is not the standard behavior of the `-f' option as
- defined in *Note Common options::.
-
- Force CVS to commit a new revision even if you haven't made any
- changes to the file. If the current revision of FILE is 1.7, then
- the following two commands are equivalent:
-
- $ cvs commit -f FILE
- $ cvs commit -r 1.8 FILE
-
-`-f FILE'
- This option is present in CVS releases 1.3, 1.3-s1 and 1.3-s2.
- Note that this is not the standard behavior of the `-f' option as
- defined in *Note Common options::.
-
- Read the log message from FILE, instead of invoking an editor.
-
-`-m MESSAGE'
- Use MESSAGE as the log message, instead of invoking an editor.
-
-commit examples
----------------
-
-New major release number
-........................
-
- When you make a major release of your product, you might want the
-revision numbers to track your major release number. You should
-normally not care about the revision numbers, but this is a thing that
-many people want to do, and it can be done without doing any harm.
-
- To bring all your files up to the RCS revision 3.0 (including those
-that haven't changed), you might do:
-
- $ cvs commit -r 3.0
-
- Note that it is generally a bad idea to try to make the RCS revision
-number equal to the current release number of your product. You should
-think of the revision number as an internal number that the CVS package
-maintains, and that you generally never need to care much about. Using
-the `tag' and `rtag' commands you can give symbolic names to the
-releases instead. *Note tag:: and *Note rtag::.
-
- Note that the number you specify with `-r' must be larger than any
-existing revision number. That is, if revision 3.0 exists, you cannot
-`cvs commit -r 1.3'.
-
-Committing to a branch
-......................
-
- You can commit to a branch revision (one that has an even number of
-dots) with the `-r' option. To create a branch revision, use the `-b'
-option of the `rtag' or `tag' commands (*note tag::. or *note
-rtag::.). Then, either `checkout' or `update' can be used to base your
-sources on the newly created branch. From that point on, all `commit'
-changes made within these working sources will be automatically added
-to a branch revision, thereby not disturbing main-line development in
-any way. For example, if you had to create a patch to the 1.2 version
-of the product, even though the 2.0 version is already under
-development, you might do:
-
- $ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
- $ cvs checkout -r FCS1_2_Patch product_module
- $ cd product_module
- [[ hack away ]]
- $ cvs commit
-
-This works automatically since the `-r' option is sticky.
-
-Creating the branch after editing
-.................................
-
- Say you have been working on some extremely experimental software,
-based on whatever revision you happened to checkout last week. If
-others in your group would like to work on this software with you, but
-without disturbing main-line development, you could commit your change
-to a new branch. Others can then checkout your experimental stuff and
-utilize the full benefit of CVS conflict resolution. The scenario might
-look like:
-
- [[ hacked sources are present ]]
- $ cvs tag -b EXPR1
- $ cvs update -r EXPR1
- $ cvs commit
-
- The `update' command will make the `-r EXPR1' option sticky on all
-files. Note that your changes to the files will never be removed by the
-`update' command. The `commit' will automatically commit to the
-correct branch, because the `-r' is sticky. You could also do like
-this:
-
- [[ hacked sources are present ]]
- $ cvs tag -b EXPR1
- $ cvs commit -r EXPR1
-
-but then, only those files that were changed by you will have the `-r
-EXPR1' sticky flag. If you hack away, and commit without specifying
-the `-r EXPR1' flag, some files may accidentally end up on the main
-trunk.
-
- To work with you on the experimental change, others would simply do
-
- $ cvs checkout -r EXPR1 whatever_module
-
-diff--Run diffs between revisions
-=================================
-
- * Synopsis: diff [-l] [rcsdiff_options] [[-r rev1 | -D date1] [-r
- rev2 | -D date2]] [files...]
-
- * Requires: working directory, repository.
-
- * Changes: nothing.
-
- The `diff' command is used to compare different revisions of files.
-The default action is to compare your working files with the revisions
-they were based on, and report any differences that are found.
-
- If any file names are given, only those files are compared. If any
-directories are given, all files under them will be compared.
-
- The exit status will be 0 if no differences were found, 1 if some
-differences were found, and 2 if any error occurred.
-
-diff options
-------------
-
- These standard options are supported by `diff' (*note Common
-options::., for a complete description of them):
-
-`-D DATE'
- Use the most recent revision no later than DATE. See `-r' for how
- this affects the comparison.
-
- CVS can be configured to pass the `-D' option through to `rcsdiff'
- (which in turn passes it on to `diff'. GNU diff uses `-D' as a
- way to put `cpp'-style `#define' statements around the output
- differences. There is no way short of testing to figure out how
- CVS was configured. In the default configuration CVS will use the
- `-D DATE' option.
-
-`-k KFLAG'
- Process RCS keywords according to KFLAG. See co(1).
-
-`-l'
- Local; run only in current working directory.
-
-`-R'
- Examine directories recursively. This option is on by default.
-
-`-r TAG'
- Compare with revision TAG. Zero, one or two `-r' options can be
- present. With no `-r' option, the working file will be compared
- with the revision it was based on. With one `-r', that revision
- will be compared to your current working file. With two `-r'
- options those two revisions will be compared (and your working
- file will not affect the outcome in any way).
-
- One or both `-r' options can be replaced by a `-D DATE' option,
- described above.
-
- Any other options that are found are passed through to `rcsdiff',
-which in turn passes them to `diff'. The exact meaning of the options
-depends on which `diff' you are using. The long options introduced in
-GNU diff 2.0 are not yet supported in CVS. See the documentation for
-your `diff' to see which options are supported.
-
-diff examples
--------------
-
- The following line produces a Unidiff (`-u' flag) between revision
-1.14 and 1.19 of `backend.c'. Due to the `-kk' flag no keywords are
-substituted, so differences that only depend on keyword substitution
-are ignored.
-
- $ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
-
- Suppose the experimental branch EXPR1 was based on a set of files
-tagged RELEASE_1_0. To see what has happened on that branch, the
-following can be used:
-
- $ cvs diff -r RELEASE_1_0 -r EXPR1
-
- A command like this can be used to produce a context diff between
-two releases:
-
- $ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
-
- If you are maintaining ChangeLogs, a command like the following just
-before you commit your changes may help you write the ChangeLog entry.
-All local modifications that have not yet been committed will be
-printed.
-
- $ cvs diff -u | less
-
-export--Export sources from CVS, similar to checkout
-====================================================
-
- * Synopsis: export [-flNn] [-r rev|-D date] [-k subst] [-d dir]
- module...
-
- * Requires: repository.
-
- * Changes: current directory.
-
- This command is a variant of `checkout'; use it when you want a copy
-of the source for module without the CVS administrative directories.
-For example, you might use `export' to prepare source for shipment
-off-site. This command requires that you specify a date or tag (with
-`-D' or `-r'), so that you can count on reproducing the source you ship
-to others.
-
- One often would like to use `-kv' with `cvs export'. This causes
-any RCS keywords to be expanded such that an import done at some other
-site will not lose the keyword revision information. But be aware that
-doesn't handle an export containing binary files correctly. Also be
-aware that after having used `-kv', one can no longer use the `ident'
-command (which is part of the RCS suite--see ident(1)) which looks for
-RCS keyword strings. If you want to be able to use `ident' you must not
-use `-kv'.
-
-export options
---------------
-
- These standard options are supported by `export' (*note Common
-options::., for a complete description of them):
-
-`-D DATE'
- Use the most recent revision no later than DATE.
-
-`-f'
- If no matching revision is found, retrieve the most recent
- revision (instead of ignoring the file).
-
-`-l'
- Local; run only in current working directory.
-
-`-n'
- Do not run any checkout program.
-
-`-R'
- Export directories recursively. This is on by default.
-
-`-r TAG'
- Use revision TAG.
-
- In addition, these options (that are common to `checkout' and
-`export') are also supported:
-
-`-d DIR'
- Create a directory called DIR for the working files, instead of
- using the module name. Unless you also use `-N', the paths
- created under DIR will be as short as possible.
-
-`-k SUBST'
- Set keyword expansion mode (*note Substitution modes::.).
-
-`-N'
- Only useful together with `-d DIR'. With this option, CVS will
- not shorten module paths in your working directory. (Normally,
- CVS shortens paths as much as possible when you specify an
- explicit target directory.)
-
-history--Show status of files and users
-=======================================
-
- * Synopsis: history [-report] [-flags] [-options args] [files...]
-
- * Requires: the file `$CVSROOT/CVSROOT/history'
-
- * Changes: nothing.
-
- CVS can keep a history file that tracks each use of the `checkout',
-`commit', `rtag', `update', and `release' commands. You can use
-`history' to display this information in various formats.
-
- Logging must be enabled by creating the file
-`$CVSROOT/CVSROOT/history'.
-
- *Warning:* `history' uses `-f', `-l', `-n', and `-p' in ways that
-conflict with the normal use inside CVS (*note Common options::.).
-
-history options
----------------
-
- Several options (shown above as `-report') control what kind of
-report is generated:
-
-`-c'
- Report on each time commit was used (i.e., each time the
- repository was modified).
-
-`-e'
- Everything (all record types); equivalent to specifying
- `-xMACFROGWUT'.
-
-`-m MODULE'
- Report on a particular module. (You can meaningfully use `-m'
- more than once on the command line.)
-
-`-o'
- Report on checked-out modules.
-
-`-T'
- Report on all tags.
-
-`-x TYPE'
- Extract a particular set of record types TYPE from the CVS
- history. The types are indicated by single letters, which you may
- specify in combination.
-
- Certain commands have a single record type:
-
- `F'
- release
-
- `O'
- checkout
-
- `T'
- rtag
-
- One of four record types may result from an update:
-
- `C'
- A merge was necessary but collisions were detected (requiring
- manual merging).
-
- `G'
- A merge was necessary and it succeeded.
-
- `U'
- A working file was copied from the repository.
-
- `W'
- The working copy of a file was deleted during update (because
- it was gone from the repository).
-
- One of three record types results from commit:
-
- `A'
- A file was added for the first time.
-
- `M'
- A file was modified.
-
- `R'
- A file was removed.
-
- The options shown as `-flags' constrain or expand the report without
-requiring option arguments:
-
-`-a'
- Show data for all users (the default is to show data only for the
- user executing `history').
-
-`-l'
- Show last modification only.
-
-`-w'
- Show only the records for modifications done from the same working
- directory where `history' is executing.
-
- The options shown as `-options ARGS' constrain the report based on
-an argument:
-
-`-b STR'
- Show data back to a record containing the string STR in either
- the module name, the file name, or the repository path.
-
-`-D DATE'
- Show data since DATE. This is slightly different from the normal
- use of `-D DATE', which selects the newest revision older than
- DATE.
-
-`-p REPOSITORY'
- Show data for a particular source repository (you can specify
- several `-p' options on the same command line).
-
-`-r REV'
- Show records referring to revisions since the revision or tag
- named REV appears in individual RCS files. Each RCS file is
- searched for the revision or tag.
-
-`-t TAG'
- Show records since tag TAG was last added to the the history file.
- This differs from the `-r' flag above in that it reads only the
- history file, not the RCS files, and is much faster.
-
-`-u NAME'
- Show records for user NAME.
-
-import--Import sources into CVS, using vendor branches
-======================================================
-
- * Synopsis: import [-options] repository vendortag releasetag...
-
- * Requires: Repository, source distribution directory.
-
- * Changes: repository.
-
- Use `import' to incorporate an entire source distribution from an
-outside source (e.g., a source vendor) into your source repository
-directory. You can use this command both for initial creation of a
-repository, and for wholesale updates to the module from the outside
-source. *Note Tracking sources::, for a discussion on this subject.
-
- The REPOSITORY argument gives a directory name (or a path to a
-directory) under the CVS root directory for repositories; if the
-directory did not exist, import creates it.
-
- When you use import for updates to source that has been modified in
-your source repository (since a prior import), it will notify you of
-any files that conflict in the two branches of development; use
-`checkout -j' to reconcile the differences, as import instructs you to
-do.
-
- If CVS decides a file should be ignored (*note cvsignore::.), it
-does not import it and prints `I ' followed by the filename (*note
-import output::., for a complete description of the output).
-
- If the file `$CVSROOT/CVSROOT/cvswrappers' exists, any file whose
-names match the specifications in that file will be treated as packages
-and the appropriate filtering will be performed on the file/directory
-before being imported, *Note Wrappers::.
-
- The outside source is saved in a first-level RCS branch, by default
-1.1.1. Updates are leaves of this branch; for example, files from the
-first imported collection of source will be revision 1.1.1.1, then
-files from the first imported update will be revision 1.1.1.2, and so
-on.
-
- At least three arguments are required. REPOSITORY is needed to
-identify the collection of source. VENDORTAG is a tag for the entire
-branch (e.g., for 1.1.1). You must also specify at least one
-RELEASETAG to identify the files at the leaves created each time you
-execute `import'.
-
-import options
---------------
-
- This standard option is supported by `import' (*note Common
-options::., for a complete description):
-
-`-m MESSAGE'
- Use MESSAGE as log information, instead of invoking an editor.
-
- There are three additional special options.
-
-`-b BRANCH'
- Specify a first-level branch other than 1.1.1. Unless the `-b
- BRANCH' flag is given, revisions will *always* be made to the
- branch 1.1.1--even if a VENDORTAG that matches another branch is
- given! What happens in that case, is that the tag will be reset
- to 1.1.1. Warning: This behavior might change in the future.
-
-`-k SUBST'
- Indicate the RCS keyword expansion mode desired. This setting
- will apply to all files created during the import, but not to any
- files that previously existed in the repository. See *Note
- Substitution modes:: for a list of valid `-k' settings.
-
-`-I NAME'
- Specify file names that should be ignored during import. You can
- use this option repeatedly. To avoid ignoring any files at all
- (even those ignored by default), specify `-I !'.
-
- NAME can be a file name pattern of the same type that you can
- specify in the `.cvsignore' file. *Note cvsignore::.
-
-`-W SPEC'
- Specify file names that should be filtered during import. You can
- use this option repeatedly.
-
- SPEC can be a file name pattern of the same type that you can
- specify in the `.cvswrappers' file. *Note Wrappers::.
-
-import output
--------------
-
- `import' keeps you informed of its progress by printing a line for
-each file, preceded by one character indicating the status of the file:
-
-`U FILE'
- The file already exists in the repository and has not been locally
- modified; a new revision has been created (if necessary).
-
-`N FILE'
- The file is a new file which has been added to the repository.
-
-`C FILE'
- The file already exists in the repository but has been locally
- modified; you will have to merge the changes.
-
-`I FILE'
- The file is being ignored (*note cvsignore::.).
-
-`L FILE'
- The file is a symbolic link; at the moment (and for the forseeable
- future), symbolic links are ignored. (Various options in the
- `modules' file can be used to recreate symbolic links on checkout,
- update, etc.; *note modules::..)
-
-import examples
----------------
-
- *Note Tracking sources::, and *Note From files::.
-
-log--Print out log information for files
-========================================
-
- * Synopsis: log [options] [files...]
-
- * Requires: repository, working directory.
-
- * Changes: nothing.
-
- Display log information for files. `log' used to call the RCS
-utility `rlog'. Although this is no longer true in the current
-sources, this history determines the format of the output and the
-options, which are not quite in the style of the other CVS commands.
-
- The output includes the location of the RCS file, the "head"
-revision (the latest revision on the trunk), all symbolic names (tags)
-and some other things. For each revision, the revision number, the
-author, the number of lines added/deleted and the log message are
-printed. All times are displayed in Coordinated Universal Time (UTC).
-(Other parts of CVS print times in the local timezone).
-
-log options
------------
-
- By default, `log' prints all information that is available. All
-other options restrict the output.
-
-`-b'
- Print information about the revisions on the default branch,
- normally the highest branch on the trunk.
-
-`-d DATES'
- Print information about revisions with a checkin date/time in the
- range given by the semicolon-separated list of dates. The date
- formats accepted are those accepted by the `-D' option to many
- other CVS commands (*note Common options::.). Dates can be
- combined into ranges as follows:
-
- `D1<D2'
- `D2>D1'
- Select the revisions that were deposited between D1 and D2.
-
- `<D'
- `D>'
- Select all revisions dated D or earlier.
-
- `D<'
- `>D'
- Select all revisions dated D or later.
-
- `D'
- Select the single, latest revision dated D or earlier.
-
- The `>' or `<' characters may be followed by `=' to indicate an
- inclusive range rather than an exclusive one.
-
- Note that the separator is a semicolon (;).
-
-`-h'
- Print only the RCS pathname, working pathname, head, default
- branch, access list, locks, symbolic names, and suffix.
-
-`-l'
- Local; run only in current working directory. (Default is to run
- recursively).
-
-`-N'
- Do not print the list of tags for this file. This option can be
- very useful when your site uses a lot of tags, so rather than
- "more"'ing over 3 pages of tag information, the log information is
- presented without tags at all.
-
-`-R'
- Print only the name of the RCS history file.
-
-`-rREVISIONS'
- Print information about revisions given in the comma-separated
- list REVISIONS of revisions and ranges. The following table
- explains the available range formats:
-
- `REV1:REV2'
- Revisions REV1 to REV2 (which must be on the same branch).
-
- `:REV'
- Revisions from the beginning of the branch up to and
- including REV.
-
- `REV:'
- Revisions starting with REV to the end of the branch
- containing REV.
-
- `BRANCH'
- An argument that is a branch means all revisions on that
- branch.
-
- `BRANCH1:BRANCH2'
- A range of branches means all revisions on the branches in
- that range.
-
- `BRANCH.'
- The latest revision in BRANCH.
-
- A bare `-r' with no revisions means the latest revision on the
- default branch, normally the trunk. There can be no space between
- the `-r' option and its argument.
-
-`-s STATES'
- Print information about revisions whose state attributes match one
- of the states given in the comma-separated list STATES.
-
-`-t'
- Print the same as `-h', plus the descriptive text.
-
-`-wLOGINS'
- Print information about revisions checked in by users with login
- names appearing in the comma-separated list LOGINS. If LOGINS is
- omitted, the user's login is assumed. There can be no space
- between the `-w' option and its argument.
-
- `log' prints the intersection of the revisions selected with the
-options `-d', `-s', and `-w', intersected with the union of the
-revisions selected by `-b' and `-r'.
-
-log examples
-------------
-
- Contributed examples are gratefully accepted.
-
-rdiff--'patch' format diffs between releases
-============================================
-
- * rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules...
-
- * Requires: repository.
-
- * Changes: nothing.
-
- * Synonym: patch
-
- Builds a Larry Wall format patch(1) file between two releases, that
-can be fed directly into the patch program to bring an old release
-up-to-date with the new release. (This is one of the few CVS commands
-that operates directly from the repository, and doesn't require a prior
-checkout.) The diff output is sent to the standard output device.
-
- You can specify (using the standard `-r' and `-D' options) any
-combination of one or two revisions or dates. If only one revision or
-date is specified, the patch file reflects differences between that
-revision or date and the current head revisions in the RCS file.
-
- Note that if the software release affected is contained in more than
-one directory, then it may be necessary to specify the `-p' option to
-the patch command when patching the old sources, so that patch is able
-to find the files that are located in other directories.
-
-rdiff options
--------------
-
- These standard options are supported by `rdiff' (*note Common
-options::., for a complete description of them):
-
-`-D DATE'
- Use the most recent revision no later than DATE.
-
-`-f'
- If no matching revision is found, retrieve the most recent
- revision (instead of ignoring the file).
-
-`-l'
- Local; don't descend subdirectories.
-
-`-r TAG'
- Use revision TAG.
-
- In addition to the above, these options are available:
-
-`-c'
- Use the context diff format. This is the default format.
-
-`-s'
- Create a summary change report instead of a patch. The summary
- includes information about files that were changed or added
- between the releases. It is sent to the standard output device.
- This is useful for finding out, for example, which files have
- changed between two dates or revisions.
-
-`-t'
- A diff of the top two revisions is sent to the standard output
- device. This is most useful for seeing what the last change to a
- file was.
-
-`-u'
- Use the unidiff format for the context diffs. This option is not
- available if your diff does not support the unidiff format.
- Remember that old versions of the `patch' program can't handle the
- unidiff format, so if you plan to post this patch to the net you
- should probably not use `-u'.
-
-`-V VN'
- Expand RCS keywords according to the rules current in RCS version
- VN (the expansion format changed with RCS version 5).
-
-rdiff examples
---------------
-
- Suppose you receive mail from address@hidden asking for an update from
-release 1.2 to 1.4 of the tc compiler. You have no such patches on
-hand, but with CVS that can easily be fixed with a command such as this:
-
- $ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
- $$ Mail -s 'The patches you asked for' address@hidden
-
- Suppose you have made release 1.3, and forked a branch called
-`R_1_3fix' for bugfixes. `R_1_3_1' corresponds to release 1.3.1, which
-was made some time ago. Now, you want to see how much development has
-been done on the branch. This command can be used:
-
- $ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name
- cvs rdiff: Diffing module-name
- File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6
- File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4
- File bar.h,v changed from revision 1.29.2.1 to 1.2
-
-release--Indicate that a Module is no longer in use
-===================================================
-
- * release [-d] directories...
-
- * Requires: Working directory.
-
- * Changes: Working directory, history log.
-
- This command is meant to safely cancel the effect of `cvs checkout'.
-Since CVS doesn't lock files, it isn't strictly necessary to use this
-command. You can always simply delete your working directory, if you
-like; but you risk losing changes you may have forgotten, and you leave
-no trace in the CVS history file (*note history file::.) that you've
-abandoned your checkout.
-
- Use `cvs release' to avoid these problems. This command checks that
-no uncommitted changes are present; that you are executing it from
-immediately above a CVS working directory; and that the repository
-recorded for your files is the same as the repository defined in the
-module database.
-
- If all these conditions are true, `cvs release' leaves a record of
-its execution (attesting to your intentionally abandoning your
-checkout) in the CVS history log.
-
-release options
----------------
-
- The `release' command supports one command option:
-
-`-d'
- Delete your working copy of the file if the release succeeds. If
- this flag is not given your files will remain in your working
- directory.
-
- *Warning:* The `release' command deletes all directories and
- files recursively. This has the very serious side-effect that any
- directory that you have created inside your checked-out sources,
- and not added to the repository (using the `add' command; *note
- Adding files::.) will be silently deleted--even if it is non-empty!
-
-release output
---------------
-
- Before `release' releases your sources it will print a one-line
-message for any file that is not up-to-date.
-
- *Warning:* Any new directories that you have created, but not added
-to the CVS directory hierarchy with the `add' command (*note Adding
-files::.) will be silently ignored (and deleted, if `-d' is specified),
-even if they contain files.
-
-`U FILE'
- There exists a newer revision of this file in the repository, and
- you have not modified your local copy of the file.
-
-`A FILE'
- The file has been added to your private copy of the sources, but
- has not yet been committed to the repository. If you delete your
- copy of the sources this file will be lost.
-
-`R FILE'
- The file has been removed from your private copy of the sources,
- but has not yet been removed from the repository, since you have
- not yet committed the removal. *Note commit::.
-
-`M FILE'
- The file is modified in your working directory. There might also
- be a newer revision inside the repository.
-
-`? FILE'
- FILE is in your working directory, but does not correspond to
- anything in the source repository, and is not in the list of files
- for CVS to ignore (see the description of the `-I' option, and
- *note cvsignore::.). If you remove your working sources, this
- file will be lost.
-
- Note that no warning message like this is printed for spurious
- directories that CVS encounters. The directory, and all its
- contents, are silently ignored.
-
-release examples
-----------------
-
- Release the module, and delete your local working copy of the files.
-
- $ cd .. # You must stand immediately above the
- # sources when you issue `cvs release'.
- $ cvs release -d tc
- You have [0] altered files in this repository.
- Are you sure you want to release (and delete) module `tc': y
- $
-
-rtag--Add a symbolic tag to a module
-====================================
-
- * rtag [-falnR] [-b] [-d] [-r tag | -Ddate] symbolic_tag modules...
-
- * Requires: repository.
-
- * Changes: repository.
-
- * Synonym: rfreeze
-
- You can use this command to assign symbolic tags to particular,
-explicitly specified source revisions in the repository. `rtag' works
-directly on the repository contents (and requires no prior checkout).
-Use `tag' instead (*note tag::.), to base the selection of revisions on
-the contents of your working directory.
-
- If you attempt to use a tag name that already exists, CVS will
-complain and not overwrite that tag. Use the `-F' option to force the
-new tag value.
-
-rtag options
-------------
-
- These standard options are supported by `rtag' (*note Common
-options::., for a complete description of them):
-
-`-D DATE'
- Tag the most recent revision no later than DATE.
-
-`-f'
- Only useful with the `-D DATE' or `-r TAG' flags. If no matching
- revision is found, use the most recent revision (instead of
- ignoring the file).
-
-`-F'
- Overwrite an existing tag of the same name on a different
- revision. This option is new in CVS 1.4. The old behavior is
- matched by `cvs tag -F'.
-
-`-l'
- Local; run only in current working directory.
-
-`-n'
- Do not run any tag program that was specified with the `-t' flag
- inside the `modules' file. (*note modules::.).
-
-`-R'
- Commit directories recursively. This is on by default.
-
-`-r TAG'
- Only tag those files that contain TAG. This can be used to rename
- a tag: tag only the files identified by the old tag, then delete
- the old tag, leaving the new tag on exactly the same files as the
- old tag.
-
- In addition to the above common options, these options are available:
-
-`-a'
- Use the `-a' option to have `rtag' look in the `Attic' (*note
- Removing files::.) for removed files that contain the specified
- tag. The tag is removed from these files, which makes it
- convenient to re-use a symbolic tag as development continues (and
- files get removed from the up-coming distribution).
-
-`-b'
- Make the tag a branch tag. *Note Branches::.
-
-`-d'
- Delete the tag instead of creating it.
-
- In general, tags (often the symbolic names of software
- distributions) should not be removed, but the `-d' option is
- available as a means to remove completely obsolete symbolic names
- if necessary (as might be the case for an Alpha release, or if you
- mistagged a module).
-
-status--Display status information on checked out files
-=======================================================
-
- * status [-lR] [-v] [files...]
-
- * Requires: working directory, repository.
-
- * Changes: nothing.
-
- Display a brief report on the current status of files with respect
-to the source repository. For information on the basic output see
-*Note File status::. For information on the `Sticky tag' and `Sticky
-date' output, see *Note Sticky tags::. For information on the `Sticky
-options' output, see the `-k' option in *Note update options::.
-
- You can also use this command to determine the potential impact of a
-`cvs update' on your working source directory--but remember that things
-might change in the repository before you run `update'.
-
-status options
---------------
-
- These standard options are supported by `status' (*note Common
-options::., for a complete description of them):
-
-`-l'
- Local; run only in current working directory.
-
-`-R'
- Commit directories recursively. This is on by default.
-
- There is one additional option:
-
-`-v'
- Verbose. In addition to the information normally displayed, print
- all symbolic tags, together with the numerical value of the
- revision or branch they refer to. For more information, see *Note
- Tags::
-
-tag--Add a symbolic tag to checked out versions of files
-========================================================
-
- * tag [-lR] [-b] [-c] [-d] symbolic_tag [files...]
-
- * Requires: working directory, repository.
-
- * Changes: repository.
-
- * Synonym: freeze
-
- Use this command to assign symbolic tags to the nearest repository
-versions to your working sources. The tags are applied immediately to
-the repository, as with `rtag', but the versions are supplied
-implicitly by the CVS records of your working files' history rather than
-applied explicitly.
-
- One use for tags is to record a snapshot of the current sources when
-the software freeze date of a project arrives. As bugs are fixed after
-the freeze date, only those changed sources that are to be part of the
-release need be re-tagged.
-
- The symbolic tags are meant to permanently record which revisions of
-which files were used in creating a software distribution. The
-`checkout' and `update' commands allow you to extract an exact copy of
-a tagged release at any time in the future, regardless of whether files
-have been changed, added, or removed since the release was tagged.
-
- This command can also be used to delete a symbolic tag, or to create
-a branch. See the options section below.
-
- If you attempt to use a tag name that already exists, CVS will
-complain and not overwrite that tag. Use the `-F' option to force the
-new tag value.
-
-tag options
------------
-
- These standard options are supported by `tag' (*note Common
-options::., for a complete description of them):
-
-`-F'
- Overwrite an existing tag of the same name on a different
- revision. This option is new in CVS 1.4. The old behavior is
- matched by `cvs tag -F'.
-
-`-l'
- Local; run only in current working directory.
-
-`-R'
- Commit directories recursively. This is on by default.
-
- Two special options are available:
-
-`-b'
- The -b option makes the tag a branch tag (*note Branches::.),
- allowing concurrent, isolated development. This is most useful
- for creating a patch to a previously released software
- distribution.
-
-`-c'
- The -c option checks that all files which are to be tagged are
- unmodified. This can be used to make sure that you can
- reconstruct the current file contents.
-
-`-d'
- Delete a tag.
-
- If you use `cvs tag -d symbolic_tag', the symbolic tag you specify
- is deleted instead of being added. Warning: Be very certain of
- your ground before you delete a tag; doing this permanently
- discards some historical information, which may later turn out to
- be valuable.
-
-update--Bring work tree in sync with repository
-===============================================
-
- * update [-AdflPpR] [-d] [-r tag|-D date] files...
-
- * Requires: repository, working directory.
-
- * Changes: working directory.
-
- After you've run checkout to create your private copy of source from
-the common repository, other developers will continue changing the
-central source. From time to time, when it is convenient in your
-development process, you can use the `update' command from within your
-working directory to reconcile your work with any revisions applied to
-the source repository since your last checkout or update.
-
-update options
---------------
-
- These standard options are available with `update' (*note Common
-options::., for a complete description of them):
-
-`-D date'
- Use the most recent revision no later than DATE. This option is
- sticky, and implies `-P'. See *Note Sticky tags::, for more
- information on sticky tags/dates.
-
-`-f'
- Only useful with the `-D DATE' or `-r TAG' flags. If no matching
- revision is found, retrieve the most recent revision (instead of
- ignoring the file).
-
-`-k KFLAG'
- Process RCS keywords according to KFLAG. See co(1). This option
- is sticky; future updates of this file in this working directory
- will use the same KFLAG. The `status' command can be viewed to
- see the sticky options. *Note status::.
-
-`-l'
- Local; run only in current working directory. *Note Recursive
- behavior::.
-
-`-P'
- Prune empty directories.
-
-`-p'
- Pipe files to the standard output.
-
-`-R'
- Operate recursively. This is on by default. *Note Recursive
- behavior::.
-
-`-r tag'
- Retrieve revision TAG. This option is sticky, and implies `-P'.
- See *Note Sticky tags::, for more information on sticky tags/dates.
-
- These special options are also available with `update'.
-
-`-A'
- Reset any sticky tags, dates, or `-k' options. See *Note Sticky
- tags::, for more information on sticky tags/dates.
-
-`-d'
- Create any directories that exist in the repository if they're
- missing from the working directory. Normally, `update' acts only
- on directories and files that were already enrolled in your
- working directory.
-
- This is useful for updating directories that were created in the
- repository since the initial checkout; but it has an unfortunate
- side effect. If you deliberately avoided certain directories in
- the repository when you created your working directory (either
- through use of a module name or by listing explicitly the files
- and directories you wanted on the command line), then updating
- with `-d' will create those directories, which may not be what you
- want.
-
-`-I NAME'
- Ignore files whose names match NAME (in your working directory)
- during the update. You can specify `-I' more than once on the
- command line to specify several files to ignore. Use `-I !' to
- avoid ignoring any files at all. *Note cvsignore::, for other
- ways to make CVS ignore some files.
-
-`-WSPEC'
- Specify file names that should be filtered during update. You can
- use this option repeatedly.
-
- SPEC can be a file name pattern of the same type that you can
- specify in the `.cvswrappers' file. *Note Wrappers::.
-
-`-jREVISION'
- With two `-j' options, merge changes from the revision specified
- with the first `-j' option to the revision specified with the
- second `j' option, into the working directory.
-
- With one `-j' option, merge changes from the ancestor revision to
- the revision specified with the `-j' option, into the working
- directory. The ancestor revision is the common ancestor of the
- revision which the working directory is based on, and the revision
- specified in the `-j' option.
-
- In addition, each -j option can contain an optional date
- specification which, when used with branches, can limit the chosen
- revision to one within a specific date. An optional date is
- specified by adding a colon (:) to the tag:
- `-jSYMBOLIC_TAG:DATE_SPECIFIER'.
-
- *Note Merging::.
-
-update output
--------------
-
- `update' and `checkout' keep you informed of its progress by
-printing a line for each file, preceded by one character indicating the
-status of the file:
-
-`U FILE'
- The file was brought up to date with respect to the repository.
- This is done for any file that exists in the repository but not in
- your source, and for files that you haven't changed but are not
- the most recent versions available in the repository.
-
-`A FILE'
- The file has been added to your private copy of the sources, and
- will be added to the source repository when you run `commit' on
- the file. This is a reminder to you that the file needs to be
- committed.
-
-`R FILE'
- The file has been removed from your private copy of the sources,
- and will be removed from the source repository when you run
- `commit' on the file. This is a reminder to you that the file
- needs to be committed.
-
-`M FILE'
- The file is modified in your working directory.
-
- `M' can indicate one of two states for a file you're working on:
- either there were no modifications to the same file in the
- repository, so that your file remains as you last saw it; or there
- were modifications in the repository as well as in your copy, but
- they were merged successfully, without conflict, in your working
- directory.
-
- CVS will print some messages if it merges your work, and a backup
- copy of your working file (as it looked before you ran `update')
- will be made. The exact name of that file is printed while
- `update' runs.
-
-`C FILE'
- A conflict was detected while trying to merge your changes to FILE
- with changes from the source repository. FILE (the copy in your
- working directory) is now the output of the rcsmerge(1) command on
- the two revisions; an unmodified copy of your file is also in your
- working directory, with the name `.#FILE.REVISION' where REVISION
- is the RCS revision that your modified file started from. Resolve
- the conflict as described in *Note Conflicts example:: (Note that
- some systems automatically purge files that begin with `.#' if
- they have not been accessed for a few days. If you intend to keep
- a copy of your original file, it is a very good idea to rename
- it.) Under VMS, the file name starts with `__' rather than `.#'.
-
-`? FILE'
- FILE is in your working directory, but does not correspond to
- anything in the source repository, and is not in the list of files
- for CVS to ignore (see the description of the `-I' option, and
- *note cvsignore::.).
-
- Note that no warning message like this is printed for spurious
- directories that CVS encounters. The directory, and all its
- contents, are silently ignored.
-
-update examples
----------------
-
- The following line will display all files which are not up-to-date
-without actually change anything in your working directory. It can be
-used to check what has been going on with the project.
-
- $ cvs -n -q update
-
-Reference manual for the Administrative files
-*********************************************
-
- Inside the repository, in the directory `$CVSROOT/CVSROOT', there
-are a number of supportive files for CVS. You can use CVS in a limited
-fashion without any of them, but if they are set up properly they can
-help make life easier. For a discussion of how to edit them, *Note
-Intro administrative files::.
-
- The most important of these files is the `modules' file, which
-defines the modules inside the repository.
-
-The modules file
-================
-
- The `modules' file records your definitions of names for collections
-of source code. CVS will use these definitions if you use CVS to
-update the modules file (use normal commands like `add', `commit', etc).
-
- The `modules' file may contain blank lines and comments (lines
-beginning with `#') as well as module definitions. Long lines can be
-continued on the next line by specifying a backslash (`\') as the last
-character on the line.
-
- A module definition is a single line of the `modules' file, in
-either of two formats. In both cases, MNAME represents the symbolic
-module name, and the remainder of the line is its definition.
-
-`MNAME -a ALIASES...'
- This represents the simplest way of defining a module MNAME. The
- `-a' flags the definition as a simple alias: CVS will treat any
- use of MNAME (as a command argument) as if the list of names
- ALIASES had been specified instead. ALIASES may contain either
- other module names or paths. When you use paths in aliases,
- `checkout' creates all intermediate directories in the working
- directory, just as if the path had been specified explicitly in
- the CVS arguments.
-
-`MNAME [ options ] DIR [ FILES... ] [ &MODULE... ]'
- In the simplest case, this form of module definition reduces to
- `MNAME DIR'. This defines all the files in directory DIR as
- module mname. DIR is a relative path (from `$CVSROOT') to a
- directory of source in the source repository. In this case, on
- checkout, a single directory called MNAME is created as a working
- directory; no intermediate directory levels are used by default,
- even if DIR was a path involving several directory levels.
-
- By explicitly specifying files in the module definition after DIR,
- you can select particular files from directory DIR. The sample
- definition for `modules' is an example of a module defined with a
- single file from a particular directory. Here is another example:
-
- m4test unsupported/gnu/m4 foreach.m4 forloop.m4
-
- With this definition, executing `cvs checkout m4test' will create
- a single working directory `m4test' containing the two files
- listed, which both come from a common directory several levels deep
- in the CVS source repository.
-
- A module definition can refer to other modules by including
- `&MODULE' in its definition. `checkout' creates a subdirectory
- for each such module, in your working directory.
-
- `-d NAME'
- Name the working directory something other than the module
- name.
-
- `-e PROG'
- Specify a program PROG to run whenever files in a module are
- exported. PROG runs with a single argument, the module name.
-
- `-i PROG'
- Specify a program PROG to run whenever files in a module are
- committed. PROG runs with a single argument, the full
- pathname of the affected directory in a source repository.
- The `commitinfo', `loginfo', and `editinfo' files provide
- other ways to call a program on commit.
-
- `-o PROG'
- Specify a program PROG to run whenever files in a module are
- checked out. PROG runs with a single argument, the module
- name.
-
- `-s STATUS'
- Assign a status to the module. When the module file is
- printed with `cvs checkout -s' the modules are sorted
- according to primarily module status, and secondarily
- according to the module name. This option has no other
- meaning. You can use this option for several things besides
- status: for instance, list the person that is responsible for
- this module.
-
- `-t PROG'
- Specify a program PROG to run whenever files in a module are
- tagged with `rtag'. PROG runs with two arguments: the module
- name and the symbolic tag specified to `rtag'. There is no
- way to specify a program to run when `tag' is executed.
-
- `-u PROG'
- Specify a program PROG to run whenever `cvs update' is
- executed from the top-level directory of the checked-out
- module. PROG runs with a single argument, the full path to
- the source repository for this module.
-
-The cvswrappers file
-====================
-
- Wrappers allow you to set a hook which transforms files on their way
-in and out of CVS. Most or all of the wrappers features do not work
-with client/server CVS.
-
- The file `cvswrappers' defines the script that will be run on a file
-when its name matches a regular expresion. There are two scripts that
-can be run on a file or directory. One script is executed on the
-file/directory before being checked into the repository (this is denoted
-with the `-t' flag) and the other when the file is checked out of the
-repository (this is denoted with the `-f' flag)
-
- The `cvswrappers' also has a `-m' option to specify the merge
-methodology that should be used when the file is updated. `MERGE'
-means the usual CVS behavior: try to merge the files (this generally
-will not work for binary files). `COPY' means that `cvs update' will
-merely copy one version over the other, and require the user using
-mechanisms outside CVS, to insert any necessary changes. The `-m'
-wrapper option only affects behavior when merging is done on update; it
-does not affect how files are stored. See *Note Binary files::, for
-more on binary files.
-
- The basic format of the file `cvswrappers' is:
-
- wildcard [option value][option value]...
-
- where option is one of
- -f from cvs filter value: path to filter
- -t to cvs filter value: path to filter
- -m update methodology value: MERGE or COPY
- -k keyword expansion value: expansion mode
-
- and value is a single-quote delimited value.
-
- *.nib -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
- *.c -t 'indent %s %s'
-
-The above example of a `cvswrappers' file states that all
-files/directories that end with a `.nib' should be filtered with the
-`wrap' program before checking the file into the repository. The file
-should be filtered though the `unwrap' program when the file is checked
-out of the repository. The `cvswrappers' file also states that a `COPY'
-methodology should be used when updating the files in the repository
-(that is no merging should be performed).
-
- The last example line says that all files that end with a `*.c'
-should be filtered with `indent' before being checked into the
-repository. Unlike the previous example no filtering of the `*.c' file
-is done when it is checked out of the repository.
-
-The `-t' filter is called with two arguments, the first is the name of
-the file/directory to filter and the second is the pathname to where
-the resulting filtered file should be placed.
-
-The `-f' filter is called with one argument, which is the name of the
-file to filter from. The end result of this filter will be a file in
-the users directory that they can work on as they normally would.
-
- For another example, the following command imports a directory,
-treating files whose name ends in `.exe' as binary:
-
- cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
-
-The commit support files
-========================
-
- The `-i' flag in the `modules' file can be used to run a certain
-program whenever files are committed (*note modules::.). The files
-described in this section provide other, more flexible, ways to run
-programs whenever something is committed.
-
- There are three kind of programs that can be run on commit. They
-are specified in files in the repository, as described below. The
-following table summarizes the file names and the purpose of the
-corresponding programs.
-
-`commitinfo'
- The program is responsible for checking that the commit is
- allowed. If it exits with a non-zero exit status the commit will
- be aborted.
-
-`editinfo'
- The specified program is used to edit the log message, and
- possibly verify that it contains all required fields. This is
- most useful in combination with the `rcsinfo' file, which can hold
- a log message template (*note rcsinfo::.).
-
-`loginfo'
- The specified program is called when the commit is complete. It
- receives the log message and some additional information and can
- store the log message in a file, or mail it to appropriate
- persons, or maybe post it to a local newsgroup, or... Your
- imagination is the limit!
-
-The common syntax
------------------
-
- The four files `commitinfo', `loginfo', `rcsinfo' and `editinfo' all
-have a common format. The purpose of the files are described later on.
-The common syntax is described here.
-
- Each line contains the following:
- * A regular expression
-
- * A whitespace separator--one or more spaces and/or tabs.
-
- * A file name or command-line template.
-
-Blank lines are ignored. Lines that start with the character `#' are
-treated as comments. Long lines unfortunately can *not* be broken in
-two parts in any way.
-
- The first regular expression that matches the current directory name
-in the repository is used. The rest of the line is used as a file name
-or command-line as appropriate.
-
-Commitinfo
-==========
-
- The `commitinfo' file defines programs to execute whenever `cvs
-commit' is about to execute. These programs are used for pre-commit
-checking to verify that the modified, added and removed files are really
-ready to be committed. This could be used, for instance, to verify
-that the changed files conform to to your site's standards for coding
-practice.
-
- As mentioned earlier, each line in the `commitinfo' file consists of
-a regular expression and a command-line template. The template can
-include a program name and any number of arguments you wish to supply
-to it. The full path to the current source repository is appended to
-the template, followed by the file names of any files involved in the
-commit (added, removed, and modified files).
-
- The first line with a regular expression matching the relative path
-to the module will be used. If the command returns a non-zero exit
-status the commit will be aborted.
-
- If the repository name does not match any of the regular expressions
-in this file, the `DEFAULT' line is used, if it is specified.
-
- All occurances of the name `ALL' appearing as a regular expression
-are used in addition to the first matching regular expression or the
-name `DEFAULT'.
-
- Note: when CVS is accessing a remote repository, `commitinfo' will
-be run on the *remote* (i.e., server) side, not the client side (*note
-Remote repositories::.).
-
-Editinfo
-========
-
- If you want to make sure that all log messages look the same way,
-you can use the `editinfo' file to specify a program that is used to
-edit the log message. This program could be a custom-made editor that
-always enforces a certain style of the log message, or maybe a simple
-shell script that calls an editor, and checks that the entered message
-contains the required fields.
-
- If no matching line is found in the `editinfo' file, the editor
-specified in the environment variable `$CVSEDITOR' is used instead. If
-that variable is not set, then the environment variable `$EDITOR' is
-used instead. If that variable is not set a precompiled default,
-normally `vi', will be used.
-
- The `editinfo' file is often most useful together with the `rcsinfo'
-file, which can be used to specify a log message template.
-
- Each line in the `editinfo' file consists of a regular expression
-and a command-line template. The template must include a program name,
-and can include any number of arguments. The full path to the current
-log message template file is appended to the template.
-
- One thing that should be noted is that the `ALL' keyword is not
-supported. If more than one matching line is found, the first one is
-used. This can be useful for specifying a default edit script in a
-module, and then overriding it in a subdirectory.
-
- If the repository name does not match any of the regular expressions
-in this file, the `DEFAULT' line is used, if it is specified.
-
- If the edit script exits with a non-zero exit status, the commit is
-aborted.
-
- Note: when CVS is accessing a remote repository, or when the `-m' or
-`-F' options to `cvs commit' are used, `editinfo' will not be consulted.
-There is no good workaround for this.
-
-Editinfo example
-----------------
-
- The following is a little silly example of a `editinfo' file,
-together with the corresponding `rcsinfo' file, the log message
-template and an editor script. We begin with the log message template.
-We want to always record a bug-id number on the first line of the log
-message. The rest of log message is free text. The following template
-is found in the file `/usr/cvssupport/tc.template'.
-
- BugId:
-
- The script `/usr/cvssupport/bugid.edit' is used to edit the log
-message.
-
- #!/bin/sh
- #
- # bugid.edit filename
- #
- # Call $EDITOR on FILENAME, and verify that the
- # resulting file contains a valid bugid on the first
- # line.
- if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
- if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
- $CVSEDITOR $1
- until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
- do echo -n "No BugId found. Edit again? ([y]/n)"
- read ans
- case ${ans} in
- n*) exit 1;;
- esac
- $CVSEDITOR $1
- done
-
- The `editinfo' file contains this line:
-
- ^tc /usr/cvssupport/bugid.edit
-
- The `rcsinfo' file contains this line:
-
- ^tc /usr/cvssupport/tc.template
-
-Loginfo
-=======
-
- The `loginfo' file is used to control where `cvs commit' log
-information is sent. The first entry on a line is a regular expression
-which is tested against the directory that the change is being made to,
-relative to the `$CVSROOT'. If a match is found, then the remainder of
-the line is a filter program that should expect log information on its
-standard input.
-
- The filter program may use one and only one % modifier (a la
-printf). If `%s' is specified in the filter program, a brief title is
-included (enclosed in single quotes) showing the modified file names.
-
- If the repository name does not match any of the regular expressions
-in this file, the `DEFAULT' line is used, if it is specified.
-
- All occurances of the name `ALL' appearing as a regular expression
-are used in addition to the first matching regular expression or
-`DEFAULT'.
-
- The first matching regular expression is used.
-
- *Note commit files::, for a description of the syntax of the
-`loginfo' file.
-
- Note: when CVS is accessing a remote repository, `loginfo' will be
-run on the *remote* (i.e., server) side, not the client side (*note
-Remote repositories::.).
-
-Loginfo example
----------------
-
- The following `loginfo' file, together with the tiny shell-script
-below, appends all log messages to the file
-`$CVSROOT/CVSROOT/commitlog', and any commits to the administrative
-files (inside the `CVSROOT' directory) are also logged in
-`/usr/adm/cvsroot-log'.
-
- ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog
- ^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log
-
- The shell-script `/usr/local/bin/cvs-log' looks like this:
-
- #!/bin/sh
- (echo "-----------------------------------------------------------------";
- echo -n $USER" ";
- date;
- echo;
- sed '1s+'${CVSROOT}'++') >> $1
-
-Keeping a checked out copy
---------------------------
-
- It is often useful to maintain a directory tree which contains files
-which correspond to the latest version in the repository. For example,
-other developers might want to refer to the latest sources without
-having to check them out, or you might be maintaining a web site with
-CVS and want every checkin to cause the files used by the web server to
-be updated.
-
- The way to do this is by having loginfo invoke `cvs update'. Doing
-so in the naive way will cause a problem with locks, so the `cvs update'
-must be run in the background. Here is an example (this should all be
-on one line):
-
- ^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs;
- cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
-
- This will cause checkins to repository directories starting with
-`cyclic-pages' to update the checked out tree in `/u/www/local-docs'.
-
-Rcsinfo
-=======
-
- The `rcsinfo' file can be used to specify a form to edit when
-filling out the commit log. The `rcsinfo' file has a syntax similar to
-the `editinfo', `commitinfo' and `loginfo' files. *Note syntax::.
-Unlike the other files the second part is *not* a command-line
-template. Instead, the part after the regular expression should be a
-full pathname to a file containing the log message template.
-
- If the repository name does not match any of the regular expressions
-in this file, the `DEFAULT' line is used, if it is specified.
-
- All occurances of the name `ALL' appearing as a regular expression
-are used in addition to the first matching regular expression or
-`DEFAULT'.
-
- The log message template will be used as a default log message. If
-you specify a log message with `cvs commit -m MESSAGE' or `cvs commit -f
-FILE' that log message will override the template.
-
- *Note editinfo example::, for an example `rcsinfo' file.
-
- When CVS is accessing a remote repository, the contents of `rcsinfo'
-at the time a directory is first checked out will specify a template
-which does not then change. If you edit `rcsinfo' or its templates,
-you may need to check out a new working directory.
-
-Ignoring files via cvsignore
-============================
-
- There are certain file names that frequently occur inside your
-working copy, but that you don't want to put under CVS control.
-Examples are all the object files that you get while you compile your
-sources. Normally, when you run `cvs update', it prints a line for
-each file it encounters that it doesn't know about (*note update
-output::.).
-
- CVS has a list of files (or sh(1) file name patterns) that it should
-ignore while running `update', `import' and `release'. This list is
-constructed in the following way.
-
- * The list is initialized to include certain file name patterns:
- names associated with CVS administration, or with other common
- source control systems; common names for patch files, object files,
- archive files, and editor backup files; and other names that are
- usually artifacts of assorted utilities. Currently, the default
- list of ignored file name patterns is:
-
- RCS SCCS CVS CVS.adm
- RCSLOG cvslog.*
- tags TAGS
- .make.state .nse_depinfo
- *~ #* .#* ,* _$* *$
- *.old *.bak *.BAK *.orig *.rej .del-*
- *.a *.olb *.o *.obj *.so *.exe
- *.Z *.elc *.ln
- core
-
- * The per-repository list in `$CVSROOT/CVSROOT/cvsignore' is
- appended to the list, if that file exists.
-
- * The per-user list in `.cvsignore' in your home directory is
- appended to the list, if it exists.
-
- * Any entries in the environment variable `$CVSIGNORE' is appended
- to the list.
-
- * Any `-I' options given to CVS is appended.
-
- * As CVS traverses through your directories, the contents of any
- `.cvsignore' will be appended to the list. The patterns found in
- `.cvsignore' are only valid for the directory that contains them,
- not for any sub-directories.
-
- In any of the 5 places listed above, a single exclamation mark (`!')
-clears the ignore list. This can be used if you want to store any file
-which normally is ignored by CVS.
-
-The history file
-================
-
- The file `$CVSROOT/CVSROOT/history' is used to log information for
-the `history' command (*note history::.). This file must be created to
-turn on logging. This is done automatically if the `cvs init' command
-is used to set up the repository (*note Creating a repository::.).
-
- The file format of the `history' file is documented only in comments
-in the CVS source code, but generally programs should use the `cvs
-history' command to access it anyway, in case the format changes with
-future releases of CVS.
-
-Expansions in administrative files
-==================================
-
- Sometimes in writing an administrative file, you might want the file
-to be able to know various things based on environment CVS is running
-in. There are several mechanisms to do that.
-
- To find the home directory of the user running CVS (from the `HOME'
-environment variable), use `~' followed by `/' or the end of the line.
-Likewise for the home directory of USER, use `~USER'. These variables
-are expanded on the server machine, and don't get any resonable
-expansion if pserver (*note Password authenticated::.) is in used;
-therefore user variables (see below) may be a better choice to
-customize behavior based on the user running CVS.
-
- One may want to know about various pieces of information internal to
-CVS. A CVS internal variable has the syntax `${VARIABLE}', where
-VARIABLE starts with a letter and consists of alphanumberic characters
-and `_'. If the character following VARIABLE is a non-alphanumeric
-character other than `_', the `{' and `}' can be omitted. The CVS
-internal variables are:
-
-`CVSROOT'
- This is the value of the CVS root in use. *Note Repository::, for
- a description of the various ways to specify this.
-
-`RCSBIN'
- This is the value CVS is using for where to find RCS binaries.
- *Note Global options::, for a description of how to specify this.
-
-`CVSEDITOR'
-`VISUAL'
-`EDITOR'
- These all expand to the same value, which is the editor that CVS
- is using. *Note Global options::, for how to specify this.
-
-`USER'
- Username of the user running CVS (on the CVS server machine).
-
- If you want to pass a value to the administrative files which the
-user that is running CVS can specify, use a user variable. To expand a
-user variable, the administrative file contains `${=VARIABLE}'. To set
-a user variable, specify the global option `-s' to CVS, with argument
-`VARIABLE=VALUE'. It may be particularly useful to specify this option
-via `.cvsrc' (*note ~/.cvsrc::.).
-
- For example, if you want the administrative file to refer to a test
-directory you might create a user variable `TESTDIR'. Then if CVS is
-invoked as `cvs -s TESTDIR=/work/local/tests', and the administrative
-file contains `sh ${=TESTDIR}/runtests', then that string is expanded
-to `sh /work/local/tests/runtests'.
-
- All other strings containing `$' are reserved; there is no way to
-quote a `$' character so that `$' represents itself.
-
-All environment variables which affect CVS
-******************************************
-
- This is a complete list of all environment variables that affect CVS.
-
-`$CVSIGNORE'
- A whitespace-separated list of file name patterns that CVS should
- ignore. *Note cvsignore::.
-
-`$CVSWRAPPERS'
- A whitespace-separated list of file name patterns that CVS should
- treat as wrappers. *Note Wrappers::.
-
-`$CVSREAD'
- If this is set, `checkout' and `update' will try hard to make the
- files in your working directory read-only. When this is not set,
- the default behavior is to permit modification of your working
- files.
-
-`$CVSROOT'
- Should contain the full pathname to the root of the CVS source
- repository (where the RCS history files are kept). This
- information must be available to CVS for most commands to execute;
- if `$CVSROOT' is not set, or if you wish to override it for one
- invocation, you can supply it on the command line: `cvs -d cvsroot
- cvs_command...' Once you have checked out a working directory, CVS
- stores the appropriate root (in the file `CVS/Root'), so normally
- you only need to worry about this when initially checking out a
- working directory.
-
-`$EDITOR'
-`$CVSEDITOR'
- Specifies the program to use for recording log messages during
- commit. If not set, the default is `/usr/ucb/vi'. `$CVSEDITOR'
- overrides `$EDITOR'. `$CVSEDITOR' does not exist in CVS 1.3, but
- the next release will probably include it.
-
-`$PATH'
- If `$RCSBIN' is not set, and no path is compiled into CVS, it will
- use `$PATH' to try to find all programs it uses.
-
-`$RCSBIN'
- This is the value CVS is using for where to find RCS binaries.
- *Note Global options::, for a description of how to specify this.
- If not set, a compiled-in value is used, or your `$PATH' is
- searched.
-
-`$HOME'
-
-`$HOMEPATH'
- Used to locate the directory where the `.cvsrc' file is searched
- (`$HOMEPATH' is used for Windows-NT). *note ~/.cvsrc::.
-
-`$CVS_RSH'
- Specifies the external program which CVS connects with, when
- `:ext:' access method is specified. *note Connecting via rsh::..
-
-`$CVS_SERVER'
- Used in client-server mode when accessing a remote repository
- using RSH. It specifies the name of the program to start on the
- server side when accessing a remote repository using RSH. The
- default value is `cvs'. *note Connecting via rsh::.
-
-`$CVS_PASSFILE'
- Used in client-server mode when accessing the `cvs login server'.
- Default value is `$HOME/.cvspass'. *note Password authentication
- client::.
-
-`$CVS_PASSWORD'
- Used in client-server mode when accessing the `cvs login server'.
- *note Password authentication client::.
-
-`$CVS_CLIENT_PORT'
- Used in client-server mode when accessing the server via Kerberos.
- *note Kerberos authenticated::.
-
-`$CVS_RCMD_PORT'
- Used in client-server mode. If set, specifies the port number to
- be used when accessing the RCMD demon on the server side.
- (Currently not used for Unix clients).
-
-`$CVS_CLIENT_LOG'
- Used for debugging only in client-server mode. If set, everything
- send to the server is logged into ``$CVS_CLIENT_LOG'.in' and
- everything send from the server is logged into
- ``$CVS_CLIENT_LOG'.out'.
-
-`$CVS_SERVER_SLEEP'
- Used only for debugging the server side in client-server mode. If
- set, delays the start of the server child process the the
- specified amount of seconds so that you can attach to it with a
- debugger.
-
-`$CVS_IGNORE_REMOTE_ROOT'
- (What is the purpose of this variable?)
-
-`$COMSPEC'
- Used under OS/2 only. It specifies the name of the command
- interpreter and defaults to CMD.EXE.
-
-`$TMPDIR'
-`$TMP'
-`$TEMP'
- Directory in which temporary files are located. Those parts of
- CVS which are implemented using RCS inspect the above variables in
- the order they appear above and the first value found is taken; if
- none of them are set, a host-dependent default is used, typically
- `/tmp'. The CVS server uses `TMPDIR'. *Note Global options::,
- for a description of how to specify this. Some parts of CVS will
- always use `/tmp' (via the `tmpnam' function provided by the
- system).
-
- On Windows NT, `TMP' is used (via the `_tempnam' function provided
- by the system).
-
- The `patch' program which is used by the CVS client uses `TMPDIR',
- and if it is not set, uses `/tmp' (at least with GNU patch 2.1).
-
- CVS invokes RCS to perform certain operations. The following
-environment variables affect RCS. Note that if you are using the
-client/server CVS, these variables need to be set on the server side
-(which may or not may be possible depending on how you are connecting).
-There is probably not any need to set any of them, however.
-
-`$LOGNAME'
-`$USER'
- If set, they affect who RCS thinks you are. If you have trouble
- checking in files it might be because your login name differs from
- the setting of e.g. `$LOGNAME'.
-
-`$RCSINIT'
- Options prepended to the argument list, separated by spaces. A
- backslash escapes spaces within an option. The `$RCSINIT' options
- are prepended to the argument lists of most RCS commands.
-
-Troubleshooting
-***************
-
-Magic branch numbers
-====================
-
- Externally, branch numbers consist of an odd number of dot-separated
-decimal integers. *Note Revision numbers::. That is not the whole
-truth, however. For efficiency reasons CVS sometimes inserts an extra 0
-in the second rightmost position (1.2.3 becomes 1.2.0.3, 8.9.10.11.12
-becomes 8.9.10.11.0.12 and so on).
-
- CVS does a pretty good job at hiding these so called magic branches,
-but in a few places the hiding is incomplete:
-
- * The magic branch number appears in the output from `cvs log'.
-
- * You cannot specify a symbolic branch name to `cvs admin'.
-
- You can use the `admin' command to reassign a symbolic name to a
-branch the way RCS expects it to be. If `R4patches' is assigned to the
-branch 1.4.2 (magic branch number 1.4.0.2) in file `numbers.c' you can
-do this:
-
- $ cvs admin -NR4patches:1.4.2 numbers.c
-
- It only works if at least one revision is already committed on the
-branch. Be very careful so that you do not assign the tag to the wrong
-number. (There is no way to see how the tag was assigned yesterday).
-
-GNU GENERAL PUBLIC LICENSE
-**************************
-
-Index
-*****
-
-* Menu:
-
-* -j (merging branches): Merging a branch.
-* -k (RCS kflags): Substitution modes.
-* .# files: update output.
-* .bashrc, setting CVSROOT in: Specifying a repository.
-* .cshrc, setting CVSROOT in: Specifying a repository.
-* .cvsrc file: ~/.cvsrc.
-* .profile, setting CVSROOT in: Specifying a repository.
-* .tcshrc, setting CVSROOT in: Specifying a repository.
-* /usr/local/cvsroot, as example repository: Repository.
-* :ext:: Connecting via rsh.
-* :kserver:: Kerberos authenticated.
-* :local:: Repository.
-* :pserver:: Password authentication client.
-* :server:: Connecting via rsh.
-* <<<<<<<: Conflicts example.
-* =======: Conflicts example.
-* >>>>>>>: Conflicts example.
-* __ files (VMS): update output.
-* A sample session: A sample session.
-* abandoning work: Editing files.
-* About this manual: Preface.
-* add (subcommand): Adding files.
-* Adding a tag: Tags.
-* Adding files: Adding files.
-* Admin (subcommand): admin.
-* Administrative files (intro): Intro administrative files.
-* Administrative files (reference): Administrative files.
-* Administrative files, editing them: Intro administrative files.
-* ALL in commitinfo: commitinfo.
-* annotate (subcommand): annotate.
-* Atomic transactions, lack of: Concurrency.
-* authenticated client, using: Password authentication client.
-* authenticating server, setting up: Password authentication server.
-* Author keyword: Keyword list.
-* Automatically ignored files: cvsignore.
-* Avoiding editor invocation: Common options.
-* Binary files: Binary files.
-* Branch merge example: Merging a branch.
-* Branch number: Revision numbers.
-* Branch numbers: Creating a branch.
-* Branch, creating a: Creating a branch.
-* Branch, vendor-: Tracking sources.
-* Branches: Branches.
-* Branches motivation: Branches motivation.
-* Branches, copying changes between: Merging.
-* Branches, sticky: Sticky tags.
-* Bringing a file up to date: Updating a file.
-* Bugs, known in this manual: BUGS.
-* Bugs, reporting (manual): BUGS.
-* Changes, copying between branches: Merging.
-* Changing a log message: admin options.
-* checked out copy, keeping: Keeping a checked out copy.
-* Checkin program: modules.
-* Checking commits: commitinfo.
-* Checking out source: Getting the source.
-* Checkout (subcommand): checkout.
-* Checkout program: modules.
-* checkout, as term for getting ready to edit: Editing files.
-* Checkout, example: Getting the source.
-* choosing, reserved or unreserved checkouts: Choosing a model.
-* Cleaning up: Cleaning up.
-* Client/Server Operation: Remote repositories.
-* Co (subcommand): checkout.
-* Command reference: Invoking CVS.
-* Command structure: Structure.
-* Comment leader: admin examples.
-* Commit (subcommand): commit.
-* Commit files: commit files.
-* Commit, when to: When to commit.
-* Commitinfo: commitinfo.
-* Committing changes: Committing your changes.
-* Common options: Common options.
-* Common syntax of info files: syntax.
-* COMSPEC: Environment variables.
-* Conflict markers: Conflicts example.
-* Conflict resolution: Conflicts example.
-* Conflicts (merge example): Conflicts example.
-* Contributors (CVS program): What is CVS?.
-* Contributors (manual): Credits.
-* Copying changes: Merging.
-* Correcting a log message: admin options.
-* Creating a branch: Creating a branch.
-* Creating a project: Starting a new project.
-* Creating a repository: Creating a repository.
-* Credits (CVS program): What is CVS?.
-* Credits (manual): Credits.
-* CVS 1.6, and watches: Watches Compatibility.
-* CVS command structure: Structure.
-* CVS passwd file: Password authentication server.
-* CVS, history of: What is CVS?.
-* CVS, introduction to: What is CVS?.
-* CVS_CLIENT_LOG: Environment variables.
-* CVS_CLIENT_PORT: Kerberos authenticated.
-* CVS_IGNORE_REMOTE_ROOT: Environment variables.
-* CVS_PASSFILE, environment variable: Password authentication client.
-* CVS_PASSWORD, environment variable: Password authentication client.
-* CVS_RCMD_PORT: Environment variables.
-* CVS_RSH: Environment variables.
-* CVS_SERVER: Connecting via rsh.
-* CVS_SERVER_SLEEP: Environment variables.
-* CVSEDITOR: Environment variables.
-* CVSEDITOR, environment variable: Committing your changes.
-* CVSIGNORE: Environment variables.
-* cvsignore (admin file), global: cvsignore.
-* CVSREAD: Environment variables.
-* CVSREAD, overriding: Global options.
-* CVSROOT: Environment variables.
-* cvsroot: Repository.
-* CVSROOT (file): Administrative files.
-* CVSROOT, environment variable: Specifying a repository.
-* CVSROOT, module name: Intro administrative files.
-* CVSROOT, multiple repositories: Multiple repositories.
-* CVSROOT, overriding: Global options.
-* CVSUMASK: File permissions.
-* CVSWRAPPERS: Environment variables.
-* cvswrappers (admin file): Wrappers.
-* CVSWRAPPERS, environment variable: Wrappers.
-* Date keyword: Keyword list.
-* Dates: Common options.
-* Decimal revision number: Revision numbers.
-* DEFAULT in commitinfo: commitinfo.
-* DEFAULT in editinfo: editinfo.
-* Defining a module: Defining the module.
-* Defining modules (intro): Intro administrative files.
-* Defining modules (reference manual): modules.
-* Deleting files: Removing files.
-* Deleting revisions: admin options.
-* Deleting sticky tags: Sticky tags.
-* Descending directories: Recursive behavior.
-* Diff: Viewing differences.
-* Diff (subcommand): diff.
-* Differences, merging: Merging two revisions.
-* Directories, moving: Moving directories.
-* Directory, descending: Recursive behavior.
-* Disjoint repositories: Multiple repositories.
-* Distributing log messages: loginfo.
-* driver.c (merge example): Conflicts example.
-* edit (subcommand): Editing files.
-* editinfo (admin file): editinfo.
-* Editing administrative files: Intro administrative files.
-* Editing the modules file: Defining the module.
-* EDITOR: Environment variables.
-* Editor, avoiding invocation of: Common options.
-* EDITOR, environment variable: Committing your changes.
-* EDITOR, overriding: Global options.
-* Editor, specifying per module: editinfo.
-* editors (subcommand): Watch information.
-* emerge: Conflicts example.
-* Environment variables: Environment variables.
-* Errors, reporting (manual): BUGS.
-* Example of a work-session: A sample session.
-* Example of merge: Conflicts example.
-* Example, branch merge: Merging a branch.
-* Export (subcommand): export.
-* Export program: modules.
-* Fetching source: Getting the source.
-* File locking: Multiple developers.
-* File permissions: File permissions.
-* File status: File status.
-* Files, moving: Moving files.
-* Files, reference manual: Administrative files.
-* Fixing a log message: admin options.
-* Forcing a tag match: Common options.
-* Form for log message: rcsinfo.
-* Format of CVS commands: Structure.
-* Getting started: A sample session.
-* Getting the source: Getting the source.
-* Global cvsignore: cvsignore.
-* Global options: Global options.
-* Group: File permissions.
-* Header keyword: Keyword list.
-* History (subcommand): history.
-* History browsing: History browsing.
-* History file: history file.
-* History files: Repository files.
-* History of CVS: What is CVS?.
-* HOME: Environment variables.
-* HOMEPATH: Environment variables.
-* Id keyword: Keyword list.
-* Ident (shell command): Using keywords.
-* Identifying files: Keyword substitution.
-* Ignored files: cvsignore.
-* Ignoring files: cvsignore.
-* Import (subcommand): import.
-* Importing files: From files.
-* Importing files, from other version control systesm: From other version
control systems.
-* Importing modules: First import.
-* Index: Index.
-* Info files (syntax): syntax.
-* Informing others: Informing others.
-* init (subcommand): Creating a repository.
-* Introduction to CVS: What is CVS?.
-* Invoking CVS: Invoking CVS.
-* Isolation: History browsing.
-* Join: Merging a branch.
-* keeping a checked out copy: Keeping a checked out copy.
-* kerberos: Kerberos authenticated.
-* Keyword expansion: Keyword substitution.
-* Keyword substitution: Keyword substitution.
-* Kflag: Substitution modes.
-* kinit: Kerberos authenticated.
-* Known bugs in this manual: BUGS.
-* Layout of repository: Repository.
-* Left-hand options: Global options.
-* Linear development: Revision numbers.
-* List, mailing list: What is CVS?.
-* Locally Added: File status.
-* Locally Modified: File status.
-* Locally Removed: File status.
-* Locker keyword: Keyword list.
-* Locking files: Multiple developers.
-* locks, cvs: Concurrency.
-* Log (subcommand): log.
-* Log information, saving: history file.
-* Log keyword: Keyword list.
-* Log keyword, selecting comment leader: admin examples.
-* Log message entry: Committing your changes.
-* Log message template: rcsinfo.
-* Log message, correcting: admin options.
-* Log messages: loginfo.
-* Log messages, editing: editinfo.
-* Login (subcommand): Password authentication client.
-* loginfo (admin file): loginfo.
-* LOGNAME: Environment variables.
-* Mail, automatic mail on commit: Informing others.
-* Mailing list: What is CVS?.
-* Mailing log messages: loginfo.
-* Main trunk (intro): Revision numbers.
-* Main trunk and branches: Branches.
-* Many repositories: Multiple repositories.
-* Markers, conflict: Conflicts example.
-* Merge, an example: Conflicts example.
-* Merge, branch example: Merging a branch.
-* Merging: Merging.
-* Merging a branch: Merging a branch.
-* Merging a file: Updating a file.
-* Merging two revisions: Merging two revisions.
-* Modifications, copying between branches: Merging.
-* Module status: modules.
-* Module, defining: Defining the module.
-* Modules (admin file): modules.
-* Modules (intro): Basic concepts.
-* Modules file: Intro administrative files.
-* Modules file, changing: Defining the module.
-* Motivation for branches: Branches motivation.
-* Moving directories: Moving directories.
-* Moving files: Moving files.
-* Multiple developers: Multiple developers.
-* Multiple repositories: Multiple repositories.
-* Name keyword: Keyword list.
-* Name, symbolic (tag): Tags.
-* Needs Checkout: File status.
-* Needs Merge: File status.
-* Needs Patch: File status.
-* Newsgroups: What is CVS?.
-* notify (admin file): Getting Notified.
-* Nroff (selecting comment leader): admin examples.
-* Number, branch: Revision numbers.
-* Number, revision-: Revision numbers.
-* option defaults: ~/.cvsrc.
-* Options, global: Global options.
-* Outdating revisions: admin options.
-* Overlap: Updating a file.
-* Overriding CVSREAD: Global options.
-* Overriding CVSROOT: Global options.
-* Overriding EDITOR: Global options.
-* Overriding RCSBIN: Global options.
-* Overriding TMPDIR: Global options.
-* Parallel repositories: Multiple repositories.
-* passwd (admin file): Password authentication server.
-* password client, using: Password authentication client.
-* password server, setting up: Password authentication server.
-* PATH: Environment variables.
-* Per-module editor: editinfo.
-* Policy: When to commit.
-* Precommit checking: commitinfo.
-* Preface: Preface.
-* Pserver (subcommand): Password authentication server.
-* RCS history files: Repository files.
-* RCS keywords: Keyword list.
-* RCS revision numbers: Tags.
-* RCS, importing files from: From other version control systems.
-* RCS-style locking: Multiple developers.
-* RCSBIN: Environment variables.
-* RCSBIN, overriding: Global options.
-* RCSfile keyword: Keyword list.
-* rcsinfo (admin file): rcsinfo.
-* RCSINIT: Environment variables.
-* Rdiff (subcommand): rdiff.
-* read-only files, and -r: Global options.
-* read-only files, and CVSREAD: Environment variables.
-* read-only files, and watches: Setting a watch.
-* read-only files, in repository: File permissions.
-* Read-only mode: Global options.
-* Recursive (directory descending): Recursive behavior.
-* Reference manual (files): Administrative files.
-* Reference manual for variables: Environment variables.
-* Reference, commands: Invoking CVS.
-* Release (subcommand): release.
-* Releases, revisions and versions: Versions revisions releases.
-* Releasing your working copy: Cleaning up.
-* Remote repositories: Remote repositories.
-* Remove (subcommand): Removing files.
-* Removing a change: Merging two revisions.
-* Removing files: Removing files.
-* Removing your working copy: Cleaning up.
-* Renaming directories: Moving directories.
-* Renaming files: Moving files.
-* Replacing a log message: admin options.
-* Reporting bugs (manual): BUGS.
-* Repositories, multiple: Multiple repositories.
-* Repositories, remote: Remote repositories.
-* Repository (intro): Repository.
-* Repository, example: Repository.
-* Repository, how data is stored: Repository storage.
-* Repository, setting up: Creating a repository.
-* reserved checkouts: Multiple developers.
-* Resetting sticky tags: Sticky tags.
-* Resolving a conflict: Conflicts example.
-* Restoring old version of removed file: Sticky tags.
-* Resurrecting old version of dead file: Sticky tags.
-* Retrieving an old revision using tags: Tags.
-* reverting to repository version: Editing files.
-* Revision keyword: Keyword list.
-* Revision management: Revision management.
-* Revision numbers: Revision numbers.
-* Revision tree: Revision numbers.
-* Revision tree, making branches: Branches.
-* Revisions, merging differences between: Merging two revisions.
-* Revisions, versions and releases: Versions revisions releases.
-* Right-hand options: Common options.
-* rsh: Connecting via rsh.
-* Rtag (subcommand): rtag.
-* rtag, creating a branch using: Creating a branch.
-* Saving space: admin options.
-* SCCS, importing files from: From other version control systems.
-* Security: File permissions.
-* setgid: File permissions.
-* Setting up a repository: Creating a repository.
-* setuid: File permissions.
-* Signum Support: Preface.
-* Source keyword: Keyword list.
-* Source, getting CVS source: What is CVS?.
-* Source, getting from CVS: Getting the source.
-* Specifying dates: Common options.
-* Spreading information: Informing others.
-* Starting a project with CVS: Starting a new project.
-* State keyword: Keyword list.
-* Status (subcommand): status.
-* Status of a file: File status.
-* Status of a module: modules.
-* sticky date: Sticky tags.
-* Sticky tags: Sticky tags.
-* Sticky tags, resetting: Sticky tags.
-* Storing log messages: loginfo.
-* Structure: Structure.
-* Subdirectories: Recursive behavior.
-* Support, getting CVS support: Preface.
-* Symbolic name (tag): Tags.
-* Syntax of info files: syntax.
-* Tag (subcommand): tag.
-* Tag program: modules.
-* tag, command, introduction: Tags.
-* tag, example: Tags.
-* Tag, retrieving old revisions: Tags.
-* Tag, symbolic name: Tags.
-* taginfo: user-defined logging.
-* Tags: Tags.
-* Tags, sticky: Sticky tags.
-* tc, Trivial Compiler (example): A sample session.
-* Team of developers: Multiple developers.
-* TEMP: Environment variables.
-* Template for log message: rcsinfo.
-* temporary files, location of: Environment variables.
-* Third-party sources: Tracking sources.
-* Time: Common options.
-* timezone, in input: Common options.
-* timezone, in output: log.
-* TMP: Environment variables.
-* TMPDIR: Environment variables.
-* TMPDIR, overriding: Global options.
-* Trace: Global options.
-* Traceability: History browsing.
-* Tracking sources: Tracking sources.
-* Transactions, atomic, lack of: Concurrency.
-* Trivial Compiler (example): A sample session.
-* Typical repository: Repository.
-* umask, for repository files: File permissions.
-* Undoing a change: Merging two revisions.
-* unedit (subcommand): Editing files.
-* Unknown: File status.
-* unreserved checkouts: Multiple developers.
-* Unresolved Conflict: File status.
-* Up-to-date: File status.
-* Update (subcommand): update.
-* Update program: modules.
-* update, introduction: Updating a file.
-* Updating a file: Updating a file.
-* USER: Environment variables.
-* users (admin file): Getting Notified.
-* Vendor: Tracking sources.
-* Vendor branch: Tracking sources.
-* Versions, revisions and releases: Versions revisions releases.
-* Viewing differences: Viewing differences.
-* watch add (subcommand): Getting Notified.
-* watch off (subcommand): Setting a watch.
-* watch on (subcommand): Setting a watch.
-* watch remove (subcommand): Getting Notified.
-* watchers (subcommand): Watch information.
-* Watches: Watches.
-* Wdiff (import example): First import.
-* What (shell command): Using keywords.
-* What branches are good for: Branches motivation.
-* What is CVS?: What is CVS?.
-* When to commit: When to commit.
-* Work-session, example of: A sample session.
-* Working copy: Multiple developers.
-* Working copy, removing: Cleaning up.
-* Wrappers: Wrappers.
-* zone, time, in input: Common options.
-* zone, time, in output: log.
-
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- www/software/cvs .bash_profile .symlinks cvs.ht...,
karl <=