[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Cvs-cvs] ccvs/doc ChangeLog cvs.texinfo stamp-1 stamp-vt... [newtags2]
|
From: |
Derek Robert Price |
|
Subject: |
[Cvs-cvs] ccvs/doc ChangeLog cvs.texinfo stamp-1 stamp-vt... [newtags2] |
|
Date: |
Tue, 17 Jan 2006 15:42:47 +0000 |
CVSROOT: /cvsroot/cvs
Module name: ccvs
Branch: newtags2
Changes by: Derek Robert Price <address@hidden> 06/01/17 15:42:47
Modified files:
doc : ChangeLog cvs.texinfo stamp-1 stamp-vti
version-client.texi version.texi
Log message:
* cvs.texinfo: Misc changes describing tag extensions.
(Patch from Frank Hemer <address@hidden>.)
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/cvs/ccvs/doc/ChangeLog.diff?only_with_tag=newtags2&tr1=1.945&tr2=1.945.2.1&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/cvs/ccvs/doc/cvs.texinfo.diff?only_with_tag=newtags2&tr1=1.674&tr2=1.674.2.1&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/cvs/ccvs/doc/stamp-1.diff?only_with_tag=newtags2&tr1=1.77&tr2=1.77.2.1&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/cvs/ccvs/doc/stamp-vti.diff?only_with_tag=newtags2&tr1=1.171&tr2=1.171.2.1&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/cvs/ccvs/doc/version-client.texi.diff?only_with_tag=newtags2&tr1=1.77&tr2=1.77.2.1&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/cvs/ccvs/doc/version.texi.diff?only_with_tag=newtags2&tr1=1.172&tr2=1.172.2.1&r1=text&r2=text
Patches:
Index: ccvs/doc/ChangeLog
diff -u /dev/null ccvs/doc/ChangeLog:1.945.2.1
--- /dev/null Tue Jan 17 15:42:47 2006
+++ ccvs/doc/ChangeLog Tue Jan 17 15:42:46 2006
@@ -0,0 +1,5359 @@
+2006-01-17 Derek Price <address@hidden>
+
+ * cvs.texinfo: Misc changes describing tag extensions.
+ (Patch from Frank Hemer <address@hidden>.)
+
+2005-12-31 Mark D. Baushke <address@hidden>
+
+ [Add CVSNT compatible [-w width] switch to cvs (r)annotate command.]
+ * cvs.texinfo (Invoking CVS): Document new -w width option.
+ (annotate options): Ditto.
+
+2005-12-09 Derek Price <address@hidden>
+
+ [patch #4634]
+ * cvsclient.texi (Root request): Clarify.
+
+2005-11-30 Mark D. Baushke <address@hidden>
+
+ [bug #14900] Add 'cvs server' handling for --allow-root
+ * cvs.texinfo (Error messages): Add a note about the Bad root
+ error that may arise if --allow-root is used and does not include
+ the directory the cvs client wants to use.
+
+2005-11-15 Derek Price <address@hidden>
+
+ * cvs.texinfo (release output, update output): Remove references to P.
+
+2005-11-12 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (admin options): Document new --execute and
+ --no-execute options.
+ (Based on CVS patch #4446 from Alex Manoussakis.)
+
+2005-11-10 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Common options): -n no longer applies to commit.
+ (commit): Remove reference to the defunct -n option.
+ * cvs.1, stamp-vti, version.texi: Regenerated
+
+2005-10-12 Derek Price <address@hidden>
+
+ * cvs.texinfo: Remove text that created unintentional cross-references
+ in generated info files.
+
+2005-10-06 Derek Price <address@hidden>
+
+ * cvs.texinfo (loginfo): Correct typo. (From Wiki.)
+
+2005-10-04 Derek Price <address@hidden>
+
+ * cvs.texinfo: s/visa versa/vice versa/. (From Wiki.)
+
+2005-09-26 Derek Price <address@hidden>
+
+ * Makefile.am (cvs-paper.ps, cvs-paper.pdf): Remove implicit sources.
+ Add comments about why implicit rules won't work for these targets.
+ Make sure the distributed cvs-paper.pdf is created in $(srcdir). Make
+ cvs-paper.pdf directly from cvs-paper.ms to avoid building it just
+ because cvs-paper.ps is missing.
+
+ * Makefile.am (EXTRA_DIST): Restore PDFs.
+ * cvs-paper.ps: Removed.
+
+2005-09-25 Derek Price <address@hidden>
+
+ * Makefile.am (doc): Finish removing PSs.
+
+ * Makefile.am (EXTRA_DIST): Remove PDFs too until errors go away.
+
+ * Makefile.am (EXTRA_DIST): Dist PDFs rather than PSs.
+
+2005-09-22 Larry Jones <address@hidden>
+
+ * cvs.texinfo (rdiff options): Document -k.
+ * cvs.1, stamp-vti, version.texi: Regenerated.
+
+2005-09-20 Larry Jones <address@hidden>
+
+ * cvs.texinfo: Move summary and detail contents to the front
+ where they belong.
+
+2005-09-14 Derek Price <address@hidden>
+
+ * Makefile.am: s#cvs.1#$(srcdir)/cvs.1#.
+
+2005-09-12 Derek Price <address@hidden>
+
+ * Makefile.am (stamp-gdt): Use texinfo, as opposed to C, comments in
+ the automatically generated getdate-cvs.texi file.
+
+2005-09-11 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Common options): Note that -r branch for a revision
+ means the head of the branch.
+
+2005-09-10 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Error messages): Add suggested messages.
+
+2005-09-09 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Error messages): Move out of sync message to correct
+ location and reword.
+ Clean up bad cross reference syntax.
+
+ * cvs.texinfo (Error messages): Add signal 11 message.
+
+2005-09-06 Derek Price <address@hidden>
+
+ * cvs.texinfo (config): Alphabetize list of keys.
+
+ * cvs.texinfo (Global options): Clarify -T description with temporary
+ file path precedence.
+ (config): Shorten TmpDir stuff and reference Global options node.
+ (Environment variables): Ditto for $TMPDIR. Remove $TMP and $TEMP. As
+ near as I can tell they are no longer used.
+
+2005-09-05 Derek Price <address@hidden>
+
+ * cvs.texinfo (config): Mention TmpDir first appeared in 1.12.13.
+
+ * cvs.texinfo (config): Describe new TmpDir option.
+
+2005-09-04 Derek Price <address@hidden>
+
+ * cvs.texinfo (config): Describe new [cvsroot] syntax.
+
+2005-09-01 Derek Price <address@hidden>
+
+ * cvs.texinfo: Update links and email addresses.
+
+2005-08-31 Derek Price <address@hidden>
+
+ * cvs.texinfo (CVS commands): Link to new node.
+ (server & pserver): New node.
+ (config): Note configurability of config file path.
+
+2005-08-29 Derek Price <address@hidden>
+
+ * cvs.texinfo (verifymsg): Describe new %{sV} format strings.
+
+2005-08-29 Derek Price <address@hidden>
+
+ * cvs.texinfo (From scratch): Add checkout to import example, from
+ wiki.
+
+2005-08-29 Derek Price <address@hidden>
+
+ * cvs.texinfo (Removing directories): Correct grammar, from wiki.
+
+2005-08-29 Derek Price <address@hidden>
+
+ * cvs.texinfo (From scratch): Clarify note on `cvs add', inspired from
+ wiki.
+
+2005-08-22 Derek Price <address@hidden>
+
+ Address bug #13882, submitted by Fred Maranhao.
+ * cvs.texinfo (log options, admin options, Invoking CVS): Add cross
+ references for clarity about possible states.
+
+2005-08-22 Derek Price <address@hidden>
+
+ * cvs.texinfo (Updating a file): Add note about update -d, inspired by
+ wiki.
+
+2005-08-12 Derek Price <address@hidden>
+
+ * cvs.texinfo (What is CVS?): Rephrase for clarity, imported from
+ Wiki.
+
+2005-08-02 Derek Price <address@hidden>
+
+ * cvs.texinfo (What is CVS?, BUGS): Correct grammar.
+
+2005-07-20 Derek Price <address@hidden>
+
+ * cvs.man.footer, cvs.texinfo, cvsclient.texi:
+ s/cvshome.org/nongnu.org.etc.../.
+
+2005-06-22 Derek Price <address@hidden>
+
+ * cvs.texinfo (Builds): Update Gunnar Tornblom's email at his request.
+
+2005-06-10 Derek Price <address@hidden>
+
+ * cvs.texinfo (loginfo, taginfo): Note new `T' format character in
+ {sTVv} list.
+
+2005-06-03 Derek Price <address@hidden>
+
+ * cvs.texinfo (Global options): Note -z *requests* a compression level.
+ (config): Describe MinCompressionLevel and MaxCompressionLevel.
+ * cvsclient.texi (Responses): Add `Force-gzip' request.
+ (Requests): Clarify `Gzip-stream' description.
+
+2005-06-01 Derek Price <address@hidden>
+
+ * cvs.texinfo (Connecting via rsh): Cross-reference method options and
+ don't capitalize `remsh' and `ssh' executable names.
+
+2005-05-23 Derek Price <address@hidden>
+
+ * getdate.texi: Update from GNULIB.
+
+2005-05-11 Derek Price <address@hidden>
+
+ * cvs.texinfo (history, history file, config): Add info on the new
+ HistoryLogPath and HistorySearchPath config options.
+
+2005-05-03 Derek Price <address@hidden>
+
+ * cvsclient.texi (Goals): Remove typo. Resolves cvshome issue #236.
+
+2005-05-03 Derek Price <address@hidden>
+
+ * cvs.texinfo (Creating a repository): Provide xref to the remote
+ repositries section. Resolves issue #203 on cvshome.org.
+
+2005-05-03 Derek Price <address@hidden>
+
+ * cvs.texinfo (Moving directories): Clarify instructions on renaming a
+ directory. Partially resolves issue #246 on cvshome.org.
+
+2005-05-03 Derek Price <address@hidden>
+
+ * cvs.texinfo (update output): Use "working directory" in place of
+ "source" for clarity. Closes issue #245 on cvshome.org.
+
+2005-04-22 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (Variables): Document SESSIONID and COMMITID
+ internal variables.
+
+2005-04-18 Derek Price <address@hidden>
+
+ * Makefile.am (EXTRA_DIST): Restore getdate-cvs.texi.
+ (DISTCLEAN): Remove same.
+ (getdate-cvs.texi): Move to...
+ ($(srcdir)/getdate-cvs.texi): ...here to avoid rebuild infos at
+ install.
+ (stamp-gdt): Generate $(srcdir)/getdate-cvs.texi.
+
+2005-04-15 Derek Price <address@hidden>
+
+ * mkman.pl: Minor changes to accomodate Perl 5.8.4. Improve
+ commenting.
+ ($nk, $ret, $debug): New globals.
+ (debug_print): New function.
+
+2005-04-14 Derek Price <address@hidden>
+
+ * cvs.texinfo (Administrative files): Rename "script hooks" node as
+ "Trigger Scripts".
+ (script hooks): Rename as...
+ (Trigger Scripts): ...this and add some clarifying text.
+ (Trigger Script Security): New node.
+ (-many *info nodes-): Rewrite to reference to Trigger Script node.
+ Add and/or rewrite index entries and cross-references.
+
+2005-04-07 Derek Price <address@hidden>
+
+ * Makefile.am: Make $(srcdir)/cvs.info, not cvs.info, dependent on
+ getdate-cvs.texi.
+
+2005-04-07 Derek Price <address@hidden>
+
+ * Makefile.am (stampt-gdt): Remove dependency on configure.
+
+2005-04-07 Derek Price <address@hidden>
+
+ * Makefile.am (DISTCLEANFILES): Move getdate-cvs.tmp to...
+ (MOSTLYCLEANFILES): ...here.
+
+2005-04-06 Derek Price <address@hidden>
+
+ * Makefile.am (cvs.1): Create intermediate file so that the original
+ isn't emptied on error.
+
+2005-03-29 Mark D. Baushke <address@hidden>
+
+ * mdate-sh, texinfo.tex: Update from GNULIB.
+
+2005-03-22 Mark D. Baushke <address@hidden>
+
+ * Makefile.in: Regenerated.
+
+2005-03-01 Derek Price <address@hidden>
+
+ Update installed GNULIB modules.
+ * getdate.texi: Update from GNULIB.
+
+2005-02-25 Derek Price <address@hidden>
+ for Frank Hemer <address@hidden>
+
+ * cvs.texinfo, RCSFILES: Describe commitid.
+
+2005-02-23 Derek Price <address@hidden>
+
+ * cvs.texinfo: Update many nodes to specify -r rev[:date] rather than
+ -r rev.
+
+2005-01-31 Derek Price <address@hidden>
+
+ * Makefile.am, cvs.man.header, cvs.texinfo: Update copyright notices.
+
+2005-01-29 Derek Price <address@hidden>
+
+ * cvs.texinfo (log options): Note quirky interaction of log options.
+ (Suggestion from Dan Peterson <address@hidden>.)
+
+2004-12-14 Derek Price <address@hidden>
+
+ * Makefile.am (EXTRA_DIST): Add HACKING.DOCS & writeproxy.rtf.
+ (SUBDIRS): Add i18n.
+
+2004-12-09 Derek Price <address@hidden>
+
+ * cvs.texinfo (Error messages): Note that old, val-tags, "no such tag"
+ problem has been fixed and expound.
+
+2004-12-09 Derek Price <address@hidden>
+
+ * cvs.texinfo (Remote repositories): Move method option data to...
+ (The connection method): ...this new node and rework.
+
+2004-12-09 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (BUGS, What is CVS?): Remove Dr. Pascal Molli's CVS
+ URL from the documentation.
+ * cvs.man.footer: Ditto.
+ * cvs.1, stamp-vti, version.texi: Regenerated.
+
+2004-12-03 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (Remote repositories): Add options CVS_RSH and
+ CVS_SERVER to the docs.
+ (Connecting via rsh): Ditto.
+ (getdate.texi): Replaced reference to getdate-cvs.texi file that
+ does not exist.
+ * stamp-1, stamp-vti, version-client.texi, version.texi:
+ Regenerated.
+
+2004-11-30 Derek Price <address@hidden>
+
+ * cvsclient.texi (Responses): Document the `Referrer' response.
+
+2004-11-29 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Keyword list): Add LocalKeyword and KeywordExpand.
+
+2004-11-29 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (Keyword list): LocalKeyword may only use the Id,
+ Header, and CVSHeader keywords at present, so document it.
+
+2004-11-29 Larry Jones <address@hidden>
+
+ * cvs.texinfo: s/KeywordExpansion/KeywordExpand/.
+
+2004-11-24 Derek Price <address@hidden>
+
+ * cvs.texinfo (Write proxies): Mention version limitations on primary
+ and secondary write proxies.
+ (Error messages): List secondary out of sync message.
+
+2004-11-17 Derek Price <address@hidden>
+
+ * getdate.texi: Update from GNULIB.
+
+2004-11-15 Derek Price <address@hidden>
+
+ * Makefile.am (stamp-gdt): Replace dependency on Makefile with
+ dependency on configure.
+
+2004-11-15 Derek Price <address@hidden>
+
+ * Makefile.am (EXTRA_DIST): s/getdate.text/getdate.texi/.
+
+2004-11-15 Derek Price <address@hidden>
+
+ * .cvsignore: Ignore intermediate cvs.vrs.
+
+2004-11-11 Derek Price <address@hidden>
+
+ * Makefile.am (cvs.dvi): Make dependent on getdate-cvs.texi.
+
+2004-11-01 Derek Price <address@hidden>
+
+ * .cvsignore: Add stamp-gdt & getdate-cvs.texi.
+ * Makefile.am (EXTRA_DIST): Distribute getdate.texi.
+ (getdate-cvs.texi, stamp-gdt): New targets.
+ (cvs.html, cvs.info, cvs.pdf, cvs.ps, cvs.txt): Depend on
+ getdate-cvs.texi.
+ * cvs.texinfo: Include getdate-cvs.texi.
+ (Common options): Reference new section rather than describing valid
+ dates.
+ * getdate.texi: New file from GNULIB.
+ * mkman.pl: Ignore include lines.
+
+2004-10-29 Derek Price <address@hidden>
+
+ * cvs.texinfo (Write proxies): Mention PrimaryServer name resolution.
+
+2004-10-29 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (Common options): The -r TAG option works with
+ the cvs annotate command.
+ (Original patch from Ville Skytta <address@hidden>.)
+
+2004-10-20 Mark D. Baushke <address@hidden>
+
+ * Makefile.in: Regenerate for new configure.in.
+
+2004-10-04 Derek Price <address@hidden>
+
+ * cvs.texinfo (assorted edit and commit related sections): Add
+ information about new '-c' and '-f' options for reservations
+ patch. The code (not documentation) for this feature was
+ originally from Noel Yap <address@hidden>, originally ported
+ forward and enhanced by Matthew Ogilvie <address@hidden>.)
+
+ * cvsclient.texi (Requests): Add "Hostname", "LocalDir", and "edit".
+ (Responses): Add "Edit-file".
+
+2004-10-04 Derek Price <address@hidden>
+
+ * cvs.texinfo (syntax): Note referrer format string.
+ * cvsclient.texi (Requests): Describe Referrer request.
+ (Responses): Note that a client should sent Referrer to the new server
+ after a Redirect.
+
+2004-10-01 Derek Price <address@hidden>
+
+ * cvs.texinfo (Write proxies, Global options): Detail operation of
+ global --allow-root option, Remove references to global --primary-root.
+
+2004-09-25 Derek Price <address@hidden>
+
+ * mkman.in: Move to...
+ * mkman.pl: ...here.
+ * Makefile.am (cvs.1): mkman is in build dir, not src dir.
+
+2004-09-24 Derek Price <address@hidden>
+
+ * Makefile.am (cvs.1): Add paths in hopes of getting more consistent
+ behavior.
+
+2004-09-14 Derek Price <address@hidden>
+
+ * cvs.texinfo (Keyword list, config): Note new config options and how
+ they effect the Log keyword.
+
+2004-08-17 Derek Price <address@hidden>
+
+ * cvsclient.texi (Requests): s/Command-prenotify/Command-prep/.
+
+2004-08-16 Derek Price <address@hidden>
+
+ * cvsclient.texi (Requests): Document the new `Command-prenotify'
+ request.
+ (Responses): Document the new `Redirect' response.
+
+2004-07-14 Derek Price <address@hidden>
+
+ * cvs.texinfo (Write proxies): Document recent changes in
+ implementation.
+
+2004-07-13 Derek Price <address@hidden>
+
+ * cvs.texinfo (script hooks/*): Tidy. Document new hooks as
+ implemented.
+
+2004-06-10 Derek Price <address@hidden>
+
+ * cvs.texinfo (config): Note that PrimaryServer hostname must match
+ that returned by uname on the primary server.
+
+2004-06-10 Derek Price <address@hidden>
+
+ * writeproxy.rtf: Update with latest modifications.
+
+2004-06-10 Derek Price <address@hidden>
+
+ * cvs.texinfo (Write proxies): Reference new script hooks.
+ (Administrative files): Move relevant parts of FIXME and references to
+ *info files...
+ (commit files): ...and most of the menu items from this node...
+ (script hooks): ...to this new node.
+ (postadmin, posttag, postwatch, preproxy, postproxy): New nodes.
+ (syntax, taginfo): Point at "script hooks" rather than
+ "Administrative files" node.
+
+2004-06-07 Derek Price <address@hidden>
+
+ * cvs.texinfo (Write proxies): New node.
+ (config): Note new PrimaryServer option.
+
+2004-06-04 Derek Price <address@hidden>
+
+ * writeproxy.rtf: Documentation for new writeproxy design.
+
+2004-07-13 Derek Price <address@hidden>
+
+ * cvs.texinfo (script hooks/*): Tidy. Document new hooks as
+ implemented.
+
+2004-06-10 Derek Price <address@hidden>
+
+ * cvs.texinfo (Write proxies): Reference new script hooks.
+ (Administrative files): Move relevant parts of FIXME and references to
+ *info files...
+ (commit files): ...and most of the menu items from this node...
+ (script hooks): ...to this new node.
+ (postadmin, posttag, postwatch): New nodes.
+ (syntax, taginfo): Point at "script hooks" rather than
+ "Administrative files" node.
+
+2004-07-17 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (config): Document ImportNewFilesToVendorBranchOnly
+ option.
+ (import options): Mention that ImportNewFilesToVendorBranchOnly
+ can force 'cvs import -X' behaviour for all imports.
+ (New feature from Chris Demetriou <address@hidden>.)
+
+2004-07-17 Derek Price <address@hidden>
+
+ * cvs.texinfo (Update imports, import): Add notes on requirement that
+ release tags be unique.
+ (Original patch from Ilya N. Golubev <address@hidden>.)
+
+2004-07-17 Derek Price <address@hidden>
+
+ * cvs.texinfo (Password authentication server): Added documentation for
+ the now required session configuration for PAM.
+ (Patch from Brian Murphy <address@hidden>.)
+
+2004-06-29 Derek Price <address@hidden>
+
+ * cvsclient.texi (Requests): Note new `Relative-directory request' as
+ well as new semantics for `Directory'.
+ (Response pathnames): Detail previously undocumented client
+ functionality with regards to pathnames specified in responses.
+
+2004-06-26 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (Vendor branch): Document that sometimes
+ the default branch won't be set to the vendor branch.
+ (import options): Add -X.
+ * cvsclient.texi (MT importmergecmd tag): Document that this
+ can also be used with the 'cvs import -X' command, and
+ that it can occur when there are no conflicts.
+ (New feature from Chris Demetriou <address@hidden>.)
+
+2004-06-21 Derek Price <address@hidden>
+
+ * cvs.texinfo (Password authentication server): Search for system user
+ rather than system password. Closes issue #185.
+ (Reported by Fred Maranhao <address@hidden>.)
+
+2004-06-10 Derek Price <address@hidden>
+
+ * cvs.texinfo (commit files): Remove reference to the obsolete -i
+ module option.
+
+2004-05-28 Derek Price <address@hidden>
+
+ * cvs.texinfo (Global options): Remove reference to global -l option.
+ (Report from Kevin Bulgrien <address@hidden>.)
+
+2004-05-19 Derek Price <address@hidden>
+
+ * cvs.texinfo (log): Updated since we display in local time now.
+ Also added some examples.
+ (Patch from Bart Robinson <address@hidden>.)
+
+ * cvs.1: Regenerated.
+
+2004-05-19 Derek Price <address@hidden>
+
+ * Makefile.am (cvs.1): Generate in $(srcdir).
+ (MAINTAINERCLEANFILES): Remove cvs.1.
+
+2004-05-14 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo: Fix makeinfo error.
+
+ * cvs.texinfo (Adding files): Cleanup example.
+ (Using keywords): Cleanup text.
+
+2004-05-13 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (Adding files): Minor cleanup.
+ (Using keywords): Minor cleanup.
+ (annotate): Move into the manual section, split into three nodes.
+ (annotate options): New node.
+ (annotate example): New node.
+ (based on patch from Steve McIntyre <address@hidden>.)
+ * cvs.1, stamp-1, stamp-vti, version-client.texi, version.texi:
+ Regenerated.
+
+2004-05-12 Derek Price <address@hidden>
+
+ * mkman.in: Clarify status messages.
+
+2004-05-12 Derek Price <address@hidden>
+
+ * cvs.texinfo (ls & rls): Document default behaviors.
+ (Patch from Alexander Taler <address@hidden>.)
+
+ * cvs.texinfo (ls & rls options): Document -d.
+ (Common options): Note ls & rls accept -R and note that they are the
+ sole exceptions it as a default.
+
+2004-05-10 Derek Price <address@hidden>
+
+ * mkman.in: Organize & tidy comments. Check for unprocessed texinfo
+ commands. Output better error messages on finding unprocessed texinfo
+ commands.
+ (do_keyword, keyword_mode): Accept $file argument for error messages.
+
+2004-05-06 Derek Price <address@hidden>
+
+ * mkman.in: Require Perl 5.005. Add comments. Remove duplicate s///.
+ Handle @:.
+
+2004-05-06 Derek Price <address@hidden>
+
+ * cvs.man.header: Minor text correction.
+ * mkman.in: Ignore @need keyword. Restore previous font for nested
+ keywords.
+ (do_keyword): Ditto on fonts. Move some functionality to...
+ (keyword_mode): ...this new function.
+
+2004-05-06 Derek Price <address@hidden>
+
+ * mkman.in: Handle keywords that cross multiple lines.
+ (do_keyword): New function.
+
+2004-05-04 Derek Price <address@hidden>
+
+ * cvs.man.header, cvs.man.footer: Reference `info CVS' rather than
+ `info cvs' to send users to the top node.
+
+2004-05-03 Derek Price <address@hidden>
+
+ * Makefile.am: mkman is built in the build dir, not $(srcdir).
+ (Report from Mark D. Baushke <address@hidden>.)
+
+2004-05-03 Derek Price <address@hidden>
+
+ * HACKING.DOCS: Fix spelling error. Add reference for @strong.
+ (Report from Mark D. Baushke <address@hidden>.)
+
+ * HACKING.DOCS: Note dependency on `makeinfo' 3.11 & greater.
+
+2004-04-30 Derek Price <address@hidden>
+
+ * mkman.in: Handle single quotes better. Parse out some redundancy
+ from node and section names.
+ * cvs.man.footer: Replace some quotes with the usual bold font.
+ Reformat links in the SEE ALSO section.
+ * cvs.1: Regenerated.
+
+2004-04-30 Derek Price <address@hidden>
+
+ * mkman.in: Handle examples better. Protect a few more characters.
+ * cvs.1, stamp-vti, version.texi: Regenerated.
+
+2004-04-30 Derek Price <address@hidden>
+
+ * cvs.man.header: Add copyright notice.
+ * cvs.1: Regenerated.
+
+2004-04-30 Derek Price <address@hidden>
+
+ * mkman.in: Add copyright and license notice.
+
+2004-04-30 Derek Price <address@hidden>
+
+ * mkman.in: Handle @@.
+ * cvs.1: Regenerated.
+
+2004-04-30 Derek Price <address@hidden>
+
+ First pass at closing issue #3 on cvshome.org.
+ * .cvsignore: Ignore mkman.
+ * cvs.1, mkman.in, cvs.man.header, cvs.man.footer: New files.
+ * cvs.texinfo: Add cut tags for mkman.
+ * Makefile.in (man_MANS): Add cvs.1.
+ (EXTRA_DIST): Add cvs.man.header & cvs.man.footer.
+ (cvs.1, mkman): New targets.
+ * Makefile.in: Regenerated.
+
+2004-04-27 Derek Price <address@hidden>
+
+ * stamp-1, version-client.texi: Regenerated.
+
+2004-04-27 Derek Price <address@hidden>
+
+ * cvs.texinfo (ls & rls options): Document new -P option.
+ * stamp-vti, version.texi: Regenerated.
+
+2004-04-23 Derek Price <address@hidden>
+
+ * cvsclient.texi (global-list-quiet): New request.
+
+2004-04-23 Derek Price <address@hidden>
+
+ * cvs.texinfo (ls, ls options, ls examples): Document
+ new ls command.
+ (Original patch from Mark D. Baushke <address@hidden>.)
+ * cvsclient.texi (list, ls, rlist): New requests.
+ * stamp-1, version-client.texi: Regenerated.
+
+2004-04-23 Derek Price <address@hidden>
+
+ * cvs.texinfo: Update years in Copyright.
+ * stamp-vti, version.texi: Regenerated.
+
+2004-04-21 Derek Price <address@hidden>
+
+ * cvs.texinfo: Use splitrcskeyword macro consistently in a failed
+ attempt to avoid a warning during PDF generation.
+ * stamp-vti, version.texi: Regenerated.
+
+2004-04-19 Derek Price <address@hidden>
+
+ * stamp-vti, version.texi: Regenerated.
+
+2004-04-18 Derek Price <address@hidden>
+
+ * cvs.texinfo: Various spelling, typo, and capitalization fixes.
+ (Patch from Ville Skyttä <address@hidden>.)
+
+2004-04-06 Derek Price <address@hidden>
+
+ * cvs.texinfo (Remote repositories): Describe how to use a web proxy to
+ contact a CVS server.
+ (GSSAPI authenticated): Use slightly clearer language.
+ (Kerberos authenticated): Remove incomplete note on server setup.
+ (Environment variables): Add CVS_PROXY_PORT.
+
+2004-04-06 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Assigning revisions): Note that client/server mode
+ only considers files sent to the server to determine the major
+ revision for new files.
+ (Reported by Krzysztof GORBIEL <address@hidden>.)
+ * stamp-vti, version.texi: Regenerated.
+
+2004-03-15 Derek Price <address@hidden>
+
+ * stamp-vti, version.texi: Regenerated.
+
+2004-03-15 Derek Price <address@hidden>
+
+ * cvs.texinfo: s/UseNewInfoFormatStrings/UseNewInfoFmtStrings/g.
+ (Reported by Matthew B. Doar <address@hidden>.)
+ * stamp-vti, version.texi: Regenerated.
+
+2004-03-11 Larry Jones <address@hidden>
+
+ * cvs.texinfo (loginfo, Error messages): Note that not reading all of
+ the log info can result in a broken pipe signal.
+ (Reported by Steven Nicoloso <address@hidden>.)
+ * stamp-vti, version.texi: Regenerated.
+
+2004-02-20 Derek Price <address@hidden>
+
+ * stamp-1, version-client.texi: Regenerated.
+
+2004-02-19 Derek Price <address@hidden>
+
+ * stamp-1, version-client.texi: Regenerated.
+
+2004-02-18 Derek Price <address@hidden>
+
+ * stamp-1, stamp-vti, version-client.texi, version.texi: Regenerated.
+
+2004-02-17 Derek Price <address@hidden>
+
+ * cvs.texinfo (syntax, updating commit files, commitinfo,
+ verifymsg, loginfo, taginfo, user-defined logging):
+ Document new format strings.
+ * stamp-1, stamp-vti, version-client.texi, version.texi: Regenerated.
+
+2004-02-15 Derek Price <address@hidden>
+
+ * stamp-1, stamp-vti, version-client.texi, version.texi: Regenerated.
+
+2004-02-04 Derek Price <address@hidden>
+
+ * cvs.texinfo (File Permissions): Clarify index entry.
+ * stamp-vti, version.texi: Regenerated.
+
+2004-01-22 Derek Price <address@hidden>
+
+ * stamp-vti, version.texi: Regenerated.
+
+2004-01-08 Larry Jones <address@hidden>
+
+ * cvs.texinfo (user-defined logging): Move taginfo stuff from here...
+ (Administrative files): ...to its own node under here.
+
+2003-12-18 Derek Price <address@hidden>
+
+ * stamp-1, stamp-vti, version-client.texi, version.texi: Regenerated
+ for dev 1.12.5.1.
+
+2003-12-18 Derek Price <address@hidden>
+
+ * stamp-1, stamp-vti, version-client.texi, version.texi: Regenerated
+ for release 1.12.5.
+
+2003-12-09 Derek Price <address@hidden>
+
+ * stamp-1, stamp-vti, version-client.texi, version.texi: Regenerated
+ for release 1.12.4.1.
+
+2003-12-09 Derek Price <address@hidden>
+
+ * cvs.texinfo (Locks): Provide technical details for promotable
+ readlocks.
+
+2003-12-09 Derek Price <address@hidden>
+
+ * stamp-vti, version.texi: Regenerated.
+
+2003-12-05 Derek Price <address@hidden>
+
+ * stamp-1, stamp-vti, version-client.texi, version.texi: Regenerated
+ for dev version 1.12.3.1.
+
+2003-12-04 Derek Price <address@hidden>
+
+ * stamp-1, stamp-vti, version-client.texi, version.texi: Regenerated
+ for release 1.12.3.
+
+2003-11-26 Derek Price <address@hidden>
+
+ * stamp-vti, version.texi: Regenerated.
+
+2003-11-25 Mark D. Baushke <address@hidden>
+
+ * Makefile.in: Regenerate for new configure.in.
+
+2003-11-18 Derek Price <address@hidden>
+
+ * stamp-vti, version.texi: Regenerated.
+
+2003-11-13 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Reverting local changes): Use the same vendor tag
+ in the admin command as was used in the previous import commands.
+
+2003-11-10 Derek Price <address@hidden>
+
+ * stamp-vti, version.texi: Regenerated.
+
+2003-11-07 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (CVS commands): Fix typo.
+ (FreeBSD PR docs/58669 reported by Ceri Davies <address@hidden>.)
+
+2003-10-30 Derek Price <address@hidden>
+
+ * stamp-vti, version.texi: Regenerated.
+
+2003-10-30 Derek Price <address@hidden>
+
+ * cvs.texinfo (File permissions, Error messages): Add index entries for
+ CVSROOT/val-tags file.
+
+2003-10-27 Derek Price <address@hidden>
+
+ * stamp-1, stamp-vti, version-client.texi, version.texi: Regenerated
+ for 1.12.2.1.
+
+2003-10-27 Derek Price <address@hidden>
+
+ * stamp-1, stamp-vti, version-client.texi, version.texi: Regenerated
+ for 1.12.2.
+
+2003-10-21 Derek Price <address@hidden>
+
+ * cvs.texinfo: Note gnu.cvs.* usenet mirrors of the email lists.
+ (Suggestion from Paul Edwards, from somewhere in Australia.)
+
+ * cvs.texinfo: Put email addresses in @email{} tags and URLs in @url{}
+ tags rather than relying on markup like @code{}.
+ * stamp-vti, version.texi: Regenerated.
+
+2003-10-14 Derek Price <address@hidden>
+
+ Port to pedantic POSIX 1003.1-2001 hosts, such as Debian GNU/Linux
+ testing with _POSIX2_VERSION=200112 in the environment.
+
+ * cvs.texinfo: Suggest 'sed 1q', not 'head -1'.
+ (Patch from Paul Eggert <address@hidden>.)
+
+2003-10-08 Derek Price <address@hidden>
+
+ * cvsclient.texi (Requests): Add recommendation to client developers to
+ avoid the `Case' request.
+ * stamp-1, version-client.texi: Regenerated.
+
+2003-10-03 Derek Price <address@hidden>
+
+ * stamp-vti, version.texi: Regenerated.
+
+2003-09-12 Derek Price <address@hidden>
+
+ * cvs.texinfo (checkoutlist): Document the error messages which may be
+ specified in this file.
+ * stamp-vti, version.texi: Regenerated.
+
+2003-08-29 Derek Price <address@hidden>
+
+ * cvs.texinfo (Administrative files, Commit files): Remove references
+ to deleted nodes.
+ (editinfo, editinfo example): Remove these obsolete nodes.
+ * stamp-vti, version.texi: Regenerated.
+
+2003-08-27 Larry Jones <address@hidden>
+
+ * cvs.texinfo (history options): Note the 'P' record type which
+ has been around for a long time but never actually appeared in
+ the history file due to bugs in the code.
+ (Invoking CVS): Ditto.
+ (config): Ditto.
+ * stamp-vti, version.texi: Regenerated.
+
+2003-08-12 Derek Price <address@hidden>
+
+ * stamp-vti, version.texi: Regenerated.
+
+2003-08-07 Derek Price <address@hidden>
+
+ * .cvsignore: Ignore {cvs,cvsclient}.txt.
+
+2003-08-07 Derek Price <address@hidden>
+
+ * cvs.texinfo: Use the @dircategory and @direntry commands from texinfo
+ rather than rolling our own.
+
+ * stamp-vti, version.texi: Regenerated.
+
+2003-08-07 Derek Price <address@hidden>
+
+ * Makefile.am (POSTSCRIPTS): Rename to...
+ (PSS): ...to sync with and override Automakes default targets.
+ (PDFS): Reorder to match PSS.
+ (SUFFIXES): Remove .pdf and .aux.
+ (cvs.aux, cvs.pdf, cvsclient.aux, cvsclient.pdf): Remove these targets.
+ .aux weren't being generated anyhow and .pdf no longer need to be
+ supplied explicitly.
+ (cvs-paper.pdf: cvs-paper.ps): Provide ps2pdf rule explicitly.
+ (.{texinfo,texi,txy}.pdf): Remove these suffix rules - they are now
+ provided by Automake.
+
+2003-08-06 Derek Price <address@hidden>
+
+ * Makefile.am (CLEANFILES): Move...
+ (MOSTLYCLEANFILES): ...here and drop PDFs since this is where Automake
+ cleans PDFs & PSs by default.
+ (MAINTAINERCLEANFILES): Clean all PostScripts even though they will
+ have been removed in mostlyclean. That is a bug in Automake.
+ (doc): Depend on info & ps.
+ (pdf, ps): Removed in favor of Automake's default targets for these
+ types.
+ (cvsclient.* targets): Depened on version-client.texi.
+ (cvs-paper.pdf): Remove in favor of Automake's default target.
+ (.{texinfo,texi,txi}.{pdf,txt}): Update these targets based on
+ Automake's similar treatment of dvi, ps, and info targets.
+ * .cvsignore: Add cvs.tmp, a `make pdf' generated file.
+
+ * Makefile.in: Regenerated.
+
+2003-07-21 Derek Price <address@hidden>
+
+ * cvs.texinfo: Expand comment on RCS terminology.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-07-20 Derek Price <address@hidden>
+
+ * cvs.texinfo (Setting up the server for password authentication):
+ Added documentation for PAM support.
+ (Original patch from Brian Murphy <address@hidden>.)
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-07-18 Derek Price <address@hidden>
+
+ * cvs.texinfo (Substitution modes): Improve the phrasing of the
+ description of the new treatment of -kb.
+
+2003-07-18 Derek Price <address@hidden>
+
+ * cvs.texinfo: Put a few errant references to bug-cvs inside @code{}
+ for consistancy.
+
+2003-07-18 Derek Price <address@hidden>
+
+ * cvs.texinfo: Update WARNINGs and Notes for a more consistent
+ appearance. Remove some obsolete comments.
+
+2003-07-18 Derek Price <address@hidden>
+
+ * cvs.texinfo (Merging and keywords): Note that keyword expansion modes
+ requested on the command line no longer override binary mode. Removed
+ an obsoleted @ignore section.
+ (Common options): Ditto minus the @ignore section. Some reworking for
+ clarity.
+ (Original patch from Dieter Maurer <address@hidden>.)
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-07-12 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Binary howto): Add note about how to determine whether
+ a file is marked as binary or not.
+ (Suggested by Erik Sigra <address@hidden>.)
+ * stamp-vti: Regenerated.
+ * version.texi: Regenerated.
+
+2003-06-23 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-06-20 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-06-16 Derek Price <address@hidden>
+
+ * cvs.texinfo (splitrcskeyword): New macro, now that @ifhtml will work
+ properly with texi2html (as of version 1.68), to cause output HTML to
+ contain <i></i> where we used to have @asis{} and prevent RCS keyword
+ substitution in generated HTML.
+ (Original patch from Patrice Dumas <address@hidden>.)
+
+2003-06-16 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-06-13 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-06-12 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-06-11 Derek Price <address@hidden>
+
+ * cvs.texinfo (Invoking CVS): Remove `-P' from the list of `cvs export'
+ options.
+ (Patch from Alexander Taler <address@hidden>.)
+
+2003-06-11 Derek Price <address@hidden>
+
+ * cvs.texinfo (Top): Remove out-of-date (by at least 5 years) comment.
+ (Patch from Alexander Taler <address@hidden>.)
+
+2003-06-11 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (Keyword list): Fix broken reference.
+ (Avoiding substitution): Ditto.
+
+2003-06-11 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-06-11 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated for new configure.in.
+ * stamp-vti: Ditto.
+ * version.texi: Ditto.
+
+2003-06-10 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (Keyword substitution): New menu entry for
+ "Configuring keyword expansion."
+ (Keyword list): New "CVSHeader" keyword. New Local keyword
+ controlled by new LocalKeyword option in CVSROOT/config.
+ (Avoiding substitution): Mention the new KeywordExpansion option
+ in CVSROOT/config.
+ (Configuring keyword expansion): Document the new KeywordExpansion
+ option in CVSROOT/config.
+ (Invoking CVS): New example of CVSHeader keyword expansion.
+
+2003-05-27 Derek Price <address@hidden>
+
+ * cvs.texinfo: Consolidate copyright notices into a single macro that
+ is called elsewhere to avoid needing three of them. Update copyright
+ notice.
+ (BUGS): Suggest Ximbiot rather than the defunct Signum Support as CVS
+ consultants.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-05-26 Derek Price <address@hidden>
+
+ * stamp-1: Regenerated for 1.12.1.1.
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2003-05-25 Derek Price <address@hidden>
+
+ * stamp-1: Regenerated for 1.12.1.
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2003-05-21 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerate with Automake version 1.7.5.
+
+2003-05-20 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated.
+
+2003-05-19 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-05-09 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated.
+
+2003-05-06 Derek Price <address@hidden>
+
+ * cvs.texinfo (Specifying what to tag by date or revision): Add a
+ missing a tag argument to the example.
+ (How your build system interacts with CVS): Correct typo.
+ (*): Let the spell checker have its way.
+ (Thanks to Anthon Pang <address@hidden> for the patch and
+ Max Bowsher <address@hidden> for validating it. This closes issue #84 on
+ <http://ccvs.cvshome.org>.)
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-04-30 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated.
+
+2003-04-28 Derek Price <address@hidden>
+
+ * cvs.texinfo (Working directory storage, Module options, Module
+ program options): Remove references to Checkin.prog and Update.prog.
+ (commit options): Remove reference to -n option.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-04-10 Larry Jones <address@hidden>
+
+ * Makefile.in: Regenerated.
+
+2003-03-31 Derek Price <address@hidden>
+
+ * cvs.texinfo (import output): Remove unecesary verbage.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-03-26 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-03-25 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Server temporary directory): Reorder list of places
+ to match code.
+ (Connection): Add additional example error message and note about
+ firewall software.
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-03-25 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-03-24 Derek Price <address@hidden>
+
+ * Makefile.am: Update copyright notice.
+
+ * Makefile.in: Regenerated.
+
+2003-03-21 Derek Price <address@hidden>
+
+ * cvs.texinfo (Environment variables): Move @end table tag to after
+ the @item $CVSPID.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-03-19 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (Connecting via rsh): Document that --with-rsh may
+ be used to specify the default "rsh" program to use.
+
+ * Makefile.in: Regenerated.
+
+ * cvs.texinfo (Environment variables): Document new CVS_PID
+ variable.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-03-19 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated.
+
+2003-03-19 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-03-16 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (Global options): Document new `-R' global option
+ for read-only file-system repository mode.
+ (Environment variables): Document new CVSREADONLYFS environment
+ variable.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-03-07 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (rcsinfo): Document that CVS/Template will now be
+ updated during normal cvs update operations.
+
+2003-03-06 Derek Price <address@hidden>
+
+ * cvs.texinfo (What is CVS?): Correct date of first post of CVS by
+ Dick Grune from December to July based on the archive posted on
+ Google:
+
<http://groups.google.com/groups?q=Grune+cvs+group:mod.sources.*&hl=en&lr=&ie=UTF-8&selm=122%40mirror.UUCP&rnum=2>.
+ (Thanks to David A Wheeler <address@hidden>.)
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-03-03 Mark D. Baushke <address@hidden>
+
+ * cvs.texinfo (CVS_LOCAL_BRANCH_NUM): Document new environment
+ variable.
+
+2003-02-27 Derek Price <address@hidden>
+
+ * cvs.texinfo (Environment variables): Make the information on
+ CVS_CLIENT_PORT slightly clearer.
+ (Kerberos authenticated): XREF the Environment variables node.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-02-25 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated.
+ * stamp-1: Ditto.
+ * version-client.texi: Ditto.
+
+2003-02-25 Derek Price <address@hidden>
+
+ * cvs.texinfo (admin): Mention UserAdminOptions.
+ (config): Ditto.
+ (Original patch from Dan Peterson <address@hidden>.)
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-02-24 Derek Price <address@hidden>
+
+ * cvs.texinfo (*): Modify some tag index entries for uniformity.
+
+2003-02-14 Derek Price <address@hidden>
+
+ * cvs.texinfo (Watch Information, Editing files, Getting Notified,
+ Setting a watch): Edit usage specs for correctness and uniformity.
+ (Sticky tags): Use ref rather than xref to avoid a warning from
+ makeinfo.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-02-10 Derek Price <address@hidden>
+
+ * cvs.texinfo (Sticky tags, update): Make merging behavior of
+ `cvs update' a bit clearer. Add cross references.
+ (Thanks to Jenn Vesperman <address@hidden> for the
+ report.)
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-02-07 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2003-02-06 Derek Price <address@hidden>
+
+ * cvs.texinfo (Common options): Add tag to the list of commands that
+ accept -D.
+
+2003-02-06 Derek Price <address@hidden>
+
+ * cvs.texinfo (Working directory storage, Module options,
+ Module program options): Correct description of where Checkin.prog
+ and Update.prog are run. Provide more index entries and cross
+ references. Remove some FIXME comments. Add a FIXCVS THEN FIXME.
+ (Thanks to Art Manion at the CERT Coordination Center <address@hidden>.)
+
+2003-02-04 Derek Price <address@hidden>
+
+ * cvs.texinfo (File status): Mention the "Unresolved Conflict" status
+ which was apparently and erroneously removed from the doc at some
+ point in the past.
+
+2003-02-03 Derek Price <address@hidden>
+
+ * cvs.texinfo (Merging a branch): Mention the GCA as opposed to the
+ "branch point" as the implicit revision when merging a branch.
+
+2003-02-03 Derek Price <address@hidden>
+
+ * cvs.texinfo (Remote repositories): :METHOD: is optional.
+
+2003-02-03 Derek Price <address@hidden>
+
+ * cvs.texinfo (Committing your changes): Move index entries closer to
+ their corresponding references.
+ (Environment variables): Include $VISUAL in order of
+ preference. Add index entries. Reference Global options node.
+ (Variables): Change order of list to match the Env. Variables node
+ mentioned above.
+
+ * stamp-1: Regenerated.
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2003-01-31 Derek Price <address@hidden>
+
+ * stamp-1: Regenerated.
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2003-01-23 Derek Price <address@hidden>
+
+ * stamp-1: Regenerated.
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2003-01-22 Larry Jones <address@hidden>
+
+ * cvs.texinfo (config): Correct LogHistory default (U was omitted).
+
+2003-01-16 Derek Price <address@hidden>
+
+ * stamp-1: Regenerated for version (1.11.5).
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2003-01-16 Derek Price <address@hidden>
+
+ * stamp-1: Regenerated for dev version (1.11.4.1).
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2002-12-28 Derek Price <address@hidden>
+
+ * stamp-1: Regenerated for version 1.11.4.
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2002-12-27 Derek Price <address@hidden>
+
+ * stamp-1: Regenerated for dev version 1.11.3.1.
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2002-12-27 Derek Price <address@hidden>
+
+ * stamp-1: Regenerated.
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2002-11-18 Derek Price <address@hidden>
+
+ * cvs.texinfo (commitinfo): Explain the environment of commands
+ run by commitinfo a little more fully.
+ (Original patch from Fred L. Drake, Jr. <address@hidden>.)
+
+ * cvs.texinfo: Change the wording of some of the commit index entries
+ for consistency and clarity.
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2002-09-24 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated using Automake 1.6.3.
+
+2002-09-24 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated.
+
+2002-09-20 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2002-08-16 Derek Price <address@hidden>
+
+ * cvs.texinfo (Error messages): Update CVS_BADROOT notes to specify
+ new configure option instead.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2002-08-12 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2002-08-06 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2002-08-05 Derek Price <address@hidden>
+
+ * cvs.texinfo: Correct typo.
+ (Thanks to Chandra Mouleeswaran <address@hidden>.)
+
+2002-04-30 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated with automake 1.6.
+
+2002-04-18 Derek Price <address@hidden>
+
+ * Makefile.am: Add FIXME comment about an automake bug.
+ * Makefile.in: Regenerated.
+
+2002-04-18 Derek Price <address@hidden>
+
+ * stamp-1: Regenerated for 1.11.2.1 version update.
+ * stamp-vti: Ditto.
+ * version-client.texi: Ditto.
+ * version.texi: Ditto.
+
+2002-04-17 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2002-04-17 Derek Price <address@hidden>
+
+ * cvs.texinfo: Add index entries for inetd and xinetd.
+
+2002-03-26 Derek Price <address@hidden>
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2002-03-17 Larry Jones <address@hidden>
+
+ * cvs.texinfo (log options): Add new -S option.
+
+2002-03-12 Larry Jones <address@hidden>
+
+ * cvs.texinfo (diff options): Add missing menu for new subsections.
+ (Patch from Pavel Roskin <address@hidden>.)
+
+2002-03-09 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Update imports): Suggest merging with two rel tags
+ instead of the branch tag and a date and explain why.
+
+2002-02-26 Larry Jones <address@hidden>
+
+ * cvs.texinfo (diff options): Document all the diff options.
+
+2002-01-10 Larry Jones <address@hidden>
+
+ * cvs.texinfo (log options): Update -r :: to match code changes.
+ (Variables): Document LOGNAME and USER environment variables.
+
+2001-12-03 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Invoking CVS): Add -F option for annotate and
+ rannotate.
+
+2001-11-28 Larry Jones <address@hidden>
+
+ * cvs.texinfo (File permissions): Add note about SGID being required
+ on some systems. Add note about LockDir.
+
+2001-10-18 Derek Price <address@hidden>
+
+ * Makefile.am: Add --batch to texi2dvi invocations.
+ (Thanks to Akim Demaille <address@hidden> for the suggestion.)
+
+ * Makefile.in: Regenerated.
+
+2001-10-04 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Connecting via rsh): Add : between host name and
+ root directory in example since some versions of CVS require it.
+ (Reported by Trevor Jim <address@hidden>.)
+
+2001-09-14 Larry Jones <address@hidden>
+
+ * cvs.texinfo (commit files): Make following sections (commitinfo,
+ verifymsg, editinfo, and loginfo) subsections of this one.
+
+2001-09-06 Derek Price <address@hidden>
+
+ * cvs.texinfo (Watch information): Cleanup some watch/edit
+ explanations and discourage the belief that files should be
+ releasable.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+ (Patch from Eric Siegerman <address@hidden>.)
+
+2001-09-05 Derek Price <address@hidden>
+
+ * cvsclient.texi: Use version-client.texi instead of version.texi so
+ cvsclient.* can have a different build date than cvs.texinfo.
+
+ * Makefile.in: Regenerated.
+ * stamp-1: New file.
+ * version-client.texi: Ditto.
+ (Reported by Alexey Mahotkin <address@hidden>.)
+
+2001-09-04 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated with automake 1.5.
+ * version.texi: Ditto.
+
+2001-08-24 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Error messages): Add new message about root not
+ being allowed to do commit.
+
+2001-08-24 Derek Price <address@hidden>
+
+ * cvs.texinfo (config): Add a new RereadLogAfterVerify
+ CVSROOT/config option to control how verifymsg scripts deal with
+ read-write log messages.
+ (Patch from Mark D. Baushke <address@hidden>.)
+
+ * cvs.texinfo (verifymsg): The verification script may now modify
+ the log message.
+ (Patch from Mark D. Baushke <address@hidden>.)
+
+ * cvs.texinfo (config, verifymsg): Correct default, changes for clarity,
+ and add a warning about `stat' and large repositories.
+
+ * version.texi: Regenerated.
+ * stamp-vti: Ditto.
+
+2001-08-20 Derek Price <address@hidden>
+
+ * Makefile.am: Reformat comment for 80 chars.
+
+ * Makefile.in: Regenerated.
+
+2001-08-10 Derek Price <address@hidden>
+
+ * cvs.texinfo (Default options and the ~/.cvsrc file): Added a few more
+ "standard" options to the example.
+
+ * stamp-vti: Regenerated.
+ * version.texi: Ditto.
+
+2001-08-06 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated.
+
+2001-07-17 Derek Price <address@hidden>
+
+ * version.texi: Regenerated.
+ * stamp-vti: Ditto.
+
+2001-07-06 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Variables): Add index entry for CVS_USER.
+ (Reported by Jens Schweikhardt <address@hidden>.)
+ (Working directory storage): Fix Emptydir index entry: Emptydir
+ is a directory, not a file.
+
+2001-07-05 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Working directory storage): Add Emptydir to index.
+
+2001-07-04 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated with new Automake release candidate 1.4h.
+
+2001-06-28 Derek Price <address@hidden>
+
+ * Makefile.am: Reference to CVSvn.texi removed.
+ * cvs.texinfo: @include version.texi and change CVSVN to VERSION.
+ * cvsclient.texi: Ditto.
+
+ * version.texi: New file.
+ * stamp-vti: Ditto.
+ * mdate-sh: New File. Work-around bug in Automake 1.4f by copying
+ top-level mdate-sh here.
+
+ * CVSvn.texi.in: Removed.
+ * CVSvn.texi: Ditto.
+
+ * Makefile.in: Regenerated.
+ (Patch from Alexey Mahotkin <address@hidden>.)
+
+2001-06-27 Larry Jones <address@hidden>
+
+ * cvs.texinfo (loginfo): Note that format string expansion is
+ quoted and contains escapes.
+
+2001-06-22 Derek Price <address@hidden>
+
+ * cvs.texinfo (checkout options): Fix transliteration typo in co
+ example.
+ (Patch from Adrian Aichner <address@hidden>.)
+
+2001-06-12 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Global options): Note that -T only affects the local
+ process in client/server mode.
+ (Environment variables): Note that CVS_SERVER can include arguments
+ as well as a program name, and note that it applies to :fork: as well
+ as to :ext: and :server:, although the default value is different.
+
+2001-06-08 Larry Jones <address@hidden>
+
+ * cvs.texinfo (config): Mention using LockDir on in-memory
+ filesystem to speed up locking.
+
+2001-06-07 Derek Price <address@hidden>
+
+ * Makefile.am (EXTRA_DIST): Remove *.aux.
+ (MOSTLYCLEAN_FILES): Remove this macro since the Automake bug it was
+ working around has been fixed.
+
+2001-06-07 Derek Price <address@hidden>
+
+ * HACKING.DOCS: Add link to the main texinfo documentation.
+
+2001-06-07 Derek Price <address@hidden>
+
+ * README.DOCS: Rename to
+ * HACKING.DOCS: this.
+
+2001-06-07 Derek Price <address@hidden>
+
+ * README.DOCS: New file attempting to document some of our texinfo
+ conventions.
+
+2001-06-06 Derek Price <address@hidden>
+
+ (Reformatting, rewording, & additions to a patch from
+ Stephen Cameron <address@hidden>.)
+
+ * cvs.texinfo (Invoking cvs, Modifying tags)
+ document new -B option of rtag and tag commands.
+
+2001-06-04 Derek Price <address@hidden>
+
+ * Makefile.am: Remove commented out DISTFILES &
+ AUTOMAKE_OPTIONS=no-texinfo.tex.
+ (Reported by Alexey Mahotkin <address@hidden>.)
+ * Makefile.in: Regenerated.
+
+2001-06-04 Larry Jones <address@hidden>
+
+ * Makefile.am: Fix rules for cvs-paper (.pdf rule actually generated
+ .ps and vice versa).
+ (Reported by Alexey Mahotkin <address@hidden>.)
+ * Makefile.in: Regenerated.
+
+2001-05-29 Derek Price <address@hidden>
+
+ * cvs.texinfo (Repository): Fix explanation of CVSROOT parsing
+ algorithm.
+
+2001-05-29 Derek Price <address@hidden>
+ patch from Pavel Roskin <address@hidden>
+
+ * Makefile.am (CVSvn.texi): Double hash comment in rule since single
+ hash comments are not portable.
+
+ * Makefile.in: Regenerated.
+
+2001-05-21 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Error messages): Fix ordering; add "cannot commit
+ files as root".
+
+ * cvs.texinfo (Invoking CVS): Add entries for kserver, pserver,
+ rannotate, rlog, and server.
+
+ * cvs.texinfo: Lots of minor editorial corrections. Mostly adding
+ @noindent after examples where the following text is intended to
+ be a continuation of the preceding text, not a new paragraph.
+
+ * cvs.texinfo (Connection): Replace information about unsetting
+ $HOME for people with old releases.
+
+
+ * cvs.texinfo (Connecting via rsh): Use @samp{} instead of @file{}
+ where it seemed appropriate.
+ (Patch from Alexey Mahotkin <address@hidden>).
+
+2001-05-18 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Password authentication server): Add xinetd info.
+ (Connection): Add "broken pipe" to possible error messages.
+
+2001-05-18 Derek Price <address@hidden>
+
+ * cvs.texinfo (update output): Change wording to something that sounds
+ a bit more like english.
+
+2001-05-02 Derek Price <address@hidden>
+
+ * cvs.texinfo (Top): Change @ifinfo to @ifnottex to placate HTML
+ generators.
+
+2001-04-27 Derek Price <address@hidden>
+
+ * CVSvn.texi: Regenerated.
+
+2001-04-27 Derek Price <address@hidden>
+
+ * CVSvn.texi: Regenerated.
+
+2001-04-25 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated using AM 1.4e as of today at 18:10 -0400.
+ * CVSvn.texi: Regenerated.
+
+2001-03-30 Larry Jones <address@hidden>
+
+ * cvsclient.texi (Dates, Requests): Add rannotate and rlog.
+
+2001-03-26 Larry Jones <address@hidden>
+
+ * cvs.texinfo (admin options): Fix typo: should be @pxref, not @xref.
+
+2001-03-26 Larry Jones <address@hidden>
+
+ * cvs.texinfo (admin options): Update description of -u option to
+ refer back to notify.
+
+2001-03-23 Derek Price <address@hidden>
+
+ * Makefile.am (ps): Make 'ps' an alias for 'doc'.
+ (doc, pdf, ps, txt): declare as '.PHONY'.
+
+ * Makefile.in: Regenerated.
+
+2001-03-23 Derek Price <address@hidden>
+
+ * Makefile.am (MOSTLYCLEANFILES): Add cvs.cps & cvs.fns as a temporary
+ workaround for an Automake deficiency.
+
+ * Makefile.in: Regenerated.
+
+2001-03-14 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated
+
+2001-02-20 Larry Jones <address@hidden>
+
+ * cvs.texinfo (BUGS): There's only one company listed now, not two.
+
+2001-02-13 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Password authentication server, First import): Use
+ @ref instead of @xref when not at the beginning of a sentence.
+
+2001-02-01 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Connection): Add still more notes about common
+ pserver error messages.
+
+2001-01-18 Derek Price <address@hidden>
+
+ * cvs.texinfo (Quick reference to CVS commands): add index entry for
+ version subcommand
+
+2001-01-18 Larry Jones <address@hidden>
+
+ * cvs.texinfo (log options): Document new :: syntax for -r.
+
+2001-01-10 Derek Price <address@hidden>
+
+ * Makefile.am (CVSvn.texi): specify $(srcdir) explicitly in target rule
+ so CVSvn.texi gets built properly for all makes.
+ (cvs_TEXINFOS): specify $(srcdir) explicitly for CVSvn.texi
+ (cvsclient_TEXINFOS): ditto
+ * Makefile.in: regenerated
+
+2000-12-26 Derek Price <address@hidden>
+
+ * Makefile.in: update timestamp
+ * CVSvn.texi: ditto
+
+2000-12-26 Derek Price <address@hidden>
+
+ * Makefile.am: new target for creation of CVSvn.texi
+ (EXTRA_DIST): add CVSvn.texi.in & CVSvn.texi
+ * Makefile.in: Regenerated
+ * CVSvn.texi: new file
+ * .cvsignore: remove CVSvn.texi since it is now included in dist
+
+2000-12-22 Derek Price <address@hidden>
+
+ * Makefile.in: Regenerated
+
+2000-12-21 Derek Price <address@hidden>
+
+ * cvs-paper.ps: Backout accidental regeneration.
+
+2000-12-21 Derek Price <address@hidden>
+
+ * .cvsignore: Added *.pdf versions of the *.ps docs
+ * CVSvn.texi.in: Use configure to generate CVSvn.texi
+ * Makefile.am: New file needed by Automake
+ * Makefile.in: Regenerated
+ * cvs-paper.ps: Regenerated
+ * texinfo.tex: New file added to placate Automake. Apparently, its
+ inclusion is mandated by the GNU coding standards.
+
+2000-12-14 Derek Price <address@hidden>
+ Linus Tolke <address@hidden>
+
+ * cvs.texinfo (Merging a branch): changed some references to "BRANCH"
+ to "BRANCHNAME" for consistancy. Add a warning about merging using a
+ single tagname reference with an xref to "Merging adds and removals"
+ for the long explanation
+ (Merging adds and removals): Add the long explanation of why merging
+ from a single tagname can be tricky
+ (update): Add a warning about merging using a single tagname reference
+ with an xref to "Merging adds and removals" for the long explanation
+
+2000-11-13 Derek Price <address@hidden>
+
+ * cvs.texinfo: use '@sc{cvs}' instead of 'CVS' in various locations
+
+2000-11-08 Derek Price <address@hidden>
+
+ * cvs.texinfo (settitle): stick a 'v' in front of the version number
+ to make it harder to confuse with chapter, section, and page numbers.
+
+2000-11-08 Derek Price <address@hidden>
+
+ * cvs.texinfo (settitle): add the version number to the title string
+ so that it is easier to find on HTML pages and the like.
+
+2000-10-20 Jim Kingdon <http://sourceforge.net/users/kingdon/>
+
+ * cvs.texinfo (Variables): Document CVS_USER.
+
+2000-10-17 Derek Price <address@hidden>
+
+ * cvs.texinfo (Remote repositories): added a comment about specifying
+ a password in the repository name when performaing a checkout.
+
+2000-10-17 Derek Price <address@hidden>
+
+ * cvs.texinfo (Remote repositories, password authenticated, GSSAPI
+ authenticated, Kerberos authenticated, Environment variables):
+ Documented CVSROOT spec change & CVS_CLIENT_PORT.
+
+2000-10-10 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Connection): Add additional notes about common
+ pserver error messages. Remove information about unsetting $HOME
+ since CVS no longer pays any attention to it in server mode.
+
+2000-09-07 Larry Jones <address@hidden>
+
+ * Makefile.in: Use @bindir@, @libdir@, @infodir@, and @mandir@
+ from autoconf.
+
+2000-08-21 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Removing directories, export): Note that export always
+ prunes directories and remove references to the non-existent -P flag.
+
+2000-07-28 Larry Jones <address@hidden>
+
+ * cvsclient.texi (Requests): Ensure that all rootless requests say
+ that they're rootless.
+
+2000-07-12 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Module program options): Remove note that commit and
+ update programs only working locally; they've worked client/server
+ for quite some time.
+
+2000-07-10 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Invoking CVS): Document new version command.
+ * cvsclient.texi (Requests): Document new version request.
+
+2000-07-06 Larry Jones <address@hidden>
+
+ * cvs.texinfo (admin options): Remove note about -t not working
+ in client/server.
+
+2000-04-03 Pavel Roskin <address@hidden>
+
+ * cvs.texinfo (Telling CVS to notify you): Remove backslashes
+ before quotes.
+
+2000-05-24 Larry Jones <address@hidden>
+
+ * cvs.texinfo (From files): Clean up @var{wdir}/@var{rdir} vs.
+ @var{dir} usage.
+
+2000-05-19 Larry Jones <address@hidden>
+
+ * cvsclient.texi (Requests): Note that Global_option is now
+ valid without Root.
+
+2000-04-17 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Variables): Clarify what USER means in pserver.
+
+2000-03-08 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Connection): Add note about inetd rate limit.
+ (ErrorMessages): Add root home directory permission messages.
+
+2000-02-12 Larry Jones <address@hidden>
+
+ * cvs.texinfo: Clean up text/formatting of previous change.
+
+2000-02-21 K.J. Paradise <address@hidden>
+
+ * cvs.texinfo : Adding John Cavanaugh's patch to allow
+ the history file to log actions based on the CVSROOT/config
+ file. (To limit which cvs actions actually make it into the
+ history file)
+
+2000-02-17 Larry Jones <address@hidden>
+
+ * cvs.texinfo: Remove references to PreservePermissions.
+
+ * cvs.texinfo (history options): Note default report type.
+
+2000-01-18 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Global options): Document compression levels.
+
+2000-01-18 Larry Jones <address@hidden>
+
+ * cvs.texinfo: Minor editorial changes from Ken Foskey
+ <address@hidden>.
+
+2000-01-11 Larry Jones <address@hidden>
+
+ * cvs.texinfo: Add index entries for "Compression" and "Gzip".
+ Correct typography in many index entries (English phrases should
+ have initial caps, subcommands/files/etc. should be as-is).
+
+2000-01-10 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (loginfo): correctly describe CVSROOT/loginfo's
+ %-expansion behavior. Thanks to Karl Heinz Marbaise
+ <address@hidden> for noticing the error.
+
+2000-01-07 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Password authentication server): Use -f in example
+ inetd.conf line.
+ (Connection): Add advice about using shell script or env to avoid
+ problems with inetd setting HOME in the server's environment.
+ (various): Use @file for inetd.conf.
+
+2000-01-02 John P Cavanaugh <address@hidden>
+
+ * cvs.texinfo: document new -C option to update, now that it works
+ both remotely and locally.
+ (Re-applied by Karl Fogel <address@hidden>.)
+
+1999-12-11 Karl Fogel <address@hidden>
+
+ * Revert previous change -- it doesn't work remotely yet.
+
+1999-12-10 John P Cavanaugh <address@hidden>
+
+ * cvs.texinfo: document new -C option to update.
+ (Applied by Karl Fogel <address@hidden>.)
+
+1999-11-20 Larry Jones <address@hidden>
+
+ * cvs.texinfo(history options): Document -f, -n, and -z.
+
+1999-11-09 Jim Kingdon <http://developer.redhat.com/>
+
+ * cvsclient.texi (Requests): Document the arguments to "log", now
+ that I've changed log.c to be more specific in terms of what it
+ will send.
+
+1999-11-05 Larry Jones <address@hidden>
+
+ * cvs.texinfo: Revert Karl's change once again since the code is now
+ fixed. Add "Variables" and "User variables" to index.
+
+1999-11-04 Karl Fogel <address@hidden>
+
+ * log.c (log_usage): Revert Jim Kingdon's reversion of my change
+ of 1999-11-03. Allowing a space between option and argument
+ results in lossage; here is a reproduction recipe: run this from
+ the top of a remote copy of the cvs source tree
+
+ cvs log -d '>1999-03-01' > log-out.with-space
+
+ and then run this (note there's no space after -d now):
+
+ cvs log -d'>1999-03-01' > log-out.no-space
+
+ The resulting files differ; furthermore, a glance at the output of
+ cvs shows that the first command failed to recurse into
+ subdirectories. Until this misbehavior can be fixed in the source
+ code, the documentation should reflect the true state of affairs:
+ if one simply omits the space, everything works fine.
+
+1999-11-04 Jim Kingdon <http://developer.redhat.com/>
+
+ * cvs.texinfo (log options): Revert Karl's change regarding -d and
+ -s. A space is allowed (see sanity.sh for example).
+
+ * cvs.texinfo (Password authentication server): The name of the
+ file is "passwd" not "password".
+
+ * cvsclient.texi (Top): Add @dircategory and @direntry.
+
+1999-11-04 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (Password authentication server, Password
+ authentication client): Rewritten to accommodate the [new]
+ possibility of empty passwords.
+
+1999-11-03 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (Invoking CVS): correct documentation for -d and -s
+ options (as did elsewhere, earlier today).
+
+1999-11-03 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (Setting a watch): describe `watch off' behavior
+ more accurately.
+
+1999-11-03 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (log options): correct documentation for -d and -s
+ options. There can be no space between these options and their
+ arguments.
+
+ Also, make sure all @sc{cvs} codes refer to "cvs" in lower case;
+ this avoids makeinfo warnings. And use @code for the CVSEDITOR
+ environment variable, not @sc.
+
+1999-09-24 Larry Jones <address@hidden>
+
+ * cvs.texinfo: Misc. formatting cleanups.
+
+1999-07-16 Tom Tromey <address@hidden>
+
+ * cvs.texinfo (admin): Mention admin -k exception. Add cvsadmin
+ to index.
+
+1999-07-14 Larry Jones <address@hidden>
+
+ * cvs.texinfo (Password authentication server): Note inetd limits
+ and suggest using shell script to avoid.
+
+1999-06-01 Jim Kingdon <http://www.cyclic.com>
+
+ * cvsclient.texi (Requests): For the import command, the
+ repository given to the Directory requests is ignored.
+
+1999-05-27 Jim Kingdon <http://www.cyclic.com>
+
+ * cvsclient.texi (Requests): Clarify that Modified, Is-modified,
+ Notify and Unchanged must specify a file within the current
+ directory.
+
+1999-05-24 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (checkoutlist): New node, contains more complete
+ documentation of this feature.
+ (CVSROOT storage): Refer to the new node when mentioning
+ checkoutlist.
+ (Administrative files): Update the menu entry for Wrappers.
+
+1999-05-17 Jim Kingdon <http://www.cyclic.com>
+
+ * cvsclient.texi (Requests): For Notify request, strike duplicate
+ "Response expected: no" and fix "a edit" -> "an edit".
+
+1999-05-14 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Working directory storage): Try to be more clear
+ about the conflict field.
+
+1999-05-11 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (config): Use comma after @xref (thanks to Pavel
+ Roskin for the report/fix).
+
+1999-05-10 Jim Kingdon <http://www.cyclic.com>
+
+ * cvsclient.texi (Requests): Document restrictions on characters
+ in Notify requests.
+
+1999-05-04 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Password authentication security): Remove sentence
+ about how no one has audited pserver for holes; a lot of holes
+ have been closed, looking for, &c, since that was written.
+ In the summary, reword to reflect the fact that sniffing a
+ readonly password does not imply general system access (as far as
+ I know, of course).
+
+ * cvs.texinfo (Connection): Also suggest inetd -d.
+
+1999-04-28 Jim Kingdon <http://www.cyclic.com>
+
+ * cvsclient.texi (Requests): Say what goes in the "watches" field
+ of the "Notify" request.
+
+ * cvs.texinfo (Common options): -r is for branches too.
+
+ * cvs.texinfo (Error messages): Add "no such tag" message.
+ (Common options): -f does not override val-tags check.
+
+1999-04-26 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Locks): #cvs.rfl locks must start with "#cvs.rfl."
+ not just "#cvs.rfl". As far as I know CVS has always implemented
+ the former behavior, and this just fixes the documentation.
+
+1999-04-23 Yoshiki Hayashi of u-tokyo.ac.jp
+
+ * cvs.texinfo (verifymsg): Correct wrong file name (bugid.edit ->
+ bugid.verify).
+
+1999-04-22 Jim Kingdon <http://www.cyclic.com>
+
+ * cvsclient.texi (Responses): The text in the "M" response is not
+ designed for machine parsing. Likewise for "error" in regular
+ protocol. Likewise for "E" and "error" in authentication protocol.
+
+1999-04-19 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Error messages): Add "Cannot check out files into
+ the repository itself".
+
+1999-04-16 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Other problems): Add the Windows problem with home
+ directory ending in a slash.
+
+1999-04-14 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (CVS in repository): Include the format of the
+ fileattr file here, rather than referring to the CVS source code.
+
+1999-04-09 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Working directory storage): Whether the timestamp
+ in CVS/Entries is local or universal actually depends on the system.
+
+1999-04-05 Derek Price
+ <http://www-personal.engin.umich.edu/~oberon/resume.html>
+
+ * cvs.texinfo (export options): Remove notation that the -r
+ tag is sticky. 'cvs export' doesn't store that data.
+
+1999-04-08 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Error messages): Add "EOF in RCS file" and
+ "unexpected EOF" (in RCS file) messages.
+
+1999-03-25 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (admin options): Say there can be no space between
+ -e and its argument (since the previous sentence said the argument
+ can be omitted, this is the only possibility).
+
+1999-02-26 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Merging and keywords): When including conflict
+ markers, put @asis{} at the start of the line, in case this file
+ itself is in CVS. Thanks to Derek Price for pointing this out.
+
+1999-02-25 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo: Refer to "keywords" not "RCS keywords". We had
+ only used the latter term in a few places, and it seems like a
+ somewhat odd term in that this style of keyword is by no means
+ specific to RCS.
+ (Merging a branch): Remove spurious ")". Use ref, not xref, after
+ "see".
+ (Merging a branch, Substitution modes): Make sure that @ref is
+ followed by comma, since info wants that.
+ (Merging and keywords): Use samp not code for "-kk". Something of
+ a judgement call, but the rest of the manual uses samp and that
+ seems better to me.
+ (Merging and keywords): Rewrite, to (a) better motivate the
+ discussion based on what the user wants to do, (b) fix up lots of
+ convoluted sentences, (c) move the discussion of the binary files
+ to the end, that is get across the basic idea first and then
+ embellish it. Remove a few unnecessary index entries. Expand
+ example. Just tell people to avoid -kk with binary files (comment
+ out the discussion of using -A after the commit).
+
+1999-01-29 Derek Price
+ <http://www-personal.engin.umich.edu/~oberon/resume.html>
+
+ * cvs.texinfo: Added new node/section on merging and keywords. It
+ contains advice on how to avoid RCS keyword conflicts when merging
+ and avoid corrupting your binary files while doing it.
+
+1999-02-24 Jim Kingdon <http://www.cyclic.com>
+
+ * cvsclient.texi (Request intro): Add paragraph about transmitting
+ more than one command.
+
+1999-01-29 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo: Use EXAMPLE.COM EXAMPLE.ORG and EXAMPLE.NET instead
+ of domains which might conflict with actual (current or future)
+ domains. The EXAMPLE domains are registered for this purpose.
+
+1999-01-22 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Sticky tags): Refer to -j as the better way to undo
+ a change.
+ (Merging two revisions): Also talk about undoing removals and
+ adds. Move the index entries to here.
+
+1999-01-21 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Error messages): Add "waiting for USER's lock".
+
+1999-01-16 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Wrappers): Comment out all the -t/-f documentation,
+ since that feature is currently disabled.
+
+1999-01-14 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs.texinfo (Connecting via rsh): Add some more index entries so
+ that people who want to use SSH and such are slightly less lost.
+
+1999-01-12 Jim Kingdon <http://www.cyclic.com>
+
+ * cvs-paper.ms: Remove comments which contained the FSF's old
+ address; it has changed.
+
+1998-12-29 Jim Kingdon <http://www.cyclic.com>
+
+ * cvsclient.texi (Dates): Numeric timezones are preferred.
+ Also mention the Checkin-time request.
+
+1998-12-23 Jim Kingdon <http://www.cyclic.com>
+
+ * RCSFILES: Add clarification about certain character set issues
+ from Paul Eggert, the RCS maintainer. The last paragraph and the
+ change from Shift-JIS to JIS as an example of a character set
+ which contains 0x40 bytes which are not '@' characters are mine;
+ the rest is directly from Paul Eggert.
+
+1998-12-22 Martin Buchholz <address@hidden>
+
+ * cvs.texinfo: Fixed various trivial typos.
+
+1998-12-17 Jim Kingdon
+
+ * cvsclient.texi (Responses): Explicitly say that Mod-time need
+ not be sent for all files.
+
+1998-12-16 Jim Kingdon
+
+ Thanks to Ram Rajadhyaksha of the MacCVS Pro team for raising the
+ following issues.
+ * cvs.texinfo (Working directory storage): The deal about storing
+ files as text files applies to all the CVS/* files, not just
+ CVS/Entries. State the rationale too.
+ Document CVSROOT/Emptydir in CVS/Repository.
+ There is no set order in CVS/Entries.
+ Explicitly say that writing Entries.Log is optional.
+
+1998-12-03 Jim Kingdon
+
+ * cvs.texinfo (Error messages): Add "unrecognized auth response".
+ (Password authentication server): Remove comment about
+ "unrecognized auth response" and link to the troubleshooting
+ section.
+
+1998-12-02 Jim Kingdon
+
+ * cvs.texinfo (Multiple repositories): Add an example.
+
+1998-11-18 Jim Kingdon
+
+ * cvs.texinfo (Invoking CVS): Change "-r tag" to "-r rev". We
+ already use "tag" as the name of the tag we are adding.
+
+1998-11-13 Jim Kingdon
+
+ * cvs.texinfo (CVS commands): Add comment about whether part of
+ the manual should be organized by command.
+
+1998-11-06 Jim Kingdon
+
+ Clean up various confusions between modules and directories:
+ * cvs.texinfo: In "are you sure you want to release" message,
+ change module to directory. CVS was changed some time ago.
+ (Tags): "working copy of the module" -> "working directory".
+ (Merging two revisions): Remove unnecessary text "that make up a
+ module".
+ (Recursive behavior): Change "module" to "directory".
+ (Removing files): Likewise.
+ (Tracking sources): Remove "a module" from titles.
+ (Moving directories): Change "module" to "parent-dir".
+ (Inside): Remove "of the module".
+ (Inside): Change "module" to "dir".
+ (Rename by copying): Change "module" to "dir".
+ (Rename by copying): Remove "of the module".
+ (Moving directories): "copy of the module" -> "checked out copy of
+ the directory"; remove second "of the module". Change "check out
+ the module" to " check out again".
+ (Moving directories): Remove "of the module".
+ (Keyword substitution): "your working copy of a module" -> "a
+ working directory".
+ (CVS commands): Change "module" to "directory".
+ (release examples): "module" -> "tc directory".
+ (commitinfo): "relative path to the module" -> "directory in the
+ repository".
+ (verifymsg): Change "module" to "directory".
+ (Updating a file): "working copy of a module" -> "working directory".
+
+1998-10-25 Jim Kingdon
+
+ * cvs.texinfo (Branches and revisions): Fix error in branch
+ numbering which was introduced with change of 4 May 1997.
+
+1998-10-20 Jim Kingdon
+
+ * cvs.texinfo (Tags): Point to Invoking CVS node so people aren't
+ left wondering what the syntax is. When introducing -r option,
+ warn people about sticky tags right off.
+ (Tagging the working directory, Tagging by date/tag, Modifying
+ tags, Tagging add/remove): New sections.
+ (Invoking CVS): Adjust tag and rtag to point to the new sections,
+ and to add tag -c which had been omitted. Delete tag -n; there is
+ no such option.
+ (rtag, tag): Removed; no longer needed.
+ (commit examples): Update xref.
+
+1998-10-15 Jim Kingdon
+
+ * cvsclient.texi (Requests): It is OK to send Set before Root.
+
+1998-10-13 Jim Kingdon
+
+ * cvsclient.texi (Protocol Notes): Remove item about "cvs update"
+ sending modified files to the server; there are some better ideas
+ at http://www.cyclic.com/cvs/dev-update.txt
+ Add mention of www.cyclic.com.
+
+1998-09-30 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Committing your changes, Environment variables):
+ Document VISUAL.
+
+1998-09-27 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Password authentication server): Say explicitly
+ that you edit passwd directly, many users get confused by this.
+
+1998-09-24 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Connecting via fork): :fork: may be of interest to
+ users, for example those who prefer CVS to prompt for one log
+ message per checkin, rather than one per directory.
+ (Connecting via fork): Document CVS_SERVER.
+
+1998-09-24 Noel Cragg <address@hidden>
+
+ * cvs.texinfo (Connecting via fork): new node about the fork
+ access method.
+
+1998-09-22 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Environment variables): Document
+ CVS_IGNORE_REMOTE_ROOT in the CVS 1.10 context.
+ (Moving a repository): Update comments concerning surgery on
+ CVS/Root and CVS/Repository files.
+
+1998-09-21 Noel Cragg <address@hidden>
+
+ * cvs.texinfo (Environment variables): remove information about
+ CVS_IGNORE_REMOTE_ROOT, since it's no longer used.
+
+1998-09-21 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (config): Mention that CVS 1.10 doesn't have
+ LockDir.
+
+1998-09-18 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Keyword list): Describe $Name and checking out with
+ a revision.
+
+1998-09-16 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: RFC2346 is out; update comment.
+
+1998-09-13 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Keyword list, Substitution modes): In describing
+ $Locker and -kkvl, refer to cvs admin -l.
+
+ * cvsclient.texi (Requests): Re-word description of Sticky to
+ allow room for "Ntagname" (or other, future, values).
+
+ * cvs.texinfo (tag): Remove confusing wording about supplying
+ revision numbers "implicitly".
+
+1998-09-10 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (rdiff options): Thanks to the diff library, -u is
+ supported regardless of your diff program.
+
+1998-09-07 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (config): Add LockDir.
+
+1998-09-01 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): "Directory" and "Argument" are
+ requests, not commands. Likewise for "other-request". A command,
+ roughly, is a request that uses "Argument"s, but we might want to
+ phase out the use of that term more so than codify it, I'm not sure.
+
+1998-09-01 Noel Cragg <address@hidden>
+
+ * cvsclient.texi (Requests): added a detailed explanation of the
+ Directory request and how it is handled, both for pre-1.10 and
+ post-1.10 servers.
+
+1998-09-01 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Multiple repositories): Also describe the CVS 1.10
+ behavior. Looking at a mismatched version of the manual seems to
+ be a reasonably common occurrence.
+
+ * cvs.texinfo (Environment variables): Revert change regarding
+ CVS_SERVER_SLEEP*; having that kind of debugging code in the main
+ CVS is getting out of hand.
+
+1998-09-01 Noel Cragg <address@hidden>
+
+ * cvs.texinfo (Multiple repositories): brief mention that cvs now
+ handles a working directory composed of multiple repositories.
+ (Environment variables): add note about CVS_SERVER_SLEEP2.
+
+1998-08-21 Ian Lance Taylor <address@hidden>
+
+ * cvsclient.texi (Text tags): Document importmergecmd tag.
+
+1998-08-20 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Common options): Replace out of date URL concerning
+ ISO8601 dates with a more general statement and a few comments.
+
+1998-08-18 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Add "Checkin-time" request.
+
+Sun Jul 26 02:42:20 1998 Noel Cragg <address@hidden>
+
+ * cvs.texinfo (config): TopLevelAdmin variable.
+
+ * cvsclient.texi (Requests): fix typo.
+
+1998-07-14 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): "remove" is like "add" in the sense
+ that it is the "ci" request which does most of the work.
+
+1998-06-23 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Excluding directories): Fix order of
+ "!first-dir/sdir" and "first-dir" to match what CVS actually
+ accepts. Reported by Tim McIntosh of sterling.com.
+
+1998-06-09 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Using keywords): Rewrite to be less specific to
+ source code in C. The old text was worse than that; it was
+ specific to certain versions of GCC (not even current GCC's, I
+ don't think) (reported most recently by Mitchell Perilstein;
+ if memory serves by others before that).
+
+1998-06-08 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Concurrency): Also mention #cvs.lock. Don't
+ mention #cvs.tfl; it is quite old (before CVS 1.5).
+ (Locks, Backing up, Concurrency): Add more index entries.
+
+1998-06-03 Ian Lance Taylor <address@hidden>
+
+ * cvs.texinfo (Tracking sources): Clarify that the vendor branch
+ is only made the head revision when you import a new file, not any
+ time you import a file.
+
+1998-05-23 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (What is CVS?): info-cvs-request is now at gnu.org
+ and is no longer handled by a human (hallelujah).
+
+1998-05-12 Jim Meyering <address@hidden>
+
+ * cvs.texinfo: Add an info dir entry.
+ Remove trailing white space.
+
+1998-05-05 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Wrappers): Be more explicit that -m 'COPY' has no
+ effect on binary files.
+
+1998-05-02 Jim Kingdon <address@hidden>
+
+ * RCSFILES: Add more discussion of the order of the revisions.
+
+1998-04-27 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (loginfo example): Also give example of sending
+ mail. Use internal variable $USER rather than expecting CVS to
+ set the environment variable $USER. Change unnecessary 'sed'
+ invocation to 'cat' (it suffered from the same problem in terms of
+ internal variables versus environment variables).
+
+ * cvs.texinfo (Error messages): Add "conflict: removed FILE was
+ modified by second party".
+
+1998-04-20 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Common options): Update comment about meaning of
+ HEAD in cvs diff.
+
+1998-04-12 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Dates): Also mention log -d.
+
+ * cvs.texinfo (Invoking CVS): No space is allowed between -r or -w
+ and its argument, for the log command.
+
+1998-04-11 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Dates): New section, explaining the deal with
+ date formats.
+
+1998-04-09 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Global options, Invoking CVS): Fix typo
+ ("files files" -> "files").
+ (Invoking CVS): Make -q and -Q more concise.
+ (Invoking CVS): Use @var for metavariables in "diff -r".
+
+1998-03-17 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (~/.cvsrc): In example, put "checkout" rather than
+ "co" into .cvsrc; we just finished explaining that only the former
+ works! Thanks to Lenny Foner for reporting this.
+
+ * cvs.texinfo (Copying): Remove this node. This basically
+ restores the status quo prior to 18 Oct 1996 (before then the node
+ existed but was empty).
+ (before Top): Adjust copyright notice accordingly.
+
+1998-03-12 Tim Pierce <address@hidden>
+
+ * RCSFILES: Updated description of `hardlinks' newphrases.
+
+1998-03-07 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Tags, Sticky tags, Creating a branch, Accessing
+ branches): Rename release-0-1 tag to rel-0-1 and likewise for
+ release-0-1-patches and release-0-4. This fixes an overfull hbox.
+ (diff options): Reformat table to fix underfull hboxes and such.
+
+1998-03-07 Tim Pierce <address@hidden>
+
+ * cvs.texinfo (Editing files, Special Files): Document hardlinks.
+ Various cleanups to PreservePermissions text.
+ * RCSFILES: Document PreservePermissions newphrases.
+
+1998-03-04 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Special Files): Add notes about client/server CVS
+ and hard links across directories.
+
+1998-03-01 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Keeping a checked out copy): The magic loginfo
+ incantation isn't too likely to work except on unix.
+
+1998-02-23 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (user-defined logging): Double "@" literal.
+
+1998-02-18 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (user-defined logging): Add taginfo example.
+
+1998-02-04 Tim Pierce <address@hidden>
+
+ * cvs.texinfo (config): PreservePermissions variable.
+ (Special Files): New.
+ (Editing files): Add note about PreservePermissions.
+
+Tue Feb 10 18:07:35 1998 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Connection): New node.
+
+ * cvsclient.texi (Protocol): Fix typo (lots -> lost).
+
+Sun Feb 8 21:39:22 1998 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Invoking CVS): For admin -b, point to the section
+ where we talk about reverting to vendor branch.
+
+ * cvs.texinfo (Invoking CVS, rdiff options): Document rdiff -V
+ option as obsolete, since it was made a fatal error some time ago.
+
+ * cvs.texinfo (Invoking CVS): Add global options, keywords, and
+ keyword substitution modes. Wording fix in reference to --help
+ and Index.
+
+Wed Jan 28 23:09:39 1998 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Excluding directories): Add index entry for "!".
+
+28 Jan 1998 Karl Fogel and Jim Kingdon
+
+ * cvsclient.texi (Requests, Responses): document
+ "wrapper-sendme-rcsOptions" and "Wrapper-rcsOption".
+
+Tue Jan 27 18:37:37 1998 Ian Lance Taylor <address@hidden>
+
+ * cvs.texinfo (Excluding directories): New node, documenting how
+ to exclude directories using ! in an alias module.
+
+Sun Jan 18 18:23:02 1998 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Add Kopt request.
+
+Thu Jan 1 17:36:42 1998 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (BUGS, Credits): Change @unnumbered to @appendix now
+ that these are moved from the start to the end.
+
+Sat Dec 27 10:06:56 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add "Too many arguments!".
+
+Fri Dec 26 18:30:26 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (What is CVS?): Just point to the two canonical web
+ sites (Pascal Molli and Cyclic) concerning CVS downloads. The GNU
+ URL was out of date and GNU only has source distributions anyway.
+
+ * cvs.texinfo: Change bug-cvs address to gnu.org per email from
+ Martin Hamilton.
+
+Tue Dec 23 18:04:09 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Sticky tags): Further cleanups. Fix thinko
+ (s/subsequent cvs update/& commands/). Remove "vi driver.c" and
+ commit from example (totally vestigial). Reword start of
+ paragraph on non-branch sticky tags, so that it better alludes
+ to branch sticky tags. When introducing sticky tags, make it
+ clear that even people who aren't trying to use sticky tags
+ may need to know how to avoid them. Restore comment about
+ CVS/Tag files.
+ (Accessing branches): Don't xref to merging here; that is a much
+ more advanced topic and the "but see" wording didn't tell us what
+ to see the xref about.
+
+Tue Dec 23 14:39:08 1997 Karl Fogel <address@hidden>
+ and Jim Kingdon
+
+ * cvs.texinfo (Creating a branch): Rewritten. Introduce with
+ `tag', then discuss `rtag' and `-r'.
+
+Tue Dec 23 10:03:37 1997 Karl Fogel <address@hidden>
+ and Jim Kingdon
+
+ * cvs.texinfo: Changes to dehairify the "Sticky tags" situation:
+ (Revisions): "Sticky tags" moved here, description in menu changed
+ to be a little more informative.
+ (Sticky tags): Moved from "Branching and merging" to "Revisions".
+ (Accessing branches): New node in "Branching and merging",
+ explains how to use checkout vs update to retrieve a branch.
+ Text and example inherited from "Sticky tags", but text mostly
+ rewritten.
+ (Sticky tags): Moved under "Revisions", rewritten somewhat (more
+ rewrites to follow).
+ Don't use "-v" in "cvs status" example.
+
+Mon Dec 22 11:46:05 1997 Karl Fogel <address@hidden>
+ and Jim Kingdon
+
+ Cleanups related to recent separation of revisions from
+ branching/merging:
+ * cvs.texinfo (Revisions): Take paragraph introducing branches,
+ rewrite it and move it to "Branching and merging".
+ (Branching and merging): Also rewrite merging intro.
+ (Revision numbers): Don't go into detail about branch revision
+ numbers here, just mention that they happen and refer to new
+ node "Branches and revisions".
+ (Branches and revisions): New node under "Branching and merging",
+ inherits text from "Revision numbers".
+ (Creating a branch): Refer to "Branches and revisions" now, not
+ "Revision numbers".
+ (Binary why): Rewrite sentence which refers to merging, so that
+ it isn't specific to branch merging.
+ (Branches motivation): Fix typo (select -> elect). Add comment
+ about what this node is accomplishing, in general.
+
+Sun Dec 21 20:57:24 1997 Karl Fogel <address@hidden>
+ and Jim Kingdon
+
+ This is just moving text; related cleanups to follow.
+ * cvs.texinfo: Changes to put branching and merging together, and
+ keep it all separate from revisions:
+ (Revisions): Renamed from "Revisions and branches".
+ (Branching and merging): Renamed from "Merging".
+ (Branches motivation, Creating a branch, Sticky tags, Magic branch
+ numbers): these subnodes moved to "Branching and merging" from
+ "Revisions".
+ everywhere: Adjusted cross-references to cope with above.
+
+Sun Dec 21 20:36:39 1997 Karl Fogel <address@hidden>
+ and Jim Kingdon
+
+ Note that this is just moving text, not changing it:
+ * cvs.texinfo: divide top-level menu into sections.
+ (Multiple developers, Builds, Tracking sources, Keyword
+ substitution): moved to be in "CVS and the Real World" section.
+ (Compatibility): moved to be in "References" section.
+
+Mon Dec 22 08:54:31 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Example): In comment, in citing the BNF style
+ used in many RFCs, cite RFC2234 not RFC822 (now that the former is
+ out).
+
+Sun Dec 21 17:42:22 1997 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (Overview): New node.
+ (What is CVS?, A sample session): Put under Overview.
+ (What is CVS not?): New node under Overview.
+ [text previously was part of "What is CVS?" -kingdon]
+ (Preface): Removed this node and its contents.
+ (Checklist): Removed this node and its contents.
+ (Credits): Now toward end of top-level menu (was under Preface).
+ (BUGS): Now toward end of top-level menu (was under Preface).
+
+Sun Dec 14 10:14:25 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): Add MT response.
+ (Text tags): New node.
+
+ * cvs.texinfo (loginfo): Add comment about which commands run
+ loginfo.
+
+Sat Dec 13 08:41:13 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Connection and Authentication): State that
+ GSSAPI is preferred to kserver. Try to be clearer about what
+ the term "pserver" means. Introduce GSSAPI and cite the relevant
+ RFCs. Discuss the limitations of the existing features in
+ preventing hijacking.
+
+ * cvs.texinfo (GSSAPI authenticated, Kerberos authenticated):
+ Briefly introduce what GSSAPI and Kerberos are. Be slightly more
+ emphatic about protecting against downgrade attacks.
+
+Fri Dec 12 17:36:46 1997 Ian Lance Taylor <address@hidden>
+
+ * cvs.texinfo (GSSAPI authenticated): New node.
+ (Global options): Document -a. Mention GSSAPI in -x
+ documentation.
+ * cvsclient.texi (Connection and Authentication): Document GSSAPI
+ authentication.
+ (Requests): Add Gssapi-encrypt and Gssapi-authenticate.
+
+Fri Dec 12 09:27:38 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (cvsignore): Add note about comments and the
+ space-separated nature of the syntax.
+
+Sun Dec 7 09:33:11 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (checkout): Clarify issues regarding updating
+ existing working directories.
+
+Sun Nov 30 20:38:17 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Wrappers): Add comment: we don't document %s.
+
+Mon Nov 24 23:00:09 1997 Karl Fogel <address@hidden>
+ and Jim Kingdon <address@hidden>
+
+ * cvsclient.texi: Move Protocol Notes node to the end.
+
+ * cvsclient.texi (Request intro): new node/section.
+ (Protocol): added some introductory material.
+ Rearranged menu into General Conventions, Protocol specification,
+ and Example etc sections.
+ (File Modes): replaces Modes, for consistency.
+
+Sat Nov 22 12:29:58 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Entries Lines): Clarify options in entries line.
+
+Tue Nov 18 09:23:15 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Be more explicit about "export" and
+ entries lines.
+
+ * Makefile.in (DISTFILES): Remove DIFFUTILS-2.7-BUG.
+
+Mon Nov 17 18:20:47 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (tag options): Expand comment with reference to FAQ.
+
+Fri Nov 14 11:02:37 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Update discussion of "dying gasps".
+
+ * cvs.texinfo (tag options): Add FIXME comment about renaming tags.
+
+Thu Nov 13 10:20:39 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Common options): Remove also has a -f option with a
+ different meaning than most.
+
+Wed Nov 12 21:57:40 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (File permissions, Connecting via rsh, Environment
+ variables): When putting an environment variable in the index, say
+ it is an environment variable. Don't index the same name twice.
+
+ * cvs.texinfo: Many edits to reflect the fact that CVS no longer
+ invokes external RCS programs.
+
+Tue Nov 11 15:15:49 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Locks, CVS in repository): New nodes, document the
+ locking scheme and briefly outline CVS and CVS/fileattr.
+
+Sun Nov 9 17:39:41 1997 Jim Kingdon <address@hidden>
+
+ * DIFFUTILS-2.7-BUG: Removed; the bug is fixed and the testcases
+ are incorporated into sanity.sh.
+
+Sat Nov 8 09:49:38 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Binary why): Try to be a little clearer about how
+ merges fit into CVS. Say it may be error prone to have developers
+ doing merges manually.
+
+Tue Nov 4 13:02:22 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (admin options): Add discussion of what happens if
+ there are tags.
+
+Fri Oct 31 00:04:09 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (admin options): Rewrite discussion of -o to
+ hopefully be clearer and to also document the new :: syntax.
+ (admin examples): Removed; incorporated into admin options.
+ (Invoking CVS): Wording fix for admin -o.
+
+ * cvs.texinfo (Binary why): New node, talks about diff and merge.
+ (Binary howto): Renamed from Binary files.
+ (Binary files): Now just contains an introduction.
+
+ * cvs.texinfo (Error messages): Add "could not merge" message. In
+ discussion of "Binary files . . . differ" message, mention that
+ this is only an issue with old verisons of CVS.
+
+Thu Oct 30 15:55:21 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add "authorization failed" message.
+
+Wed Oct 29 11:52:05 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Remove fake RCSid; we decided to remove rcsid's a
+ while ago. Cleanups suggested by Stephen Gildea (CVSROOT/passwd
+ has 2 or 3 fields; /user -> /usr; noone -> no one; in used -> in
+ use). Add comment about making compilers happy about rcsids.
+
+Sat Oct 25 00:58:24 1997 Jim Kingdon <address@hidden>
+
+ * RCSFILES: rcsfile.5 is correct about {num} after next being
+ optional.
+
+Wed Oct 22 10:08:27 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add message about unrecognized
+ response from cvs server.
+
+1997-10-11 Noel Cragg <address@hidden>
+
+ * cvs.texinfo (checkout options): describe how the `-d' and `-N'
+ flags really work. Give examples.
+ (export options): refer the reader to the descriptions for `-d'
+ and `-N' in checkout options, since the behavior is the same.
+
+Thu Oct 9 12:01:35 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (log options): Add comment about "cvs log -r".
+
+Wed Oct 8 10:24:19 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (rtag options): Add comment about how this is
+ confusing.
+
+Tue Sep 30 12:31:25 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Working directory storage): Add comment about
+ Entries.Static.
+
+Thu Sep 25 23:52:57 1997 Noel Cragg <address@hidden>
+
+ * cvsclient.texi (Responses): description of Module-expansion was
+ missing a carriage return after the @item clause.
+
+Wed Sep 24 12:04:42 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Remote repositories): Add comment about pserver
+ vs. having users create their own repositories.
+
+Sat Sep 20 00:59:53 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Keyword list): Change title from "RCS Keywords" to
+ "Keyword list" as it is CVS that expands them.
+ (Avoiding substitution): Change "rcs" to "cvs", in the context of
+ the program which expands keywords.
+
+Fri Sep 19 22:57:24 1997 Jim Kingdon <address@hidden>
+
+ * RCSFILES: Grammar fix in first paragraph. Re-word section on
+ dead newphrase. Add item about what it means if "expand" is omitted.
+
+ * cvs.texinfo (Magic branch numbers): Change example branch number
+ from 1.2.3 to 1.2.4; CVS assigns even branch numbers and I don't
+ think vendor branches are very relevant to this example.
+
+Wed Sep 17 17:21:33 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (admin options): Add comment about "cvs admin -b"
+ (with no argument to the -b).
+
+ * RCSFILES: "next" is optional, not required.
+
+Tue Sep 16 15:13:22 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Binary files): Add comment about another possible
+ way to auto-detect binary files.
+
+Sun Sep 14 12:38:56 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Conflicts example): Adjust text and comments
+ regarding conflict markers to reflect change in CVS.
+
+Wed Sep 10 12:44:04 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Server requirements): Add comment about server
+ disk usage in /tmp.
+
+ * cvs.texinfo (Common options): More comments about date formats:
+ "now", "yesterday", and the "3 weeks ago" family.
+
+Tue Sep 9 13:09:58 1997 Jim Kingdon <address@hidden>
+
+ * DIFFUTILS-2.7-BUG: Eggert patch is preferred to Rittle one.
+
+Sun Sep 7 18:38:23 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (history options): Revise -e to say that it includes
+ future record types (and remove out of date list of what record
+ types it implies).
+
+ * cvs.texinfo (Environment variables): Expand/correct discussion
+ of HOME, HOMEDRIVE, and HOMEPATH.
+ (Error messages): Add "could not find out home directory".
+
+ * cvs.texinfo (update options): Reword -r doc to hopefully be
+ clearer that it takes either numeric or symbolic revision.
+
+ * cvs.texinfo (syntax): Add comment about how regexp syntax may
+ be, er, creatively altered, by configure.in.
+
+Sat Sep 6 11:29:15 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Working directory storage): Document Baserev and
+ Baserev.tmp.
+ (Working directory storage): Adjust comment regarding CVS/* being
+ text files.
+
+Fri Sep 5 14:42:39 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (BUGS): Remove mention of unsupported resources page
+ on http://www.cyclic.com, as it might go away in a future
+ reorganization.
+
+ * DIFFUTILS-2.7-BUG: Further info from Eggert.
+
+1997-09-05 Paul Eggert <address@hidden>
+
+ * DIFFUTILS-2.7-BUG: Explain how this bug will probably be
+ fixed in the next diffutils release.
+
+Thu Sep 4 17:09:57 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Binary files): Reword the section on what you need
+ to do with cvs admin -kb to hopefully be a bit clearer. Still not
+ ideal (see comment).
+
+ * cvs.texinfo (modules): Break node into separate nodes for alias
+ modules, regular modules, ampersand modules, and options. Expand
+ text with more examples and explanations. Add index entries.
+
+Wed Sep 3 14:49:43 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Multiple developers): Add idea about cvs editors
+ and reserved checkouts.
+
+Sun Aug 31 19:36:21 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Rewrite paragraph on cvs add on a
+ filename containing '/'.
+
+Thu Aug 28 14:13:50 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (diff options): Add comment about "cvs diff"
+ vs. "cvs diff -r HEAD".
+
+ * cvs.texinfo (Global options): Add comment about -w not
+ overriding cvs watch on.
+
+Wed Aug 27 08:09:31 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Password authentication server): Grammar fix ("under
+ as the username" -> "as the username").
+
+ * cvs.texinfo: Fix doubled 'the the' typos. Reported by
+ address@hidden
+
+Tue Aug 26 12:25:42 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Checklist): Reword xref to point to Binary files
+ rather than Keyword expansion. Credit goes to address@hidden
+ (Jeff Breidenbach) for reporting the problem.
+
+Mon Aug 18 17:23:18 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (modules): Suggest taginfo instead of -t. Add
+ comment with some of the reasons. Add comment about -u and -i
+ problems.
+
+Sat Aug 16 10:19:06 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add note about how "could not
+ check out foo.c" seems to also have been observed on Irix.
+
+Fri Aug 15 17:28:01 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add "could not check out foo.c".
+
+Thu Aug 14 23:57:53 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Wrappers): Document new -m 'COPY' behavior.
+
+Tue Aug 12 20:56:40 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Sticky tags): Add comment about how we should be
+ documenting sticky tags.
+
+Fri Aug 8 10:01:03 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (File status): Add comment about "working revision"
+ in cvs status for a locally removed file.
+
+Thu Aug 7 22:53:45 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (From other version control systems): Mention
+ pvcs_to_rcs alongside sccs2rcs.
+
+Tue Aug 5 17:22:50 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Compatibility): Add comment about how CVS probably
+ could be detecting the case of dead files killed by CVS 1.3.
+
+ * cvs.texinfo (From other version control systems): Add paragraph
+ about converting from systems which don't export RCS files.
+
+Sun Aug 3 21:03:14 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): Cite RFC1321 for MD5.
+
+ * cvs.texinfo (A sample session): Nuke index entry for "A sample
+ session". The fact that this isn't "sample session" is totally
+ bogus, but in general the table of contents is probably better for
+ this entry.
+
+ * cvs.texinfo (Error messages): Add comment about wording of error
+ concerning unknown -x option.
+
+ * cvs.texinfo (Wrappers): Add comment about absolute filter pathname.
+
+Thu Jul 31 14:40:15 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Use @ref not @xref when reference is not at the
+ start of a sentence. Avoids capitalizing "See" when we shouldn't.
+ Fixes to other similar xref problems.
+
+Wed Jul 30 19:30:31 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Connection and Authentication): Don't use @samp
+ on BEGIN AUTH REQUEST and friends. Avoids overfull hbox.
+
+Fri Jul 25 10:40:22 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Remove obsolete sentence regarding
+ using Directory instead of Repository enabling alternate response
+ syntax.
+
+ * cvsclient.texi (Response intro): Add discussing of file updating
+ responses and file update modifying responses.
+ (Responses): Refer to this description rather than trying to
+ describe it in each place. The descriptions in each place were
+ somewhat incomplete and didn't get updated when new file updating
+ responses were added.
+
+ * cvsclient.texi: Split node Responses into Response intro,
+ Response pathnames, and Responses.
+
+Thu Jul 24 23:13:24 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (config): Document SystemAuth.
+ (Password authentication server): Mention SystemAuth.
+
+Mon Jul 21 08:57:04 1997 Jim Kingdon <address@hidden>
+
+ * Makefile.in (DISTFILES): Add DIFFUTILS-2.7-BUG.
+
+Sun Jul 20 17:55:52 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (admin options): For options with optional
+ arguments, specify that there can be no space between the option
+ and its argument. For -N, add xref to Magic branch numbers. For
+ -t, talk about reading from stdin. Comment changes.
+
+Sat Jul 19 22:28:47 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Preface): Make section titles more verbose.
+ Likewise for the menu.
+
+Fri Jul 18 08:41:11 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): No need for an external patch if
+ server and client are current. Add comment with more thoughts
+ about messages specific to old versions of CVS.
+
+ * cvs.texinfo (Error messages): Add "cannot start server via rcmd".
+
+ * cvs.texinfo (Error messages): Add "cannot open CVS/Root" for cvs
+ init.
+
+ * cvs.texinfo (Error messages): Add "missing author".
+
+Tue Jul 15 16:47:08 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Keyword list): Fix documentation of $Log to reflect
+ the fact that we no longer use the comment leader.
+ (admin options): Fix documentation of $Log.
+ (admin examples): Remove example concerning comment leader, since
+ the example no longer does what it claims to.
+ (admin, admin options): Fix various parts of the documentation to
+ not refer to this being implemented via RCS. Say nastier things
+ about -I and -x. Add comments about options to "rcs" which we
+ don't document.
+
+Mon Jul 14 00:04:32 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): The "cannot change permissions on
+ temporary directory" error has been happening in various test cases.
+
+Sat Jul 12 11:12:18 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Repository files): Further comments about leading
+ "-" in filenames.
+
+Fri Jul 11 21:30:11 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Repository files): Add comment about legal
+ filenames.
+
+Wed Jul 9 18:05:26 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): Add Mbinary response.
+
+Mon Jul 7 12:04:01 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Goals): Add previously unwritten goal about only
+ one way to do each operation.
+
+ * cvs.texinfo (File permissions): Rewrite paragraph on setuid to
+ be more verbose and less unix-specific.
+
+Sat Jul 5 03:16:38 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Connection and Authentication): When we said to
+ "ignore" an unrecogized code we mean to treat it as nonspecific,
+ not to ignore the response.
+
+ * cvsclient.texi (Example): Refer to RFC2119 when referring to
+ terminology of MUST, SHALL, &c.
+
+ * cvs.texinfo (Windows permissions): New node.
+
+Fri Jul 4 15:27:43 1997 Ian Lance Taylor <address@hidden>
+
+ * cvs.texinfo (Common options): Fix typo (avaliable for
+ available).
+
+Tue Jul 1 09:19:02 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Server requirements): Discuss memory used by diff.
+
+ * cvs.texinfo (Substitution modes): Add comment about -A resetting
+ both sticky tags/dates and sticky options.
+
+ * cvs.texinfo (File permissions): Add paragraph concerning
+ ownership of the RCS files.
+
+ * cvs.texinfo (Working directory storage): Relative repositories
+ in CVS/Repository are legal.
+
+Mon Jun 30 10:48:21 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Top): Add menu item for Password scrambling.
+
+ * cvs.texinfo (Committing your changes): Add comment concerning
+ documentation of message prompting.
+
+Fri Jun 27 11:20:34 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Password scrambling): New node.
+ (Connection and Authentication): Adjust accordingly.
+ (Protocol Notes): Add long discussion of character sets and
+ password scrambling.
+
+ * cvs.texinfo (Repository files): Also mention doc/RCSFILES in
+ documenting RCS file format.
+ (CVSROOT, storage of files): New node.
+
+Thu Jun 26 09:18:15 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (File permissions): xref to the pserver thing about
+ permissions in CVSROOT.
+ (Kerberos authenticated): Explicitly mention kerberos rsh.
+ Add various index entries for "security, <foo>".
+
+Wed Jun 25 13:39:16 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Common options): Rewrite comments concerning HEAD
+ and testcases and solution. Changing HEAD might be too big a
+ change; might be better to phase it out.
+ (Common options, Tags): Add index entries for HEAD and BASE.
+
+Tue Jun 24 09:37:26 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add assertion failed.
+
+ * cvsclient.texi (Connection and Authentication): Add "E" and
+ "error" as responses in authentication protocol. The server
+ already was in the (formerly bad) habit of sending them, and we
+ might as well implement this in the client and document it.
+
+ * cvs.texinfo (Password authentication security): Note about
+ permissions on $CVSROOT also applies to its parent and so on up to
+ /.
+
+Mon Jun 23 18:28:18 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Creating a repository): xref to Server requirements
+ for more details on memory, CPU.
+ (Server requirements): Add xref to Creating a repository regarding
+ disk space.
+
+ * cvs.texinfo (Read-only access, Password authentication
+ security): The known holes which let a read-only user execute
+ arbitrary programs on the server are gone.
+
+ * cvsclient.texi (Protocol Notes): Remove multisite item; it is
+ replaced by item 186 in TODO. Add a general reference to TODO.
+ Rewrite accordingly the sentence about multisite in the item
+ concerning sending modified files in "cvs update".
+
+Fri Jun 20 17:00:20 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add "binary files differ" when
+ trying to check in a binary file.
+
+Fri Jun 20 14:01:23 1997 David J MacKenzie <address@hidden>
+ and Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Fix various formatting, spelling, stylistic, and
+ factual errors.
+
+Thu Jun 19 07:11:33 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (config): New node.
+ (Password authentication server): Talk about RCSBIN in config as
+ an alternative to -b global option.
+ * cvsclient.texi (Requests): Specify when Root can/must be used.
+
+ * cvs.texinfo (Error messages): Add
+ "*PANIC* administration files missing".
+
+ * cvs.texinfo (Password authentication server): Mention
+ permissions on $CVSROOT and $CVSROOT/CVSROOT as part of the
+ installation process.
+ (Password authentication security): Clarify that permissions issue
+ applies to $CVSROOT as well as $CVSROOT/CVSROOT.
+
+Wed Jun 18 00:03:25 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Password authentication security): Add paragraph
+ on write permissions of $CVSROOT/CVSROOT.
+
+ * cvs.texinfo (Adding and removing): New node. Move Adding files,
+ Removing files, Removing directories, Moving files, and Moving
+ directories under it.
+
+ * cvs.texinfo (Removing directories): Add sentence about how
+ one doesn't remove the directory itself.
+
+ * cvs.texinfo (Password authentication server): Document
+ --allow-root.
+
+Tue Jun 17 09:58:03 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add "unknown option" from RCS.
+
+Fri Jun 13 12:11:09 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Global options): Add note about how -n might affect
+ CVS's output.
+
+Thu Jun 12 09:33:40 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Other problems): New node. Add discussion of
+ problem with old rcsmerge.
+
+ * cvs.texinfo (Environment variables): Add CVSUMASK.
+
+Mon Jun 2 18:39:57 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Moving a repository): New node.
+
+Tue May 27 18:27:57 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Working directory storage): Add comment about
+ timestamps.
+ * cvsclient.texi (Responses): Add Mod-time.
+
+Mon May 26 10:04:32 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Wrappers): Add comment concerning -t/-f and
+ client/server.
+
+Sun May 25 00:08:39 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Multiple vendor branches): New node.
+ (First import, import options, Invoking CVS): xref to it.
+
+Sat May 24 23:47:47 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (File permissions): Add comment about group
+ ownership in repository and setgid bit on directories.
+
+Fri May 23 17:14:05 1997 Jim Kingdon <address@hidden>
+
+ * RCSFILES: Fix typo in dead newphrase description ("an" -> "a").
+
+Fri May 23 16:33:38 1997 Ian Lance Taylor <address@hidden>
+
+ * RCSFILES: Mention dead as a newphrase.
+
+Fri May 23 09:45:39 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Builds): In comment, update URL of mk.
+
+Thu May 22 09:25:56 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add comment about yet another way
+ to produce a "cannot open CVS/Entries for reading" error.
+
+Tue May 20 17:54:55 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add item about EINVAL in rename.
+
+Mon May 19 00:21:49 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Keywords in imports): New node.
+ (Tracking sources): Add comment about what a "vendor" is.
+
+ * cvs.texinfo (Keyword substitution): Where it refers to RCS
+ having a certain behavior, rewrite to not pass the buck like
+ that. Saying "RCS file" is still OK; that is a legit CVS
+ concept. A few other minor edits.
+
+Sun May 18 10:24:57 1997 Jim Kingdon <address@hidden>
+
+ * RCSFILES: Add list of known newphrase extensions.
+
+ * cvs.texinfo (From other version control systems): Fix typo
+ ("systesm" -> "systems").
+
+ * cvs.texinfo (Exit status): New node.
+ (diff): Replace text on exit status with an xref to that node.
+ The previous text documented a behavior which CVS no longer
+ implements.
+ (user-defined logging, commitinfo, verifymsg, Error messages):
+ Add index entries for "exit status, of <something which CVS invokes>".
+
+ * cvs.texinfo (Administrative files): Add comment concerning
+ writing triggers and particularly performance issues.
+
+ * cvs.texinfo (rtag options, tag options): Don't discuss what old
+ versions did with respect to the behavior now controlled by -F; we
+ don't try to document old versions here. Add comments concerning
+ how -F should be documented. Add index entries for "renaming
+ tags" and such pointing to "tag -F".
+
+Wed May 14 12:16:19 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Binary files): Add text and comment about
+ automatically detecting binary files.
+
+Mon May 12 11:55:07 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Connection and Authentication): Add item about
+ future expansion.
+
+Thu May 8 11:08:34 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Update imports): Add comment about wdiff
+ vs. fsf/wdiff in example.
+
+Wed May 7 13:52:47 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (checkout): Add comment about need for example
+ regarding what the "module" argument means.
+
+Tue May 6 18:02:27 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (History browsing): Add comment about looking at old
+ revisions.
+
+Tue May 06 15:05:00 1997 Larry Jones <address@hidden>
+
+ * cvs.texinfo: More additions/corrections for -R due to recent
+ changes.
+
+Mon Dec 16 15:18:00 1996 Larry Jones <address@hidden>
+
+ * cvs.texinfo: Added/corrected documentation for -R. (Minor edits
+ by Jim Kingdon to reflect recent changes in cvs.texinfo)
+
+Sun May 4 14:38:35 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Compatibility): Add comment about "D" lines in
+ Entries.
+
+ * cvs.texinfo (CVS commands, diff): Change "run diffs" to "show
+ differences"; the former is jargon.
+ (CVS commands): Don't refer to "rlog" in describing what log does.
+
+ * Makefile.in (cvsclient.dvi cvsclient.aux): Run texi2dvi rather
+ than (poorly) emulating it ourself.
+
+ Fix overfull and underfull hboxes:
+ * cvs.texinfo (What is CVS?): Add words "the newsgroup" before
+ "comp.sources.unix".
+ (Credits): Put list of people in @display.
+ (Repository files): Put /usr/local/cvsroot in @example.
+ (Connecting via rsh): Change "anklet" to "toe" in example.
+ (Kerberos authenticated, Password authentication client, Password
+ authentication server): Change "brickyard" to "yard" in example.
+ (Read-only access): Use @example and refer to files with a shorter
+ pathname.
+ (Server temporary directory): Use @example for pathname.
+ (Watches Compatibility): Add phony line break.
+ (Revision numbers): Remove revision 1.2.2.2 and tighten up the
+ spacing for "the main trunk".
+ (Tags, Creating a branch): Change /usr/local/cvsroot to /u/cvsroot.
+ (Merging more than once): Tighten up spacing for "the main trunk".
+ (Recursive behavior): Put long command in @example.
+ (First import): Remove word "called".
+ (Common options): Put long URL in @example.
+ (loginfo example): Use fewer hyphens in example.
+ (Variables): Put long command name in @example.
+ (Copying): Add line break.
+ (Administrative files): Remove "the" from title.
+ (Copying): Change "@unnumberedsec" to two "@heading"s.
+ * cvsclient.texi (Requests): Change /home/kingdon/zwork/cvsroot to
+ /u/cvsroot.
+ (Example): Add word "file".
+ (Example): Change line breaks in example log message.
+ (Example): Change /home/kingdon/testing/cvsroot to /u/cvsroot.
+
+ * cvs.texinfo (Credits): Don't refer to appendix A and B, they
+ have been renumbered. Reword so that it works whether the text in
+ question has since been rewritten or not.
+
+ * cvs.texinfo (BUGS): Rewrite to reflect the many different ways
+ that one might want to handle bugs. Move information on Signum
+ and Cyclic from Preface to here. Remove information on known
+ deficiencies in the manual (some of them I'm not sure were really
+ things in need of improvement; others were too general to be
+ useful). For the most part FIXME comments are probably better for
+ this. Remove "Linkoping, October 1993, Per Cederqvist"--many
+ parts of the manual are now from other people, dates, and places.
+ (What is CVS): For the most part, just refer to BUGS concerning
+ bug-cvs. Also tell people how to subscribe to bug-cvs.
+ (Credits): Say that list is not comprehensive and refer to
+ ChangeLog.
+
+Sat May 3 10:51:58 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (rcsinfo): Add comment about checkoutlist and
+ related topics.
+
+ * cvs.texinfo (Server temporary directory): New node.
+
+ * cvs.texinfo (Backing up): New node.
+
+ * cvs.texinfo (Repository): Be more explicit about the repository
+ and the working directory not being subdirectories of each other.
+
+Mon Apr 28 11:12:56 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Removing files): Use "*.c" not "?.c" in example;
+ the former should be good for both unix and DOS-like operating
+ systems. Document -f option. Refer to Invoking CVS for a full
+ list of options. Add a few comments.
+
+ * cvs.texinfo (Invoking CVS): For checkout and update, call them
+ "sticky options" not "sticky kopts".
+
+ * cvs.texinfo (Editing files): Add additional comments on get
+ vs. checkout.
+
+Sun Apr 27 16:17:06 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (commit): Only document the current flags (where -f
+ is force and -F file gets the message from a log file). We had
+ partly made this change on 9 Feb 1997, but some places got missed.
+
+ * RCSFILES: Add discussion of the common concern regarding
+ applying deltas to get to a branch head.
+
+ * DIFFUTILS-2.7-BUG: New file.
+
+ * cvs.texinfo (File status): Refer to "Invoking CVS", not
+ "status", for status options. Add paragraph about how "cvs -n -q
+ update" is another way to display file status.
+ (update examples): Removed; it had contained the "cvs -n -q
+ update" material.
+ (Invoking CVS): xref to "File status" and "Tags", not "status" and
+ "status options".
+ (status, status options): Removed.
+ (update options, checkout options): xref to "Invoking CVS"
+ not "status".
+
+ * cvsclient.texi (Requests): Clarify how long-lived Sticky and
+ Static-directory are.
+
+ * cvs.texinfo: Add @finalout.
+
+ * cvs.texinfo (Error messages): Add "cannot change permissions on
+ temporary directory" message.
+
+Wed Apr 23 12:53:45 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Document "add" in much more detail.
+
+Wed Apr 23 00:38:17 1997 Ian Lance Taylor <address@hidden>
+
+ * cvsclient.texi (Requests): Correct small typo (`a' for `as').
+
+Tue Apr 22 14:23:32 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Protocol Notes): Expand ideas on multisite
+ features somewhat. Add items about the network turnarounds for
+ pserver authentication and for protocol negotiation.
+
+Mon Apr 21 08:54:48 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Working directory storage): Describe what to do
+ with Entries.Log in more detail.
+
+ * cvsclient.texi (Responses): Say "CVS 1.9 and earlier" rather
+ than "pre version 1.10". The latter increases confusion by
+ referring to a version which doesn't exist yet.
+
+Mon Apr 21 01:02:53 1997 Ian Lance Taylor <address@hidden>
+
+ * cvsclient.texi (Responses): Document Rcs-diff. Indicate that
+ Patched is now deprecated in favor of Rcs-diff.
+
+Sun Apr 20 23:42:03 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Working directory storage): Add note about format
+ of timestamp and the "Result of merge" concept.
+
+Sat Apr 19 13:42:33 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): It is OK for Copy-file to implement
+ a rename instead of a copy.
+
+Fri Apr 18 12:05:48 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Assigning revisions): Say that -r implies -f.
+
+Thu Apr 17 16:34:14 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (From other version control systems): Add comment
+ about CMZ and PATCHY.
+
+Wed Apr 16 12:35:25 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): Add paragraph describing how
+ Copy-file relates to Merged.
+ (Responses): Add paragraph about how it is the server which
+ worries about not clobbering the user's file.
+
+Tue Apr 15 00:57:31 1997 Jim Kingdon <address@hidden>
+
+ * RCSFILES: Add notes on keyword expansion.
+
+ * cvs.texinfo (Rename by copying): Comment out seemingly erroneous
+ text regarding the revision number that the new file starts with.
+
+Mon Apr 14 12:37:35 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Clients should try to send
+ notifications right away.
+
+ * cvsclient.texi (Requests): For Notify request, clarify a few
+ future expansion situations. Specify the format of the time.
+
+ * cvsclient.texi (Requests): Clarify that arguments to co, rdiff,
+ and rtag are module names (and how that differs from file/directory
+ names).
+
+ * cvsclient.texi (Responses): Say that servers need to create
+ directories one at a time.
+
+Sat Apr 12 09:32:58 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Committing your changes): Say that editor default
+ is notepad (not vi) for Windows NT/95. Be more clear about what
+ "cvs commit" does. Add paragraph about timestamps.
+ (Environment variables, Global options, editinfo):
+ Add xrefs to that node.
+
+Thu Apr 10 15:48:39 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add "could not patch; will refetch".
+
+Wed Apr 9 15:21:11 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Working directory storage): New node.
+
+ * cvs.texinfo (Error messages): Add comment about "cvs co ." on
+ NT.
+
+Tue Apr 8 14:44:26 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Add diff3 usage message.
+
+Sun Apr 6 19:03:01 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Removing files): Add comment about undoing a "cvs
+ remove".
+
+ * cvsclient.texi (Requests): Explicitly mention the idea of
+ deferring "Notify" requests.
+
+Tue Apr 1 07:51:38 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): Add paragraph about directory
+ creation and empty directories.
+
+ * cvs.texinfo (Binary files): Add comment about binary files and
+ merges.
+
+ * cvsclient.texi (Requests): Add discussion of when to send
+ Is-modified.
+
+ * cvsclient.texi (Requests): Sending Is-modified is enough to
+ prevent the file from being considered "lost".
+
+Sun Mar 30 00:31:47 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Add Is-modified request. Clarify
+ order of Entry relative to Unchanged or Is-modified (might as well
+ specify the same thing vis-a-vis Modified while we are at it).
+
+Sat Mar 29 12:32:40 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi: Change "newline" to "linefeed". Most of the
+ document already reads "linefeed" and that is what is intended.
+ (File transmissions): New node, moved here from Requests.
+ (Goals, Filenames, File transmissions, new node Strings): Add
+ discussion of character sets and what we expect from the transport
+ protocol we run on.
+
+ * cvsclient.texi (Requests): Add paragraph about each Directory
+ request specifying a new local-directory and repository.
+
+ * cvsclient.texi (Requests): Add paragraph about renaming
+ local-directory in Directory request. Use "local-directory"
+ consistently instead of "working directory", for clarity.
+
+Fri Mar 28 13:59:59 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Make it clear that there is no
+ guarantee that one will get Clear-sticky instead of another
+ response. Also clarify that clients will tend to store the
+ repository in a long-term way.
+
+ * cvsclient.texi (Requests): Further clarify Directory example.
+
+ * cvsclient.texi (Requests): Add example and further explanation
+ of what expand-modules is for.
+
+ * cvsclient.texi (Requests): Add example, hopefully making it
+ clearer what REPOSITORY and LOCAL-DIRECTORY mean to Directory.
+
+ * cvs.texinfo (Attic): New node.
+ (rtag options): Adjust discussion of -a accordingly.
+ (Repository files): Adjust accordingly.
+
+Thu Mar 27 09:57:05 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): Give exact wording of broken pipe
+ error message.
+
+ * cvs.texinfo (history database): Add comment about various
+ problems with the history file.
+
+ * cvs.texinfo (Common options): The ISO8601 web page we had
+ mentioned in a comment is no more. Replace it with a new one.
+
+ * cvs.texinfo (Common options): "cvs history" also outputs dates.
+
+Wed Mar 26 10:54:21 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Common options): "cvs editors" also outputs dates.
+
+ * cvs.texinfo (Outside): Fix paragraph which said that revision
+ numbers start at 1.0. First of all, it is 1.1. Second of all, it
+ is sometimes 2.1, 3.1, etc. Third of all, the xref should be to
+ Assigning revisions not commit options.
+
+ * cvs.texinfo (Outside): Comment out sentence which incorrectly
+ stated that "cvs add" can operate on "foo/bar.c".
+
+Tue Mar 25 22:21:29 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Error messages): New node.
+ (Magic branch numbers): Move from Troubleshooting to Revisions and
+ branches. The former placement never made any sense to me.
+ (Revision numbers): Remove "Main trunk (intro)" index entry now
+ that this node is right next to the other "main trunk" index
+ entry.
+ (BUGS): Very briefly mention reporting bugs in CVS.
+
+ * cvs.texinfo (Compatibility): Add comment about "Nfoo" in CVS/Tag.
+
+Mon Mar 24 13:50:24 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Creating a branch): Add comment about -r in branch
+ example.
+
+ * cvsclient.texi (Responses): Discuss meaning of tagspec and
+ future expansion in Set-sticky. The behavior described is the one
+ which CVS has always implemented.
+
+Fri Mar 21 14:19:05 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Revise meaning of "Case" per change
+ to CVS.
+
+Tue Mar 18 15:50:47 1997 Jim Kingdon <address@hidden>
+
+ The following reorganization hopefully presents numeric revisions
+ in a slightly more coherent fashion. The only new material is the
+ paragraph about assigning revisions for added files.
+ * cvs.texinfo (A sample session): Bring in a sentence from Basic
+ concepts node, defining a repository.
+ (Revisions and branches): Renamed from Branches (it has always
+ covered non-branch tags too). Bring in nodes "Revision numbers" and
+ "Versions revisions releases" from Basic concepts, the former in
+ particular was way too detailed for an intro section.
+ (A sample session): Add comment about how we need an introduction
+ and what might go into one. Also bring in the paragraph from
+ Basic concepts introducing modules, but comment it out.
+ (Viewing differences): Add comment about
+ (Basic concepts): Removed; its content has been farmed out as
+ described above, and as the comment said, it was fundamentally
+ flawed.
+ (Assigning revisions): New node. Incorporates the "New major
+ release number" subsubsec which was in "commit examples". Add
+ paragraph concerning how CVS assigns revisions on added files.
+ (commit options): Refer to that node under -r.
+ (Invoking CVS): Add comment about text for -r.
+
+Tue Mar 18 13:04:30 1997 Jim Meyering <address@hidden>
+
+ * Makefile.in: (install-info): Depend on installdirs.
+
+Sun Mar 16 12:37:12 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (File permissions): CVSUMASK now works for RCS
+ files; but it is (still) awkward for client/server CVS.
+
+Sat Mar 15 17:41:12 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Magic branch numbers): Add comment about where this
+ should go.
+
+Thu Mar 13 09:11:36 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Credits): Fix grammatical mistake ("manual about"
+ -> "manual is about"). Reported by Philippe De Muyter.
+
+Sun Mar 9 09:06:40 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (File permissions): Add comment about val-tags and
+ CVSUMASK.
+
+Sun Mar 2 12:33:26 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (From scratch): Add comment about creating
+ directories with add rather than import.
+
+ * cvs.texinfo (Creating a repository): Add comment about how this
+ somewhat duplicates Server requirements.
+
+ * cvs.texinfo (Connecting via rsh): Add comment about rsh
+ vs. remsh. Also wording fix ("incorrect" -> "inapplicable").
+
+ * cvs.texinfo (Outside): Add comment about renames and annotate.
+
+ * cvs.texinfo (Server requirements): New node.
+
+Thu Feb 27 15:20:49 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Multiple developers): Reword section on "cvs admin
+ -l". As nearly as I can tell based on when it came up on info-cvs
+ and other contexts, people who are into reserved checkouts
+ generally find that cvs admin -l is OK. Add a bunch more notes
+ (inside @ignore) about reserved checkout implementation ideas.
+
+Sun Feb 23 16:12:03 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Common options): Add various additional comments
+ about date formats.
+
+ * RCSFILES: Remove diff for Id and explain it in words instead.
+ The previous values for Id had been clobbered by keyword expansion
+ on the RCSFILES file itself.
+
+Sat Feb 22 14:16:28 1997 Jim Kingdon <address@hidden>
+
+ * Makefile.in (DISTFILES): Fix typo (missing backslash).
+
+Fri Feb 21 23:08:38 1997 Jim Kingdon <address@hidden>
+
+ * RCSFILES: New file.
+ * Makefile.in (DISTFILES): Add RCSFILES.
+
+20 Feb 1997 Lenny Foner <address@hidden>
+
+ * cvs.texinfo (Checklist): Fix typo ("keword" -> "keyword").
+
+Thu Feb 20 21:57:05 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Keeping a checked out copy): Add "web" to index.
+
+Wed Feb 12 18:44:16 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Password authentication client, Invoking CVS):
+ Document "cvs logout" command.
+
+Tue Feb 11 20:42:45 1997 Ian Lance Taylor <address@hidden>
+
+ * cvs.texinfo (commit options): Document that the -f option to
+ commit disables recursion.
+
+Sun Feb 9 13:58:59 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (diff options): Document all the options we pass
+ through to diff. Remove paragraph about -D sometimes meaning
+ --ifdef since that is no longer true.
+
+ * cvs.texinfo (Multiple developers): Add lengthy comment about
+ reserved checkout design issues.
+
+ * cvs.texinfo (Wrappers): Add paragraph about timestamps.
+
+ * cvs.texinfo (commit options): Don't try to document what CVS 1.3
+ does with -f and how recent versions differ: 1.3 is pretty old
+ anyway, we generally only try to document the current version, and
+ the way it was described here was pretty confusing.
+ (Environment variables): Likewise for CVSEDITOR.
+
+ * cvs.texinfo (import output): Add index entries for symbolic
+ links. Add brief mention of whether behavior should be
+ different. Add comments on other symbolic link issues.
+
+Wed Feb 5 13:02:37 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Concurrency): Add comment about commit/commit
+ atomicity.
+
+Mon Feb 3 10:55:41 1997 joel boutros <address@hidden>
+
+ * cvs.texinfo (Connecting via rsh): Fix typo (programs -> problems).
+
+Fri Jan 31 12:18:47 1997 Ian Lance Taylor <address@hidden>
+
+ * cvsclient.texi (Connection and Authentication): Correct typo
+ (``sent'' for ``send''), and rewrite sentence for clarity.
+
+Fri Jan 24 10:31:57 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (File status): Change "Unresolved Conflict" to "File
+ had conflicts on merge" per change to CVS.
+
+Sun Jan 19 16:21:17 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (admin): Add comments about "group" and "compiled in
+ value". At least one info-cvs poster was confused by this.
+
+Thu Jan 16 17:54:51 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Wrappers): It is just -t/-f which doesn't work
+ client/server. -k *does* (well, except for the problem with
+ import noted in BUGS). -m I don't know and I doubt anyone cares.
+
+Mon Jan 13 15:41:02 1997 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (Read-only access): rephrase to imply that there may
+ be other administrative files, besides history and locks, which
+ read-only users can also affect (in the future, for example, the
+ `passwd' file).
+
+Wed Jan 8 14:50:47 1997 Jim Kingdon <address@hidden>
+
+ * Makefile.in: Remove CVSid; we decided to get rid
+ of these some time ago.
+
+Wed Jan 8 09:08:36 1997 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Connection and Authentication): Document
+ restriction that cvs root sent in the cvs protocol and in the
+ pserver authentication protocol must be identical.
+
+Thu Jan 2 13:30:56 1997 Jim Kingdon <address@hidden>
+
+ * Makefile.in, cvs.texinfo: Remove "675" paragraph;
+ see ../ChangeLog for rationale.
+
+Thu Jan 2 09:34:51 1997 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (Read-only access): new node.
+ (Repository): new menu item for above new node.
+ (Password authentication server): document the user-aliasing
+ feature. Why was this undocumented before?
+
+Wed Jan 1 18:12:11 1997 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Conflicts example): Use @asis in example to prevent
+ starting a line with a conflict marker. This means that when
+ maintaining the file with CVS itself, CVS will not think there is
+ a conflict merely because of the conflict marker in the example.
+ IMHO, this is totally bogus and CVS needs a better way of figuring
+ out whether a conflict is resolved (see comments elsewhere in this
+ node), but until then.... Credit to Fred Fish for reporting the
+ problem.
+
+ * cvs.texinfo (cvsignore): Add paragraph about how .cvsignore
+ files in the sources being imported by "cvs import" override
+ "-I !". Credit goes to Fred Fish for pointing out this problem.
+
+Thu Dec 19 12:36:46 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Credits): Update Roland Pesch email address per his
+ request.
+
+Tue Dec 17 12:57:56 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (verifymsg): In example, remove text "and reedit if
+ necessary"; it was copied from editinfo and doesn't apply here.
+ Fix syntax of if statement; remove unnecessary attempt at loop;
+ don't use -n with echo. Add @appendixsec at start of node.
+ Add note about how verifymsg cannot change log message.
+ (editinfo): In paragraph saying editinfo is obsolete, fix various
+ typos and formatting glitches. Mention -e as well as EDITOR.
+ (editinfo): In saying that editinfo doesn't get consulted with -m,
+ -F or client/server, recommend verifymsg. Remove comment which
+ says, in effect, "we need a feature like verifymsg".
+ (editinfo example): Change "verifymsg" back to "editinfo" here;
+ the example is of editinfo not verifymsg.
+
+Tue Dec 17 12:45:32 1996 Abe Feldman <address@hidden>
+
+ * cvs.texinfo (verifymsg): New node.
+ various places: Say that editinfo is obsolete, or refer to
+ verifymsg instead of editinfo
+
+Wed Dec 11 08:55:26 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Compatibility): Add comment about 1.3 and file death.
+
+ * cvs.texinfo (update output, release output): Document "P" as
+ well as "U".
+
+Tue Dec 10 16:23:40 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Builds): Change "make" to "implement" and "build";
+ in this context "make" is ambiguous.
+ (Builds): Add new URL of mk web page.
+
+Mon Dec 9 11:03:37 1996 Jim Blandy <address@hidden>
+
+ * cvs.texinfo (Password authentication client, Environment
+ variables): Remove mention of CVS_PASSWORD.
+
+Sun Dec 8 22:38:34 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Repository files): Mention differences between RCS
+ files in RCS and in CVS.
+ (Tags): Tag names must start with a letter.
+
+Fri Dec 6 09:08:18 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (syntax): Expand discussion of regular expression
+ syntax.
+
+Fri Nov 29 09:06:41 1996 address@hidden (Fred Fish)
+ and Jim Kingdon <address@hidden>
+
+ * cvs.texinfo, cvsclient.texi: Make sure @ref and friends are
+ followed by "," or "." as described in the texinfo manual. This
+ is a dubious practice as texi2html and texinfo.tex don't require
+ it, and makeinfo could insert them as needed, but since makeinfo
+ doesn't do that yet, cope.
+
+ * cvs.texinfo (From files): Suggest "diff -r" rather than "ls -R"
+ as the way to see that the sources seem to have been imported
+ correctly.
+ (Common options): -k is also available with import.
+ (admin options): Fix typo ("interrested" -> "interested").
+
+Mon Nov 25 10:03:56 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Common options): Add comments about two digit
+ years, year 2000, and ambiguous/nonexistent dates.
+
+Sun Nov 24 17:27:24 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (First import): Don't say what the wdiff program we
+ are using as an example does--that is confusing. Also don't show
+ untarring it--people might be familiar with cpio, ZIP, VMS BACKUP,
+ etc., instead of tar.
+
+ * cvs.texinfo (Adding files): Update comment about "cvs add -m".
+
+ * cvs.texinfo (Common options): Remove -H; -H is not a command
+ option.
+ (Global options): Also list --help and --version. Don't say that
+ -H gives a list of commands; it doesn't any more (directly).
+
+ * cvs.texinfo: Add comment pointing to paper size web page.
+
+ * cvs.texinfo (Common options): Rewrite section on date formats.
+ Executive summary is that RFC822 and ISO8601 are now preferred.
+
+Wed Nov 20 08:39:45 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Getting Notified): Add paragraph clarifying that
+ watches happen per user, not per working directory.
+
+Tue Nov 19 09:39:08 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Tags): Suggest that future special tag names might
+ start with ".". Fix typo.
+
+ * cvs.texinfo (Removing directories): -P is also available with
+ export.
+ (Moving directories): Rewrite first paragraph; now says that you
+ must use -P for the directory to disappear from working
+ directories. Thanks to Martin Lorentzon
+ <address@hidden> for reporting this bug.
+ (various): Where we mention -P, point to Removing directories
+ node.
+
+Sat Nov 16 18:03:22 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Example): Rewrite to actually be based on a real
+ live example (and therefore reflect the way the protocol currently
+ works). Add comment about formatting of the document itself.
+
+Thu Nov 14 10:22:58 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Introduction): Use @ref, not @xref, after "see".
+ (Goals): Rewrite items about locking, about uploading in big
+ chunks, and about atomicity to be focused more on the protocol
+ than the current implementation.
+ (Notes): Remove this node. The attempt to describe the basic
+ model has pretty much been replaced by the Introduction.
+ The material about how to start the client is incomplete and
+ better left to cvs.texinfo. And the item about the lack of
+ SERVER_FLOWCONTROL is obsolete now that SERVER_FLOWCONTROL is the
+ default.
+ (Protocol Notes): Add comment about multisite features.
+ (Requirements): Use @code for requests and responses.
+
+ * cvs.texinfo (Remote repositories): Add a few sentences defining
+ "client" and "server"; before we had been using the terms without
+ defining them.
+
+ * cvs.texinfo (What is CVS?): Add paragraph about reporting bugs.
+ Reword and expand comp.software.config-mgmt description (and add
+ comments about other newsgroup facts). Point people at GNU list
+ of FTP sites rather than directly at prep.ai.mit.edu.
+
+Wed Nov 6 09:45:08 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Tracking sources): Add comment regarding added and
+ removed files.
+
+Tue Nov 5 14:00:31 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Rename node "Invoking CVS" to "CVS commands".
+ Rewrite the intro and comments to reflect addition of the new
+ Invoking CVS.
+ (Invoking CVS): New node, a quick summary of each command.
+ (annotate): Don't list the options; refer to Invoking CVS and
+ Common options instead.
+
+Sun Nov 3 21:22:42 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Compatibility): New node, moved from ../README.
+
+ * cvs.texinfo (Common options): Add comment about how tar manual
+ contains documentation for getdate date formats.
+
+Fri Nov 1 14:00:31 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (commit examples): Rewrite "New major release
+ number" section to tighten up the wording, better motivate the
+ discussion, and replace the term "rcs revision number" with
+ "numeric revision".
+
+Fri Oct 25 07:49:21 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (loginfo): Don't say "a la printf"; the syntax is
+ only vaguely similar to printf.
+
+ * cvs.texinfo (loginfo): To get just the repository name, suggest
+ %{} instead of % "standing alone"; the latter is now an error.
+
+Tue Oct 22 13:08:54 1996 Noel Cragg <address@hidden>
+
+ * cvs.texinfo (loginfo): add information on the new loginfo format
+ string specification.
+
+Mon Oct 21 17:33:44 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Builds): New node.
+ (What is CVS?): Refer to it.
+
+Sat Oct 19 14:32:21 1996 Jim Meyering <address@hidden>
+ and Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Choosing a model): Wording/grammar fix.
+
+Sat Oct 19 14:32:21 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Obsolete): New node.
+ (Requests): Remove Repository and Lost and adjust Directory,
+ UseUnchanged, and other places accordingly.
+ (Required): Directory and Unchanged are now required.
+
+ * cvs.texinfo (Removing files): Don't talk about modules; they are
+ not relevant in this context.
+ (Removing directories): New node.
+ (Common options): Refer to it instead of duplicating information.
+
+Fri Oct 18 11:05:06 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (First import, import): Add paragraph about the fact
+ that import doesn't modify the directory which it imports from.
+
+ * cvs.texinfo (Creating a repository): Add paragraph about
+ resource requirements.
+
+ * cvs.texinfo (Copying): Replace empty node with a copy of the GPL.
+
+Thu Oct 17 12:10:55 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Adding files): Revise comment to more accurately
+ reflect the functioning/nonfunctioning status of cvs add -m.
+
+ * cvs.texinfo (Reverting local changes): New node, somewhat based
+ on the version of this node from 30 Sep 96 change.
+ (admin options): Refer to it.
+
+ * cvs.texinfo: Reinstate 30 Sep 96 change from A4 to US letter.
+
+ * cvs.texinfo (Concurrency): When telling people how to clean up
+ locks, tell them to make sure the locks are owned by the person
+ who has the stale locks.
+ (update output, release output): Remove text about how CVS doesn't
+ print "? foo" for directories; CVS has since been changed (see
+ conflicts-130 in sanity.sh).
+
+Wed Oct 16 15:01:42 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (history options): Mention new option -x E.
+
+Mon Oct 14 15:21:25 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Tags): Add paragraph on choosing a convention for
+ naming tags.
+
+Thu Oct 10 16:05:26 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (modules): Describe what & does.
+
+Mon Oct 7 17:20:11 1996 Ian Lance Taylor <address@hidden>
+
+ * cvs.texinfo (Removing files): Correct apparent cut and paste
+ error: refer to the removed file, not the added file.
+
+Tue Oct 1 14:15:33 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Revert all recent changes (the last unscathed one
+ is the CVSUMASK one from Sunday). For the most part said changes
+ are for new features which are not appropriate at this stage of
+ the release process. None of the changes being reverted need to
+ go into 1.9, that is for sure.
+
+Mon Sep 30 18:17:34 1996 Greg A. Woods <address@hidden>
+
+ * cvs.texinfo (Credits): add comment asking if we should update.
+ Add more detail about printing Letter on A4.
+ Add some comments about internal comments.
+ (From files): describe "cvs import -b 1" for importing existing
+ projects onto the main branch.
+ (First import): add a couple of helpful hints about naming vendor
+ and release tags, etc., and regularize the examples with this.
+ (Tracking sources): noted some reasons why you might use vendor
+ branches with "cvs import".
+ (Update imports): mention using "update" in place of "checkout" if
+ you have an existing working directory.
+ (Binary files in imports): add sub-menu separator comment.
+ (Tracking sources): new menu entry "Reverting to vendor release".
+ (Reverting to vendor release): new node to describe reverting
+ local changes and optionally using patch(1) to move local changes
+ forward.
+ (Global options): describe -D and -g, as well as DIFFBIN and
+ GREPBIN.
+ (export examples): add one.
+ (import options): describe the effect of '-b 1'.
+
+Mon Sep 30 08:09:53 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Adjust comments concerning A4 vs. US letter,
+ referring to ../README.
+
+ * cvs.texinfo (Common options): Add comment about dates which CVS
+ uses in output.
+
+Sun Sep 29 11:14:16 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Keyword list): Don't mention Name twice.
+
+ * cvs.texinfo (File permissions): Expand CVSUMASK stuff a bit.
+ (Setting a watch, Environment variables, Global options): Update
+ index entries for "read-only files, and ...".
+
+ * cvsclient.texi (Requests): State that Gzip-stream is preferred
+ to gzip-file-contents. Cite RFC1952/1951 rather than just "gzip".
+ Say that RFC1950/1951 compression is also known as "zlib".
+
+Sat Sep 28 09:31:45 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Repository): Move all information about the
+ internal structure of the repository to User modules node. Rename
+ it to "Repository storage" ("User modules" wasn't particularly
+ clear). Mention CVSUMASK. Much clarification and
+ reorganization.
+ (Basic concepts): Remove material which duplicates what is now in
+ Repository. Rewrite paragraph introducing modules.
+
+ * cvs.texinfo (Starting a new project): In discussing difficulty
+ in renaming files, don't refer to "cvs 1.x"--there is no
+ non-vaporous "cvs 2.x". Reword to reflect that part of the reason
+ to avoid renames (where possible) is not because of CVS at all, and
+ to try to give a general impression of how bad CVS issues involved in
+ renaming are.
+
+Fri Sep 27 04:23:44 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Adding files): Talk about directories, not modules,
+ since that is what is meant. Suggest using -kb option to add
+ rather than running cvs admin after the fact and xref to Binary
+ files not admin examples. Incorporate information which had been
+ in "add" node (there was a lot of duplication). Don't document
+ use of "add" on a directory to take the place of "cvs update -d";
+ the latter is simpler and more logical.
+ (add, add options, add examples): Removed.
+ (release output, release options): Update xrefs accordingly.
+ (Adding files, Removing files): Mention the fact that adds and
+ removes are branch-specific.
+ (Merging adds and removals): New node.
+
+ * cvs.texinfo (Concurrency): When mentioning RCS locks, use the
+ term reserved checkouts and xref to the place where we discuss
+ them in more depth.
+
+Thu Sep 26 08:26:01 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (log): Add comments about timezones.
+ (log, Common options): Add index entries for timezone and zone, time.
+
+Wed Sep 25 11:05:30 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (log options): Add xref to where we describe the
+ date formats that -d accepts.
+ (Common options): Don't refer to date formats accepted by co(1);
+ CVS's rules have never been the same. Add long whiny comment
+ about what a mess date formats are.
+
+Tue Sep 24 11:49:02 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (From other version control systems): The RCS file
+ must not be locked when you copy it to the CVS repository.
+
+ * cvs.texinfo (Editing files): Also discuss how to revert in the
+ non-watch case. Add some index entries.
+
+ * cvs.texinfo (update output): Add comment about how we *should*
+ be handling .# files. Mention fact that it is different under
+ VMS. Add .# to index.
+
+Fri Sep 20 13:08:33 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Multiple developers): Revise text on reserved
+ versus unreserved checkouts extensively. Move index entries for
+ "reserved checkouts" and "RCS-style locking" to here. Add
+ cross-reference to cvs admin -l. Add new section "Choosing a
+ model".
+ (Editing files): Add note about use of the word "checkout".
+
+Tue Sep 17 00:54:57 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Defining the module): Don't suggest "cvs co
+ modules"; that depends on a "modules" module being defined which
+ is not the default which is created by "cvs init". Instead
+ suggest "cvs co CVSROOT/modules" which should always work.
+
+Tue Sep 17 00:43:49 1996 VaX#n8 <address@hidden>
+ and Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Rename by copying): Suggest "cvs tag -d" on the file
+ "new", not on everything. Also don't suggest deleting branch tags.
+
+Tue Sep 17 00:34:39 1996 David A. Swierczek <address@hidden>
+
+ * Makefile.in (install-info): Note whether files are in srcdir and
+ deal with it rather than cd'ing into srcdir.
+
+Mon Sep 16 23:33:36 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Wrappers): Add comment about using wrappers to
+ compress files in the repository.
+
+ * cvs.texinfo (modules): Add comments about how we should be
+ documenting how -i and friends operate in client/server CVS.
+
+ * cvs.texinfo (File permissions): Describe the need for write
+ permissions for locks and val-tags.
+
+ * cvs.texinfo (commitinfo): Add comment about using commitinfo to
+ enforce who has access.
+
+Wed Jul 24 17:01:41 1996 Larry Jones <address@hidden>
+ and Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (checkout): Refer to "update output" node.
+ (import): Add new import output node.
+ (release): Correct release output menu entry (used to be
+ release options instead).
+ (update output): Say this is output from checkout as well as
+ update.
+
+Mon Sep 16 16:18:38 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Common options): Clarify that CVS uses MM/DD/YY dates.
+
+ * cvs.texinfo (Common options): Add comment about what HEAD means.
+
+Mon Sep 16 10:52:04 1996 Norbert Kiesel <address@hidden>
+
+ * cvs.texinfo (Global options): Document global '-T' option.
+
+Sat Sep 14 10:46:58 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Keeping a checked out copy): New node.
+
+Fri Sep 13 23:55:42 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Magic branch numbers): Delete song and dance about
+ how cvs log can't cope with magic branches because rlog doesn't
+ know about them; cvs log no longer calls rlog. Delete item about
+ how you can't specify a symbolic branch to cvs log; that is fixed.
+
+Wed Sep 11 22:48:21 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Password authentication server): Add comments
+ regarding port numbers and troubleshooting.
+
+Tue Sep 10 10:36:00 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (What is CVS?): Reword text regarding info-cvs,
+ to avoid overfull hbox.
+
+ * cvs.texinfo (Binary files): Add comment about further issues
+ with recovering from failure to use -kb.
+
+ * cvs.texinfo (Conflicts example): Describe the "feature" by which
+ CVS won't check in files with conflicts.
+ (File status): Expand and revise to document all the possible
+ statuses from cvs status. Also document "Working revision" and
+ "Repository revision". Refer to other sections for other aspects
+ of cvs status.
+ (status options): Refer to other sections as appropriate.
+ (update output): Refer user to Conflicts example node. Add
+ comment regarding purging of .# files.
+
+Fri Sep 6 11:47:14 1996 Ian Lance Taylor <address@hidden>
+
+ * cvs.texinfo (Kerberos authenticated): Mention need for
+ --enable-encryption option in order to use encryption.
+ (Global options): Likewise, in description of -x option.
+
+Thu Sep 5 14:31:42 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Connecting via rsh): Discuss :ext:, :server:, and
+ CVS_RSH.
+ (Remote repositories): Mention what default is if no access method
+ is specified.
+ (Environment variables): Don't discuss CVS_RSH at length here;
+ rely on reference to "Connecting via rsh" node.
+
+Mon Aug 26 15:39:18 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Protocol Notes): When talking about having the
+ client know the original contents of files, suggest cvs edit as a
+ solution.
+
+Thu Aug 22 10:44:40 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Keyword list): Document Name keyword.
+
+ * cvs.texinfo (Tags): Revise comment regarding legal tag names.
+
+Mon Aug 12 14:58:54 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Password authentication security): Add comment
+ about how some of this is not pserver-specific.
+
+Tue Aug 6 16:48:53 1996 Ian Lance Taylor <address@hidden>
+
+ * cvs.texinfo (log, log options): Update for changes to cvs log
+ now that it no longer invokes rlog.
+
+Thu Jul 25 10:10:16 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Fix typo (Kerberos-request ->
+ Kerberos-encrypt).
+
+Wed Jul 24 18:53:13 1996 Ian Lance Taylor <address@hidden>
+
+ * cvs.texinfo (Kerberos authenticated): Change the note that the
+ Kerberos connection is not encrypted.
+ (Global options): Add documentation for -x.
+ * cvsclient.texi (Protocol Notes): Remove enhancement note about
+ Kerberos encryption.
+ (Requests): Add documentation for Kerberos-encrypt request.
+
+Thu Jul 18 18:27:40 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Creating a repository): Mention need to be able to
+ create lock files in the repository.
+
+ * cvsclient.texi (Responses): In F response, make at least a
+ minimal attempt to define "flush".
+
+ * cvs.texinfo (Wrappers): Document -k.
+ (From files, Binary files in imports): Say that imports can deal
+ with binary files and refer to Wrappers node for details.
+ (Binary files): Likewise for imports and adds.
+
+Sat Jul 13 18:29:10 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Binary files): Add paragraph concerning the fact
+ that the keyword expansion mode is not versioned, and why this is
+ a problem.
+
+Fri Jul 12 18:55:06 1996 Ian Lance Taylor <address@hidden>
+
+ * cvsclient.texi (Requests): Document Gzip-stream.
+
+Thu Jul 11 21:51:45 1996 Ian Lance Taylor <address@hidden>
+
+ * cvsclient.texi (Responses): Document new "F" response.
+
+Wed Jul 10 18:46:39 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (log): Don't document "rlog"; it is deprecated.
+
+Sat Jul 6 22:07:45 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Environment variables): Document more temp
+ directory nonsense, this time with "patch".
+
+Fri Jul 5 23:27:40 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): Add comment regarding "/." ending.
+
+Fri Sep 13 10:52:09 1996 Greg A. Woods <address@hidden>
+
+ * cvs.texinfo: don't force afourpaper -- Letter prints much better
+ on A4 than the other way around, believe you me!
+ (rdiff options): describe -k and new -K.
+ (RCS keywords): add description of $Name.
+ (Using keywords): add description of #ident and example of using
+ $Name.
+ - also fixed cross references to Substitution modes in various
+ places.
+ (import options): mention that -b 1 imports to the trunk.
+
+Tue Jul 2 22:40:39 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Sticky tags): Update to reflect change in
+ "resurrected" message.
+
+Fri Jun 28 10:48:33 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Connecting via rsh): Add comment about what we
+ might be saying about troubleshooting.
+
+Sun Jun 23 10:07:45 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Password authentication security): Add comment
+ regarding anoncvs as practised by OpenBSD.
+
+Wed Jun 19 15:41:11 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Administrative files): Add xref to Intro
+ administrative files.
+ (Intro administrative files): Add comment suggesting future
+ reorganizations of this material.
+ (syntax): Add comment regarding this node.
+ (Getting Notified): Actually document the notify file. It hadn't
+ really been documented to speak of.
+ (editinfo,loginfo,rcsfino,cvsignore): Make the index entries
+ follow the standard "foo (admin file)" format.
+
+Fri Jun 14 18:14:32 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (editinfo): Discuss the way editinfo falls down in
+ the face of -m or -F options to commit, or remote CVS.
+
+Thu Jun 13 15:08:27 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Watches): Add comment discussing the
+ fact that using cvs edit instead of chmod is not enforced.
+
+ * cvs.texinfo (Setting up): Add index entry for "init (subcommand)".
+ (Creating a repository): Move contents of node Setting up here...
+ (Setting up): ...and remove this node.
+ (Creating a repository): Don't refer to the INSTALL file (it just
+ refers back to us!).
+
+ * cvsclient.texi (Responses): Document the fact that the server
+ should send data only when the client is expecting responses.
+
+Wed Jun 12 16:04:48 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Entries Lines): Add comment regarding specifying
+ the meaning of "any other" data, in the conflict field.
+ (Example): Make it clear that using a separate connection for each
+ command is not required by the protocol. Add some comments
+ regarding ways in which the example is out of date or wrong.
+
+Fri Jun 7 18:02:36 1996 Ian Lance Taylor <address@hidden>
+ and Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (annotate): Document new -r, -D, and -f options.
+
+Fri Jun 7 16:59:47 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Invoking CVS): Add comment describing why only some
+ commands are listed here.
+ (Structure, Environment variables): Don't describe CVS as a
+ front-end to RCS.
+
+Tue Jun 4 21:19:42 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): Document Created and Update-existing.
+
+Mon Jun 3 17:01:02 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): Clarify "diff -c" versus "diff -u"
+ format in Patched response. Don't specify how the client must
+ implement its patch-applying functionality.
+
+Sun May 26 17:12:24 1996 Norbert Kiesel <address@hidden>
+
+ * cvs.texinfo (tag options) Document option "-c".
+
+Thu May 23 21:11:56 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Credits): Rewrite section on FAQ to reflect the
+ fact that FAQ is no longer maintained.
+ (What is CVS?): Mention comp.software.config-mgmt as well as
+ info-cvs. Mention the fact that info-cvs-request can be slow in
+ responding.
+ (What is CVS?): Rather than say that cvs is not a configuration
+ mangement system, say specifically what it lacks (change control,
+ etc.). I added process control (which was sorely lacking from the
+ list of configuration management functionality), and deleted some
+ functions such as tape construction which are not provided by the
+ well-known configuration management systems.
+
+ * cvs.texinfo (checkout options): Add comment regarding
+ subdirectories (lack of clarity pointed out by address@hidden).
+ Add comment about that infernal "short as possible" wording.
+
+ * cvs.texinfo (Global options): Fix error ("diff" -> "log")
+ (reported by address@hidden).
+ Remove footnote "Yes, this really should be fixed, and it's being
+ worked on"--it isn't clear what "this" is, and I doubt anyone is
+ working on it.
+
+Tue May 21 17:22:18 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Clarify Directory with "." as local
+ directory, and that filename for Questionable cannot contain "/".
+
+Mon May 20 13:15:25 1996 Greg A. Woods <address@hidden>
+
+ * cvs.texinfo (rdiff): description from main.c:cmd_usage
+ (rtag): description from main.c:cmd_usage
+ (status): description from main.c:cmd_usage
+ (tag): description from main.c:cmd_usage
+ [all for the sake of consistency]
+
+Fri May 17 11:42:46 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Add index entries for :local:, etc.
+ (Password authentication server): Revert erroneous change
+ regarding the format of CVSROOT/passwd file.
+
+Thu May 16 17:06:46 1996 Noel Cragg <address@hidden>
+
+ * cvsclient.texi (Notes): Removed paragraphs about various server
+ invocations which are now described in full in node "Connection
+ and Authentication."
+ (Requests): Include a note that "gzip-file-contents" doesn't
+ follow the upper/lowercase convention and that unknown reqests
+ always elicit a response, regardless of capitalization.
+
+ * cvs.texinfo (Kerberos authenticated): Removed bogus version
+ number.
+ (Repository): explain the ":local:" access method.
+
+Wed May 15 23:43:04 1996 Noel Cragg <address@hidden>
+
+ * cvsclient.texi (Goals): mention access methods.
+ (Requests): add note about convention: requests starting with a
+ captial letter don't have any expected response. Made sure each
+ request has a "Response expected" note.
+
+ * cvs.texinfo (Remote repositories): add info about access
+ methods; fix pserver info.
+
+Tue May 14 08:56:41 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Environment variables): Try to document somewhat
+ more accurately where we put temporary files.
+
+ * cvs.texinfo (From files): Say directory tree instead of module
+ where that is what we mean. Use @var{wdir} and @var{rdir} in the
+ example instead of using @var{dir} for two different things.
+ (From files): Say directory tree instead of module
+ where that is what we mean.
+ (Binary files): When using cvs admin -kb, one needs an extra
+ commit step on non-unix systems.
+ (Binary files in imports): New node.
+ (Wrappers): Add comment regarding indent example.
+ (Top): Don't refer to modules when that is not what we mean.
+
+Fri May 10 09:39:49 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Sticky tags): Explain what sticky dates and
+ non-branch sticky tags are good for.
+
+ * cvs.texinfo (Repository): Document that -d overrides CVS/Root.
+
+Wed May 1 15:38:26 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Tags): Document un-revision of all-uppercase tag
+ names.
+
+Wed Apr 24 08:41:51 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Password authentication security): Rewrite sentence
+ on complex and unknown security bugs to clarify that it is
+ referring to people who have been give access to cvs, not to holes
+ in the authentication method (which is relatively simple).
+
+Tue Apr 23 09:31:29 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Wrappers): Talk about what -m does (and does not
+ do). Other minor edits.
+
+Wed Apr 17 15:27:03 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (rcsinfo): Rewrite paragraph concerning remote CVS.
+ * cvsclient.texi (Responses): Document Template response.
+
+Sun Apr 14 16:01:39 1996 Karl Fogel <address@hidden>
+
+ * .cvsignore: added CVSvn.texi.
+
+Wed Apr 10 16:56:21 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (~/.cvsrc): Mention setting global options with "cvs".
+
+ * cvs.texinfo (release): Change "modules" to "directories".
+ Release does not take module names as arguments.
+
+ * cvs.texinfo (Creating a branch): Add comments about how we
+ should better document tagging the branchpoint.
+
+Tue Apr 9 19:59:45 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Top): Use @value{CVSVN}, not a vague refenece to 1.4.
+
+ * cvs.texinfo (From other version control systems): New node.
+
+Mon Apr 8 15:59:37 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Connection and Authentication): Revise kerberos
+ and pserver sections to reflect the fact that port 2401 is now
+ officially registered.
+
+Thu Mar 28 09:51:13 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (History browsing): Reinstate this node. Try to get
+ it into some minimally useful state (it still needs a lot of
+ work).
+ (annotate): New node, subnode of History browing.
+
+ * cvsclient.texi (Requests): Add annotate request.
+
+Tue Mar 26 08:46:39 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: In various examples, change tag names to avoid tag
+ names reserved to CVS.
+
+ * cvs.texinfo (Tags): Document what is a valid tag name.
+
+ * cvs.texinfo (Substitution modes): Try to describe how the
+ various keyword expansion settings interract.
+ (Binary files): Suggest cvs update -A, not removing file and then
+ updating it, to get effect of new keyword expansion options.
+
+ * cvs.texinfo (admin options): Mention CVS's use of `dead' state.
+
+Thu Mar 21 08:25:17 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Environment variables): Expand introduction to RCS
+ environment variables. Expand and correct CVS_SERVER_SLEEP.
+
+ * cvs.texinfo (Environment variables): Remove POSIXLY_CORRECT; cvs
+ requires options to precede arguments regardless of it.
+
+Thu Mar 21 08:18:42 1996 Norbert Kiesel <address@hidden>
+
+ * cvs.texinfo: Remove paragrahps about a forthcoming CVS
+ newsgroup and about sending patches to think.com.
+ (Environment): Document some more (all?) used environment
+ variables.
+
+Wed Mar 20 09:44:21 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Introduction): New node.
+ * Makefile.in: Add cruft to reflect fact that cvsclient.texi now
+ uses CVSvn.texi.
+
+Mon Mar 18 14:43:53 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Add Case request.
+
+Wed Mar 13 16:01:47 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Connection and Authentication): New node.
+
+ * cvsclient.texi (Requests): Expand discussion of Root a bit.
+
+ * cvs.texinfo (Setting up): Don't refer to INSTALL file; revise to
+ reflect some information which had been in the INSTALL file.
+
+ * cvs.texinfo (history file): Update to reflect cvsinit -> cvs
+ init. Adjust discussion of whether history file format is
+ documented.
+ (Setting up): Update to reflect cvsinit -> cvs init.
+
+ * cvsclient.texi (Requests): Document init request.
+
+Thu Feb 29 10:08:31 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (loginfo example): Adjust example to reflect the way
+ that CVS actually works. Add comments questioning whether that is
+ the best behavior.
+
+ * cvs.texinfo (cvsignore): Document additions to default ignore list.
+
+Mon Feb 26 13:48:01 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Filenames): New node, documents / vs \, etc.
+
+Wed Feb 24 1996 Marcus Daniels <address@hidden>
+
+ * cvs.texinfo (Password authentication server): Mention
+ support for imaginary usernames.
+
+Thu Feb 15 16:34:56 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Variables): Add new internal variable $USER.
+
+Wed Feb 14 22:52:58 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (export, admin): Document -k option to cvs export.
+
+ * cvs.texinfo (admin options): Mention using -l, -u, -L, and -U in
+ conjunction with rcslock.pl.
+
+Mon Feb 12 16:38:41 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Remove references to mkmodules.
+
+Sun Feb 11 12:31:36 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi: Add Set request.
+
+ * cvs.texinfo (Variables): Rewrite to reflect user variables
+ replacing environment variables; motivate the discussion better.
+ (Global options): Add -s option.
+
+Sat Feb 10 11:18:37 1996 Jim Blandy <address@hidden>
+
+ * cvs.texinfo (Variables): Fix @table commands.
+
+Fri Feb 9 17:31:18 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Variables): New node.
+
+ * Makefile.in (CVSvn.texi): New rule.
+ (OBJDIR_DISTFILES): Add CVSvn.texi.
+ (cvs.dvi,cvs.info): Add cruft to deal with it being in build dir
+ or srcdir.
+ * cvs.texinfo: Include CVSvn.texi and use the version number from
+ it instead of a hardcoded version number and date.
+
+Thu Feb 1 13:28:03 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Sticky tags): Expand so it really documents the
+ features it is talking about rather than referring to "Appendix
+ A". Add example of how to restore the old version of a dead
+ file. In various other parts of the manual refer to this node, in
+ some cases deleting duplicative text. In the case of cvs admin
+ -b, mention vendor branch usage.
+ (Removing files): Discuss removing files (in user-visible terms,
+ not in terms of the Attic and such).
+ (remove): Remove node; merge contents into Removing files.
+
+Tue Jan 30 17:52:06 1996 Jim Blandy <address@hidden>
+
+ * cvs.texinfo: Tweak @top node, to make file compatible with both
+ makeinfo and texinfo-format-buffer. Perhaps we should fix the
+ formatters to agree on what constitutes valid texinfo.
+
+Mon Jan 29 16:38:33 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requirements): New node, to talk about required
+ versus optional parts of the protocol.
+
+Sun Jan 28 09:00:34 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Modes): Add discussion what what the mode really
+ means (across diverse operating systems).
+
+Tue Jan 23 12:54:57 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Per mail from Per Cederqvist, change author to "Per
+ Cederqvist et al". Also remove sentence about Signum shipping
+ hardcopy manuals and add information on Cyclic. Change version
+ number to 1.6.87.
+
+Fri Jan 12 15:29:39 1996 Vince Demarco <address@hidden>
+
+ * cvs.texinfo: Fix the documentation for the com/uncom change
+ to wrap/unwrap. make everything consistant
+
+Wed Jan 10 16:11:54 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Concurrency): Add index entries; minor clarification.
+
+Tue Jan 9 16:03:39 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Getting Notified): Document users file.
+
+ * cvs.texinfo (cvsignore): Add *.obj to list of ignored files.
+
+Wed Jan 3 17:01:58 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (import): Adjust list of ignored files to match
+ recent change to CVS (CVS* -> CVS CVS.adm). Consolidate
+ discussion of ignored files in one place (with xrefs from others).
+
+ * cvsclient.texi: Remove How To node. It was out of date
+ (again!), and I am getting sick of trying to update it (internals
+ documentation should be in the comments, where it at least has a
+ fighting chance of staying up to date).
+ (Protocol): Say what \n and \t mean in this document.
+
+Tue Jan 2 23:39:32 1996 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Wrappers): Change comb/uncom to wrap/unwrap.
+
+Mon Jan 2 23:00:00 1996 Vince Demarco <address@hidden>
+
+ * cvs.texinfo: update the Wrappers documentation so it isn't
+ so NEXTSTEP centric. The wrappers code has alot of other
+ general uses. The new version of the documentation tryes
+ to show that to the reader.
+
+Mon Jan 1 13:09:39 1996 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): Clarify that Module-expansion is not
+ suitable for passing to co.
+
+Sun Dec 31 10:53:47 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Password authentication server): Suggest specifying
+ -b in inetd.conf.
+
+ * cvs.texinfo (Password authentication): Variety of cleanups and
+ minor fixes, including shorter node names.
+
+Sun Dec 24 02:37:51 1995 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (Using the client with password authentication):
+ tixed fypos.
+
+Sun Dec 24 00:00:16 1995 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (Remote repositories): use @code{rsh} most places,
+ because it is the name of a program, and because I am a pedant.
+ Refer to new node "Password authenticated".
+ (Password authenticated): new node.
+ (Setting up the server for password authentication): new node.
+ (Using the client with password authentication): new node.
+ (Security considerations with password authentication): new node.
+
+ These are all really long node names, but it seems necessary that
+ they be descriptive in case they're referenced elsewhere. If you
+ can think of a way out of this, please change them.
+
+Thu Dec 21 12:09:34 1995 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Requests): Add Questionable. Revise
+ documentation of export and update to explain role of -I option.
+
+Tue Dec 19 16:44:18 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Update binary files info for -kb.
+
+Mon Dec 11 12:20:55 1995 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Responses): Add Notified and Mode.
+ (Requests): Add Notify, noop, watch-on, watch-off, watch-add,
+ watch-remove, watchers, and editors.
+ * cvs.texinfo (Watches): New node, to describe new developer
+ communication features.
+
+Thu Nov 23 08:59:09 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (admin options): In saying that cvs admin -o is not
+ such a good way to undo a change, refer to the section which
+ describes the preferred way.
+
+Thu Nov 13 16:39:03 1995 Fred Fish <address@hidden>
+
+ * Makefile.in: Remove extraneous tab from empty line.
+
+Mon Nov 13 15:00:26 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Concurrency): New node, to describe user-visible
+ behaviors associated with cvs locks.
+
+ * cvs.texinfo (Remote repositories): Add more details of how to
+ set things up (with rsh and kerberos).
+
+Thu Nov 9 11:41:37 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Remove -Q and -q options from command synopses.
+
+Wed Nov 8 09:38:00 1995 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (Notes): Revise paragraph on server memory use
+ problem.
+
+Tue Nov 7 16:26:39 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Document merging more than once from a branch;
+ miscellaneous cleanups.
+
+Mon Oct 30 13:12:53 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (modules): Document -e.
+
+Thu Oct 26 11:15:40 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Tags): Update "version" vs. "revision" for CVS 1.5.
+ (Index,BUGS): Change bug reporting address from Per Cederqvist to
+ address@hidden
+
+Wed Oct 25 15:37:05 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: Miscellaneous minor changes (clean up CVS/Root
+ stuff, don't say release requires a module entry, etc.).
+
+Tue Oct 24 11:01:22 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo: More precisely describe scope of document.
+ * cvsclient.texi: Describe scope of document
+
+Thu Oct 12 11:25:40 1995 Karl Fogel <address@hidden>
+
+ * cvs.texinfo: cover page now refers to CVS 1.6, and "last
+ updated" date has been upped to today.
+
+Wed Oct 11 22:30:10 1995 Jim Kingdon <address@hidden>
+
+ * Makefile.in (info): Look for *.info* either in build dir or in
+ srcdir.
+
+Mon Oct 2 17:10:49 1995 Norbert Kiesel <address@hidden>
+
+ * cvs.texinfo (admin): Describe usage of CVS_ADMIN_GROUP to
+ restrict usage of admin.
+
+Fri Oct 6 21:17:50 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (~/.cvsrc): Document change to command name matching.
+
+Thu Oct 5 18:03:41 1995 Jim Kingdon <address@hidden>
+
+ * Makefile.in (install-info): Add comment about srcdir.
+
+Wed Sep 13 12:45:53 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Moving files): Rewrite "Outside" node to clarify
+ that history is still there and describe how to get it. Assorted
+ cleanups.
+
+Tue Sep 12 19:02:47 1995 Jim Kingdon <address@hidden>
+
+ * cvs.texinfo (Removing files): Remove section on limitations
+ which are gone now that we have death support.
+
+Wed Aug 30 12:32:29 1995 Karl Fogel <address@hidden>
+
+ * cvs.texinfo (Remote Repositories): new node, referred to from
+ `Basics' and `Repository'.
+ (Repository): documented new `-d' vs. `$CVSROOT' vs. `CVS/Root'
+ behavior.
+ (commitinfo): document client/server-case behavior.
+ (editinfo): document client/server-case behavior.
+ (loginfo): document client/server-case behavior.
+ (rcsinfo): document client/server-case behavior.
+
+Mon Aug 21 00:23:45 1995 Jim Kingdon <address@hidden>
+
+ * cvsclient.texi (How To): The way to force rsh is to set
+ CVS_CLIENT_PORT to -1, not to some bogus value.
+
+Tue Aug 15 17:12:08 1995 Karl Fogel <address@hidden>
+
+ * cvs.texinfo
+ (Basic concepts): talk about remote repositories.
+ (Repository): same.
+
+Mon Jul 24 19:09:12 1995 James Kingdon <address@hidden>
+
+ * cvs.texinfo: Remove references to -q and -Q command options.
+
+Fri Jul 21 10:33:07 1995 Vince DeMarco <address@hidden>
+
+ * cvs.texinfo: Changes for CVSEDITOR and wrappers.
+
+Thu Jul 13 23:04:12 CDT 1995 Jim Meyering (address@hidden)
+
+ * Makefile.in (cvs-paper.ps): *Never* redirect output directly to
+ the target (usu $@) of a rule. Instead, redirect to a temporary
+ file, and then move that temporary to the target. I chose to
+ name temporary files address@hidden Remember to be careful that the
length
+ of the temporary file name not exceed the 14-character limit.
+
+Sun Jul 9 19:03:00 1995 Greg A. Woods <address@hidden>
+
+ * doc/cvs.texinfo:
+ - document '-q' for 'cvs status'
+ - correction to regexp use in *info files
+ - correction to use of 'cvsinit' script
+ (from previous local changes)
+
+Tue Jun 20 18:57:55 1995 James Kingdon <address@hidden>
+
+ * Makefile.in (dist-dir): Depend on $(OBJDIR_DISTFILES).
+
+Fri Jun 16 21:56:16 1995 Karl Fogel <address@hidden>
+ and Jim Meyering <address@hidden>
+
+ * update.c (update_file_proc): If noexec, just write 'C', don't merge.
+
+Fri Jun 16 07:56:04 1995 Jim Kingdon (address@hidden)
+
+ * cvs-paper.ps: Added.
+
+Sat May 27 08:46:00 1995 Jim Meyering (address@hidden)
+
+ * Makefile.in (Makefile): Regenerate only Makefile in current
+ directory when Makefile.in is out of date. Depend on ../config.status.
+
+Sat May 27 08:08:18 1995 Jim Meyering (address@hidden)
+
+ * doc/Makefile.in (realclean): Remove more postscript and info files.
+
+Fri Apr 28 22:44:06 1995 Jim Blandy <address@hidden>
+
+ * Makefile.in (DISTFILES): Updated.
+ (doc): Depend on cvsclient.ps too.
+ (cvs.aux, cvsclient.aux): Add target.
+ (cvsclient.dvi): Don't nuke the aux file. They're small and
+ helpful.
+ (cvsclient.ps): New target.
+ (dist-dir): Renamed from dist; changed to work with DISTDIR
+ variable from parent.
+
+Sun Apr 23 22:13:18 1995 Noel Cragg <address@hidden>
+
+ * Makefile: Added more files to the `clean' target.
+ * .cvsignore: Added the same files.
+
+Mon Nov 28 10:22:46 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Notes): Remove item about commit options; now
+ fixed. Rewrite paragraph about server memory usage.
+
+ * cvsclient.texi (Responses): Add Set-checkin-prog and
+ Set-update-prog.
+ (Requests): Add Checkin-prog and Update-prog.
+ * cvsclient.texi (TODO): Remove last item (it is fixed) and node.
+
+Fri Nov 18 16:51:36 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Requests): Add Max-dotdot.
+
+Thu Nov 3 07:04:24 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Protocol): Add Directory request.
+ (TODO): Remove item about renaming directories.
+ (Protocol): Change @subheading to @node/@section.
+
+Fri Oct 28 07:51:13 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Protocol): Add expand-module request and
+ Module-expansion response.
+ (Protocol Notes, TODO): Remove items about cvs co funkiness.
+
+Wed Oct 12 19:49:36 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Protocol): Add Copy-file response.
+
+ * cvsclient.texi (How To): Correct item about where declaration
+ of cvs commands go.
+
+ * cvsclient.texi (Protocol): Add new commands. Merge description
+ of how commands work which was duplicated among the various
+ commands. Formatting cleanups.
+ (TODO): Remove item about bad error message on checking in a
+ nonexistent file; this works now (presumably fixed by the
+ Unchanged stuff).
+ (Notes): Remove thing about trying unsupported commands via NFS,
+ rdist, etc. Also remove item about some commands not being
+ supported. There are no unsupported commands anymore.
+
+Tue Sep 13 13:28:52 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Protocol): Document New-entry response.
+
+Mon Sep 12 06:35:15 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Protocol): Clarify that checksum is of patched
+ file, not patch itself. Fix typo (valid-requests -> Valid-requests).
+
+ * cvsclient.texi (Protocol): Document Sticky request and
+ Set-sticky and Clear-sticky responses.
+ (Notes): Remove sticky tags from todo list.
+
+Thu Sep 8 14:23:58 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Protocol): Document Static-directory requests
+ and Set-static-directory and Clear-static-directory responses.
+ (Notes): Remove Entries.Static support from todo list.
+
+ * cvsclient.texi (Protocol): Document Unchanged and UseUnchanged
+ requests. Update documentation of Entry and Lost accordingly.
+
+Mon Aug 22 14:08:21 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Goals): Remove mention of rsh.
+ (Protocol Notes, TODO): Remove compression item.
+ (Protocol): Document "status" request.
+ (TODO): Remove suggestion to add "cvs status".
+
+Tue Jul 19 10:02:53 1994 Ian Lance Taylor (address@hidden)
+
+ * Makefile.in (install-info): Do not depend upon installdirs.
+
+Fri Jul 15 12:56:53 1994 Ian Lance Taylor (address@hidden)
+
+ * Makefile.in (all): Do not depend upon info.
+ (install): Do not depend upon install-info.
+
+Thu Jul 7 20:43:12 1994 Ian Lance Taylor (address@hidden)
+
+ * cvsclient.texi (Protocol): Add Checksum response.
+
+Thu Jun 30 15:16:50 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Protocol): Add Global_option request.
+
+Wed Jun 29 14:09:42 1994 Ian Lance Taylor (address@hidden)
+
+ * cvsclient.texi: Describe sending patches, including the dummy
+ update-patches request and the Patched response. Mention Kerberos
+ authentication using ``cvs kserver''. Some other minor changes.
+
+Tue Jun 28 15:21:06 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Protocol Notes): Remove note about sending diffs
+ in Updated; Ian did it. Remove note about adding encryption to rsh.
+
+Sat May 7 10:44:30 1994 Jim Kingdon (address@hidden)
+
+ * cvsclient.texi (Protocol): Document Modified without Entry. Add
+ `add' and `remove' and `Remove-entry'. Formatting cleanups.
+
+Tue Apr 19 01:29:04 1994 John Gilmore (address@hidden)
+
+ * cvsclient.texi: New node How To; cleanups throughout.
+ * Makefile.in: Add dependencies on cvsclient.texi.
+
Index: ccvs/doc/cvs.texinfo
diff -u /dev/null ccvs/doc/cvs.texinfo:1.674.2.1
--- /dev/null Tue Jan 17 15:42:47 2006
+++ ccvs/doc/cvs.texinfo Tue Jan 17 15:42:46 2006
@@ -0,0 +1,16143 @@
+\input texinfo @c -*-texinfo-*-
address@hidden Documentation for CVS.
address@hidden cvs.info
address@hidden copyleftnotice
address@hidden
+Copyright @copyright{} 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
+ 2001, 2002, 2003, 2004, 2005
+ Free Software Foundation, Inc.
+
address@hidden @columnfractions .12 .88
address@hidden Portions
address@hidden @tab Copyright @copyright{} 1999, 2000, 2001, 2002, 2003, 2004,
2005
+ Derek R. Price,
address@hidden @tab Copyright @copyright{} 2002, 2003, 2004, 2005
+ Ximbiot @url{http://ximbiot.com},
address@hidden @tab Copyright @copyright{} 1992, 1993, 1999 Signum Support AB,
address@hidden @tab and Copyright @copyright{} others.
address@hidden multitable
+
address@hidden
+Permission is granted to process this file through Tex and print the
+results, provided the printed document carries copying permission
+notice identical to this one except for the removal of this paragraph
+(this paragraph not being relevant to the printed manual).
+
address@hidden ignore
+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
+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 this permission notice may be stated in a translation
+approved by the Free Software Foundation.
address@hidden macro
+
address@hidden This file is part of the CVS distribution.
+
address@hidden CVS is free software; you can redistribute it and/or modify
address@hidden it under the terms of the GNU General Public License as
published by
address@hidden the Free Software Foundation; either version 2, or (at your
option)
address@hidden any later version.
+
address@hidden CVS is distributed in the hope that it will be useful,
address@hidden but WITHOUT ANY WARRANTY; without even the implied warranty of
address@hidden MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
address@hidden GNU General Public License for more details.
+
address@hidden See ../README for A4 vs. US letter size.
address@hidden When we provided A4 postscript, and people tried to
address@hidden print it on US letter, the usual complaint was that the
address@hidden page numbers would get cut off.
address@hidden If one prints US letter on A4, reportedly there is
address@hidden some extra space at the top and/or bottom, and the side
address@hidden margins are a bit narrow, but no text is lost.
address@hidden
address@hidden See
address@hidden http://www.ft.uni-erlangen.de/~mskuhn/iso-paper.html
address@hidden for more on paper sizes. Insuring that margins are
address@hidden big enough to print on either A4 or US letter does
address@hidden indeed seem to be the usual approach (RFC2346).
+
address@hidden This document seems to get overfull hboxes with some
address@hidden frequency (probably because the tendency is to
address@hidden sanity-check it with "make info" and run TeX less
address@hidden often). The big ugly boxes just seem to add insult
address@hidden to injury, and I'm not aware of them helping to fix
address@hidden the overfull hboxes at all.
address@hidden
+
address@hidden version.texi
address@hidden CVS---Concurrent Versions System address@hidden
address@hidden odd
+
address@hidden -- TODO list:
address@hidden -- Fix all lines that match "address@hidden -- "
address@hidden -- Also places marked with FIXME should be manual
address@hidden problems (as opposed to FIXCVS for CVS problems).
+
address@hidden @splitrcskeyword{} is used to avoid keyword expansion. It is
replaced by
address@hidden @asis when generating info and dvi, and by <i></i> in the
generated html,
address@hidden such that keywords are not expanded in the generated html.
address@hidden
address@hidden splitrcskeyword {arg}
address@hidden
address@hidden macro
address@hidden ifnothtml
+
address@hidden
address@hidden splitrcskeyword {arg}
address@hidden
address@hidden macro
address@hidden ifhtml
+
address@hidden GNU Packages
address@hidden
+* CVS: (cvs). Concurrent Versions System
address@hidden direntry
address@hidden Individual utilities
address@hidden
+* cvs: (cvs)CVS commands. Concurrent Versions System
address@hidden direntry
+
address@hidden The titlepage section does not appear in the Info file.
address@hidden
address@hidden 4
address@hidden The title is printed in a large font.
address@hidden @titlefont{Version Management}
address@hidden
address@hidden @titlefont{with}
address@hidden
address@hidden @titlefont{CVS}
address@hidden 2
address@hidden for @sc{cvs} @value{VERSION}
address@hidden -release-
address@hidden 3
address@hidden Per Cederqvist et al
+
address@hidden The following two commands start the copyright page
address@hidden for the printed manual. This will not appear in the Info file.
address@hidden
address@hidden 0pt plus 1filll
address@hidden
address@hidden titlepage
+
address@hidden
+
address@hidden
+
address@hidden ================================================================
address@hidden The real text starts here
address@hidden ================================================================
+
address@hidden
address@hidden
---------------------------------------------------------------------
address@hidden Top
address@hidden
+
+This info manual describes how to use and administer
address@hidden version @value{VERSION}.
address@hidden ifnottex
+
address@hidden
address@hidden
address@hidden ifinfo
+
address@hidden This menu is pretty long. Not sure how easily that
address@hidden can be fixed (no brilliant ideas right away)...
address@hidden
+* Overview:: An introduction to CVS
+* Repository:: Where all your sources are stored
+* Starting a new project:: Starting a project with CVS
+* Revisions:: Numeric and symbolic names for revisions
+* Branching and merging:: Diverging/rejoining branches of development
+* Recursive behavior:: CVS descends directories
+* Adding and removing:: Adding/removing/renaming files/directories
+* History browsing:: Viewing the history of files in various ways
+
+CVS and the Real World.
+-----------------------
+* Binary files:: CVS can handle binary files
+* Multiple developers:: How CVS helps a group of developers
+* Revision management:: Policy questions for revision management
+* Keyword substitution:: CVS can include the revision inside the file
+* Tracking sources:: Tracking third-party sources
+* Builds:: Issues related to CVS and builds
+* Special Files:: Devices, links and other non-regular files
+
+References.
+-----------
+* CVS commands:: CVS commands share some things
+* Invoking CVS:: Quick reference to CVS commands
+* Administrative files:: Reference manual for the Administrative files
+* Environment variables:: All environment variables which affect CVS
+* Compatibility:: Upgrading CVS versions
+* Troubleshooting:: Some tips when nothing works
+* Credits:: Some of the contributors to this manual
+* BUGS:: Dealing with bugs in CVS or this manual
+* Index:: Index
address@hidden menu
+
address@hidden
---------------------------------------------------------------------
address@hidden Overview
address@hidden Overview
address@hidden Overview
+
+This chapter is for people who have never used
address@hidden, and perhaps have never used version control
+software before.
+
+If you are already familiar with @sc{cvs} and are just
+trying to learn a particular feature or remember a
+certain command, you can probably skip everything here.
+
address@hidden
+* What is CVS?:: What you can do with @sc{cvs}
+* What is CVS not?:: Problems @sc{cvs} doesn't try to solve
+* A sample session:: A tour of basic @sc{cvs} usage
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden What is CVS?
address@hidden What is CVS?
address@hidden What is CVS?
address@hidden Introduction to CVS
address@hidden CVS, introduction to
+
address@hidden is a version control system. Using it, you can
+record the history of your source files.
+
address@hidden -- ///
address@hidden -- ///Those who cannot remember the past are condemned to repeat
it.
address@hidden -- /// -- George Santayana
address@hidden -- //////
+
address@hidden -- Insert history quote here!
+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 @sc{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. @sc{cvs}
+stores all the versions of a file in a single file in a
+clever way that only stores the differences between
+versions.
+
address@hidden 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 @sc{gnu} Emacs, try to make sure that
+two people never modify the same file at the
+same time. Unfortunately, if someone is using another
+editor, that safeguard will not work. @sc{cvs} solves this problem
+by insulating the different developers from each other. Every
+developer works in his own directory, and @sc{cvs} merges
+the work when each developer is done.
+
address@hidden History of CVS
address@hidden CVS, history of
address@hidden Credits (CVS program)
address@hidden Contributors (CVS program)
address@hidden started out as a bunch of shell scripts written by
+Dick Grune, posted to the newsgroup
address@hidden in the volume 6
+release of July, 1986. While no actual code from
+these shell scripts is present in the current version
+of @sc{cvs} much of the @sc{cvs} conflict resolution algorithms
+come from them.
+
+In April, 1989, Brian Berliner designed and coded @sc{cvs}.
+Jeff Polk later helped Brian with the design of the @sc{cvs}
+module and vendor branch support.
+
address@hidden Source, getting CVS source
+You can get @sc{cvs} in a variety of ways, including
+free download from the Internet. For more information
+on downloading @sc{cvs} and other @sc{cvs} topics, see:
+
address@hidden
address@hidden://cvs.nongnu.org/}
address@hidden example
+
address@hidden Mailing list
address@hidden List, mailing list
address@hidden Newsgroups
+There is a mailing list, known as @email{info-cvs@@nongnu.org},
+devoted to @sc{cvs}. To subscribe or
+unsubscribe
+write to
address@hidden@@nongnu.org}.
+If you prefer a Usenet group, there is a one-way mirror (posts to the email
+list are usually sent to the news group, but not vice versa) of
address@hidden@@nongnu.org} at @url{news:gnu.cvs.help}. The right
+Usenet group for posts is @url{news:comp.software.config-mgmt} which is for
address@hidden discussions (along with other configuration
+management systems). In the future, it might be
+possible to create a
address@hidden, but probably only
+if there is sufficient @sc{cvs} traffic on
address@hidden:comp.software.config-mgmt}.
address@hidden Other random data is that the tale was very
address@hidden skeptical of comp.software.config-mgmt.cvs when the
address@hidden subject came up around 1995 or so (for one
address@hidden thing, because creating it would be a "reorg" which
address@hidden would need to take a more comprehensive look at the
address@hidden whole comp.software.config-mgmt.* hierarchy).
+
+You can also subscribe to the @email{bug-cvs@@nongnu.org} mailing list,
+described in more detail in @ref{BUGS}. To subscribe
+send mail to @email{bug-cvs-request@@nongnu.org}. There is a two-way
+Usenet mirror (posts to the Usenet group are usually sent to the email list and
+vice versa) of @email{bug-cvs@@nongnu.org} named @url{news:gnu.cvs.bug}.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden What is CVS not?
address@hidden What is CVS not?
address@hidden What is CVS not?
+
address@hidden can do a lot of things for you, but it does
+not try to be everything for everyone.
+
address@hidden @asis
address@hidden @sc{cvs} is not a build system.
+
+Though the structure of your repository and modules
+file interact with your build system
+(e.g. @file{Makefile}s), they are essentially
+independent.
+
address@hidden does not dictate how you build anything. It
+merely stores files for retrieval in a tree structure
+you devise.
+
address@hidden does not dictate how to use disk space in the
+checked out working directories. If you write your
address@hidden 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,
address@hidden in @file{Makefile}s, etc.), you can
+arrange your disk usage however you like.
+
+But you have to remember that @emph{any} such system is
+a lot of work to construct and maintain. @sc{cvs} does
+not address the issues involved.
+
+Of course, you should place the tools created to
+support such a build system (scripts, @file{Makefile}s,
+etc) under @sc{cvs}.
+
+Figuring out what files need to be rebuilt when
+something changes is, again, something to be handled
+outside the scope of @sc{cvs}. One traditional
+approach is to use @code{make} for building, and use
+some automated tool for generating the dependencies which
address@hidden uses.
+
+See @ref{Builds}, for more information on doing builds
+in conjunction with @sc{cvs}.
+
address@hidden @sc{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, @sc{cvs} can't help.
+
address@hidden 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.
+
address@hidden @sc{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.
+
address@hidden 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 @dfn{conflict} is purely textual, arising
+when two changes to the same base file are near enough
+to spook the merge (i.e. @code{diff3}) command.
+
address@hidden 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
address@hidden defined in file @file{A}. At the same time,
+someone edits file @file{B}, adding new calls to
+function @code{X} using the old arguments. You are
+outside the realm of @sc{cvs}'s competence.
+
+Acquire the habit of reading specs and talking to your
+peers.
+
+
address@hidden @sc{cvs} does not have change control
+
+Change control refers to a number of things. First of
+all it can mean @dfn{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
address@hidden to an external bug-tracking system, see the
address@hidden and @file{verifymsg} files
+(@pxref{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 @code{cvs commit}
+operation, @sc{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 @sc{gnu} style @file{ChangeLog}
+can help somewhat.
address@hidden FIXME: should have an xref to a section which talks
address@hidden more about keeping ChangeLog's with CVS, but that
address@hidden section hasn't been written yet.
+
+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 @sc{cvs} is to
+generate a diff (using @code{cvs diff} or @code{diff})
+and email it to someone who can then apply it using the
address@hidden utility. This is very flexible, but
+depends on mechanisms outside @sc{cvs} to make sure
+nothing falls through the cracks.
+
address@hidden @sc{cvs} is not an automated testing program
+
+It should be possible to enforce mandatory use of a
+test suite using the @code{commitinfo} file. I haven't
+heard a lot about projects trying to do that or whether
+there are subtle gotchas, however.
+
address@hidden @sc{cvs} does not have a built-in 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 @sc{cvs} but it might be a little more work.
+In some cases you'll want to use the @file{commitinfo},
address@hidden, @file{rcsinfo}, or @file{verifymsg}
+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.
address@hidden table
+
address@hidden
---------------------------------------------------------------------
address@hidden A sample session
address@hidden A sample session
address@hidden Example of a work-session
address@hidden Getting started
address@hidden Work-session, example of
address@hidden tc, Trivial Compiler (example)
address@hidden Trivial Compiler (example)
+
address@hidden I think an example is a pretty good way to start. But
address@hidden somewhere in here, maybe after the sample session,
address@hidden we need something which is kind of
address@hidden a "roadmap" which is more directed at sketching out
address@hidden the functionality of CVS and pointing people to
address@hidden various other parts of the manual. As it stands now
address@hidden people who read in order get dumped right into all
address@hidden manner of hair regarding remote repositories,
address@hidden creating a repository, etc.
address@hidden
address@hidden The following was in the old Basic concepts node. I don't
address@hidden know how good a job it does at introducing modules,
address@hidden or whether they need to be introduced so soon, but
address@hidden something of this sort might go into some
address@hidden introductory material somewhere.
address@hidden
address@hidden Modules (intro)
+The repository contains directories and files, in an
+arbitrary tree. The @dfn{modules} feature can be used
+to group together a set of directories or files into a
+single entity (@pxref{modules}). A typical usage is to
+define one module per project.
address@hidden ignore
+
+As a way of introducing @sc{cvs}, we'll go through a
+typical work-session using @sc{cvs}. The first thing
+to understand is that @sc{cvs} stores all files in a
+centralized @dfn{repository} (@pxref{Repository}); this
+section assumes that a repository is set up.
address@hidden I'm not sure that the sentence concerning the
address@hidden repository quite tells the user what they need to
address@hidden know at this point. Might need to expand on "centralized"
address@hidden slightly (maybe not here, maybe further down in the example?)
+
+Suppose you are working on a simple compiler. The source
+consists of a handful of C files and a @file{Makefile}.
+The compiler is called @samp{tc} (Trivial Compiler),
+and the repository is set up so that there is a module
+called @samp{tc}.
+
address@hidden
+* Getting the source:: Creating a workspace
+* Committing your changes:: Making your work available to others
+* Cleaning up:: Cleaning up
+* Viewing differences:: Viewing differences
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Getting the source
address@hidden Getting the source
address@hidden Getting the source
address@hidden Checking out source
address@hidden Fetching source
address@hidden Source, getting from CVS
address@hidden Checkout, example
+
+The first thing you must do is to get your own working copy of the
+source for @samp{tc}. For this, you use the @code{checkout} command:
+
address@hidden
+$ cvs checkout tc
address@hidden example
+
address@hidden
+This will create a new directory called @file{tc} and populate it with
+the source files.
+
address@hidden
+$ cd tc
+$ ls
+CVS Makefile backend.c driver.c frontend.c parser.c
address@hidden example
+
+The @file{CVS} directory is used internally by
address@hidden Normally, you should not modify or remove
+any of the files in it.
+
+You start your favorite editor, hack away at @file{backend.c}, and a couple
+of hours later you have added an optimization pass to the compiler.
+A note to @sc{rcs} and @sc{sccs} users: There is no need to lock the files that
+you want to edit. @xref{Multiple developers}, for an explanation.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Committing your changes
address@hidden Committing your changes
address@hidden Committing changes to files
address@hidden Log message entry
+
+When you have checked that the compiler is still compilable you decide
+to make a new version of @file{backend.c}. This will
+store your new @file{backend.c} in the repository and
+make it available to anyone else who is using that same
+repository.
+
address@hidden
+$ cvs commit backend.c
address@hidden example
+
address@hidden
address@hidden 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.
+
address@hidden CVSEDITOR, environment variable
address@hidden EDITOR, environment variable
+The environment variable @code{$CVSEDITOR} determines
+which editor is started. If @code{$CVSEDITOR} is not
+set, then if the environment variable @code{$EDITOR} is
+set, it will be used. If both @code{$CVSEDITOR} and
address@hidden are not set then there is a default
+which will vary with your operating system, for example
address@hidden for unix or @code{notepad} for Windows
+NT/95.
+
address@hidden VISUAL, environment variable
+In addition, @sc{cvs} checks the @code{$VISUAL} environment
+variable. Opinions vary on whether this behavior is desirable and
+whether future releases of @sc{cvs} should check @code{$VISUAL} or
+ignore it. You will be OK either way if you make sure that
address@hidden is either unset or set to the same thing as
address@hidden
+
address@hidden This probably should go into some new node
address@hidden containing detailed info on the editor, rather than
address@hidden the intro. In fact, perhaps some of the stuff with
address@hidden CVSEDITOR and -m and so on should too.
+When @sc{cvs} starts the editor, it includes a list of
+files which are modified. For the @sc{cvs} client,
+this list is based on comparing the modification time
+of the file against the modification time that the file
+had when it was last gotten or updated. Therefore, if
+a file's modification time has changed but its contents
+have not, it will show up as modified. The simplest
+way to handle this is simply not to worry about it---if
+you proceed with the commit @sc{cvs} will detect that
+the contents are not modified and treat it as an
+unmodified file. The next @code{update} will clue
address@hidden in to the fact that the file is unmodified,
+and it will reset its stored timestamp so that the file
+will not show up in future editor sessions.
address@hidden FIXCVS: Might be nice if "commit" and other commands
address@hidden would reset that timestamp too, but currently commit
address@hidden doesn't.
address@hidden FIXME: Need to talk more about the process of
address@hidden prompting for the log message. Like show an example
address@hidden of what it pops up in the editor, for example. Also
address@hidden a discussion of how to get the "a)bort, c)ontinue,
address@hidden e)dit" prompt and what to do with it. Might also
address@hidden work in the suggestion that if you want a diff, you
address@hidden should make it before running commit (someone
address@hidden suggested that the diff pop up in the editor. I'm
address@hidden not sure that is better than telling people to run
address@hidden "cvs diff" first if that is what they want, but if
address@hidden we want to tell people that, the manual possibly
address@hidden should say it).
+
+If you want to avoid
+starting an editor you can specify the log message on
+the command line using the @samp{-m} flag instead, like
+this:
+
address@hidden
+$ cvs commit -m "Added an optimization pass" backend.c
address@hidden example
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Cleaning up
address@hidden Cleaning up
address@hidden Cleaning up
address@hidden Working copy, removing
address@hidden Removing your working copy
address@hidden Releasing your working copy
+
+Before you turn to other tasks you decide to remove your working copy of
+tc. One acceptable way to do that is of course
+
address@hidden
+$ cd ..
+$ rm -r tc
address@hidden example
+
address@hidden
+but a better way is to use the @code{release} command (@pxref{release}):
+
address@hidden
+$ 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) directory `tc': n
+** `release' aborted by user choice.
address@hidden example
+
+The @code{release} command checks that all your modifications have been
+committed. If history logging is enabled it also makes a note in the
+history file. @xref{history file}.
+
+When you use the @samp{-d} flag with @code{release}, it
+also removes your working copy.
+
+In the example above, the @code{release} command wrote a couple of lines
+of output. @samp{? tc} means that the file @file{tc} is unknown to @sc{cvs}.
+That is nothing to worry about: @file{tc} is the executable compiler,
+and it should not be stored in the repository. @xref{cvsignore},
+for information about how to make that warning go away.
address@hidden output}, for a complete explanation of
+all possible output from @code{release}.
+
address@hidden driver.c} is more serious. It means that the
+file @file{driver.c} has been modified since it was
+checked out.
+
+The @code{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 @kbd{n @key{RET}}
+when @code{release} asks for confirmation.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Viewing differences
address@hidden Viewing differences
address@hidden Viewing differences
address@hidden Diff
+
+You do not remember modifying @file{driver.c}, so you want to see what
+has happened to that file.
+
address@hidden
+$ cd tc
+$ cvs diff driver.c
address@hidden example
+
+This command runs @code{diff} to compare the version of @file{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.
address@hidden FIXME: we haven't yet defined the term "check in".
+
address@hidden
+$ 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) directory `tc': y
address@hidden example
+
address@hidden
---------------------------------------------------------------------
address@hidden Repository
address@hidden The Repository
address@hidden Repository (intro)
address@hidden Repository, example
address@hidden Layout of repository
address@hidden Typical repository
address@hidden /usr/local/cvsroot, as example repository
address@hidden cvsroot
+
+The @sc{cvs} @dfn{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 @sc{cvs}
+commands to get your own copy of the files into a
address@hidden directory}, and then
+work on that copy. When you've finished a set of
+changes, you check (or @dfn{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. Note that the repository is not a
+subdirectory of the working directory, or vice versa;
+they should be in separate locations.
address@hidden Need some example, e.g. repository
address@hidden /usr/local/cvsroot; working directory
address@hidden /home/joe/sources. But this node is too long
address@hidden as it is; need a little reorganization...
+
address@hidden :local:, setting up
address@hidden 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 @dfn{access method}.
+For example, the access method @code{:local:} means to
+access a repository directory, so the repository
address@hidden:local:/usr/local/cvsroot} means that the
+repository is in @file{/usr/local/cvsroot} on the
+computer running @sc{cvs}. For information on other
+access methods, see @ref{Remote repositories}.
+
address@hidden Can se say this more concisely? Like by passing
address@hidden more of the buck to the Remote repositories node?
+If the access method is omitted, then if the repository
+starts with @samp{/}, then @code{:local:} is
+assumed. If it does not start with @samp{/} then either
address@hidden:ext:} or @code{:server:} is assumed. For
+example, if you have a local repository in
address@hidden/usr/local/cvsroot}, you can use
address@hidden/usr/local/cvsroot} instead of
address@hidden:local:/usr/local/cvsroot}. But if (under
+Windows NT, for example) your local repository is
address@hidden:\src\cvsroot}, then you must specify the access
+method, as in @code{:local:c:/src/cvsroot}.
+
address@hidden This might appear to go in Repository storage, but
address@hidden actually it is describing something which is quite
address@hidden user-visible, when you do a "cvs co CVSROOT". This
address@hidden isn't necessary the perfect place for that, though.
+The repository is split in two parts. @file{$CVSROOT/CVSROOT} contains
+administrative files for @sc{cvs}. The other directories contain the actual
+user-defined modules.
+
address@hidden
+* Specifying a repository:: Telling CVS where your repository is
+* Repository storage:: The structure of the repository
+* Working directory storage:: The structure of working directories
+* Intro administrative files:: Defining modules
+* Multiple repositories:: Multiple repositories
+* Creating a repository:: Creating a repository
+* Backing up:: Backing up a repository
+* Moving a repository:: Moving a repository
+* Remote repositories:: Accessing repositories on remote machines
+* Read-only access:: Granting read-only access to the repository
+* Server temporary directory:: The server creates temporary directories
address@hidden menu
+
address@hidden Specifying a repository
address@hidden Telling CVS where your repository is
+
+There are several ways to tell @sc{cvs}
+where to find the repository. You can name the
+repository on the command line explicitly, with the
address@hidden (for "directory") option:
+
address@hidden
+cvs -d /usr/local/cvsroot checkout yoyodyne/tc
address@hidden example
+
address@hidden .profile, setting CVSROOT in
address@hidden .cshrc, setting CVSROOT in
address@hidden .tcshrc, setting CVSROOT in
address@hidden .bashrc, setting CVSROOT in
address@hidden CVSROOT, environment variable
+ Or you can set the @code{$CVSROOT} environment
+variable to an absolute path to the root of the
+repository, @file{/usr/local/cvsroot} in this example.
+To set @code{$CVSROOT}, @code{csh} and @code{tcsh}
+users should have this line in their @file{.cshrc} or
address@hidden files:
+
address@hidden
+setenv CVSROOT /usr/local/cvsroot
address@hidden example
+
address@hidden
address@hidden and @code{bash} users should instead have these lines in their
address@hidden or @file{.bashrc}:
+
address@hidden
+CVSROOT=/usr/local/cvsroot
+export CVSROOT
address@hidden example
+
address@hidden Root file, in CVS directory
address@hidden CVS/Root file
+ A repository specified with @code{-d} will
+override the @code{$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
address@hidden/Root} file in the working copy).
+
+The @code{-d} option and the @file{CVS/Root} file both
+override the @code{$CVSROOT} environment variable. If
address@hidden option differs from @file{CVS/Root}, the
+former is used. Of course, for proper operation they
+should be two ways of referring to the same repository.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Repository storage
address@hidden How data is stored in the repository
address@hidden Repository, how data is stored
+
+For most purposes it isn't important @emph{how}
address@hidden 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 @sc{cvs} commands, such
+changes need not be disruptive.
+
+However, in some cases it may be necessary to
+understand how @sc{cvs} stores data in the repository,
+for example you might need to track down @sc{cvs} locks
+(@pxref{Concurrency}) or you might need to deal with
+the file permissions appropriate for the repository.
+
address@hidden
+* Repository files:: What files are stored in the repository
+* File permissions:: File permissions
+* Windows permissions:: Issues specific to Windows
+* Attic:: Some files are stored in the Attic
+* CVS in repository:: Additional information in CVS directory
+* Locks:: CVS locks control concurrent accesses
+* CVSROOT storage:: A few things about CVSROOT are different
address@hidden menu
+
address@hidden Repository files
address@hidden Where files are stored within the repository
+
address@hidden @cindex Filenames, legal
address@hidden @cindex Legal filenames
address@hidden Somewhere we need to say something about legitimate
address@hidden characters in filenames in working directory and
address@hidden repository. Not "/" (not even on non-unix). And
address@hidden here is a specific set of issues:
address@hidden Files starting with a - are handled inconsistently. They can not
address@hidden be added to a repository with an add command, because it they
are
address@hidden interpreted as a switch. They can appear in a repository if
they are
address@hidden part of a tree that is imported. They can not be removed from
the tree
address@hidden once they are there.
address@hidden Note that "--" *is* supported (as a
address@hidden consequence of using GNU getopt). Should document
address@hidden this somewhere ("Common options"?). The other usual technique,
address@hidden "./-foo", isn't as effective, at least for "cvs add"
address@hidden which doesn't support pathnames containing "/".
+
+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
+
address@hidden
+/usr/local/cvsroot
address@hidden example
+
address@hidden
+here is a possible directory tree (showing only the
+directories):
+
address@hidden
address@hidden/usr}
+ |
+ address@hidden
+ | |
+ | address@hidden
+ | | |
+ | | address@hidden
+ | (administrative files)
+ |
+ address@hidden
+ | |
+ | address@hidden
+ | | (source code to @sc{gnu} diff)
+ | |
+ | address@hidden
+ | | (source code to @sc{rcs})
+ | |
+ | address@hidden
+ | (source code to @sc{cvs})
+ |
+ address@hidden
+ |
+ address@hidden
+ | |
+ | address@hidden
+ | |
+ | address@hidden
+ |
+ +--(other Yoyodyne software)
address@hidden example
+
+With the directories are @dfn{history files} for each file
+under version control. The name of the history file is
+the name of the corresponding file with @samp{,v}
+appended to the end. Here is what the repository for
+the @file{yoyodyne/tc} directory might look like:
address@hidden FIXME: Should also mention CVS (CVSREP)
address@hidden FIXME? Should we introduce Attic with an xref to
address@hidden Attic? Not sure whether that is a good idea or not.
address@hidden
+ @code{$CVSROOT}
+ |
+ address@hidden
+ | |
+ | address@hidden
+ | | |
+ address@hidden,v}
+ address@hidden,v}
+ address@hidden,v}
+ address@hidden,v}
+ address@hidden,v}
+ address@hidden
+ | |
+ | address@hidden,v}
+ |
+ address@hidden
+ |
+ address@hidden,v}
+ address@hidden,v}
address@hidden example
+
address@hidden History files
address@hidden RCS history files
address@hidden The first sentence, about what history files
address@hidden contain, is kind of redundant with our intro to what the
address@hidden repository does in node Repository....
+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 @dfn{RCS files}, because the first program to
+store files in that format was a version control system
+known as @sc{rcs}. For a full
+description of the file format, see the @code{man} page
address@hidden(5)}, distributed with @sc{rcs}, or the
+file @file{doc/RCSFILES} in the @sc{cvs} source
+distribution. This
+file format has become very common---many systems other
+than @sc{cvs} or @sc{rcs} can at least import history
+files in this format.
address@hidden FIXME: Think about including documentation for this
address@hidden rather than citing it? In the long run, getting
address@hidden this to be a standard (not sure if we can cope with
address@hidden a standards process as formal as IEEE/ANSI/ISO/etc,
address@hidden though...) is the way to go, so maybe citing is
address@hidden better.
+
+The @sc{rcs} files used in @sc{cvs} differ in a few
+ways from the standard format. The biggest difference
+is magic branches; for more information see @ref{Magic
+branch numbers}. Also in @sc{cvs} the valid tag names
+are a subset of what @sc{rcs} accepts; for @sc{cvs}'s
+rules see @ref{Tags}.
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden File permissions
address@hidden File permissions
address@hidden -- Move this to @node Creating a repository or similar
address@hidden Security, file permissions in repository
address@hidden File permissions, general
address@hidden Permissions, general
address@hidden FIXME: we need to somehow reflect "permissions in
address@hidden repository" versus "permissions in working
address@hidden directory" in the index entries.
address@hidden Group, UNIX file permissions, in repository
address@hidden Read-only files, in repository
+All @samp{,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.
+(On some systems, you also need to set the set-group-ID-on-execution bit
+on the repository directories (see chmod(1)) so that newly-created files
+and directories get the group-ID of the parent directory rather than
+that of the current process.)
+
address@hidden See also comment in commitinfo node regarding cases
address@hidden which are really awkward with unix groups.
+
+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 @sc{cvs} needs to create lock files
+(@pxref{Concurrency}). You can use LockDir in CVSROOT/config
+to put the lock files somewhere other than in the repository
+if you want to allow read-only access to some directories
+(@pxref{config}).
+
address@hidden CVS seems to use CVSUMASK in picking permissions for
address@hidden val-tags, but maybe we should say more about this.
address@hidden Like val-tags gets created by someone who doesn't
address@hidden have CVSUMASK set right?
address@hidden CVSROOT/val-tags file, and read-only access to projects
address@hidden val-tags file, and read-only access to projects
+Also note that users must have write access to the
address@hidden/val-tags} file. @sc{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).
+
+Each @sc{rcs} file will be owned by the user who last
+checked it in. This has little significance; what
+really matters is who owns the directories.
+
address@hidden CVSUMASK, environment variable
address@hidden Umask, for repository files
address@hidden 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}
+environment variable that will control the file
+permissions which @sc{cvs} uses in creating directories
+and/or files in the repository. @code{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
address@hidden creates them read-only (see the sections on
+watches, @ref{Setting a watch}; -r, @ref{Global
+options}; or @code{CVSREAD}, @ref{Environment variables}).
address@hidden FIXME: Need more discussion of which
address@hidden group should own the file in the repository.
address@hidden Include a somewhat detailed example of the usual
address@hidden case where CVSUMASK is 007, the developers are all
address@hidden in a group, and that group owns stuff in the
address@hidden repository. Need to talk about group ownership of
address@hidden newly-created directories/files (on some unices,
address@hidden such as SunOS4, setting the setgid bit on the
address@hidden directories will make files inherit the directory's
address@hidden group. On other unices, your mileage may vary. I
address@hidden can't remember what POSIX says about this, if
address@hidden anything).
+
+Note that using the client/server @sc{cvs}
+(@pxref{Remote repositories}), there is no good way to
+set @code{CVSUMASK}; the setting on the client machine
+has no effect. If you are connecting with @code{rsh}, you
+can set @code{CVSUMASK} in @file{.bashrc} or @file{.cshrc}, as
+described in the documentation for your operating
+system. This behavior might change in future versions
+of @sc{cvs}; do not rely on the setting of
address@hidden on the client having no effect.
address@hidden FIXME: need to explain what a umask is or cite
address@hidden someplace which does.
address@hidden
address@hidden There is also a larger (largely separate) issue
address@hidden about the meaning of CVSUMASK in a non-unix context.
address@hidden For example, whether there is
address@hidden an equivalent which fits better into other
address@hidden protection schemes like POSIX.6, VMS, &c.
address@hidden
address@hidden FIXME: Need one place which discusses this
address@hidden read-only files thing. Why would one use -r or
address@hidden CVSREAD? Why would one use watches? How do they
address@hidden interact?
address@hidden
address@hidden FIXME: We need to state
address@hidden whether using CVSUMASK removes the need for manually
address@hidden fixing permissions (in fact, if we are going to mention
address@hidden manually fixing permission, we better document a lot
address@hidden better just what we mean by "fix").
+
+Using pserver, you will generally need stricter
+permissions on the @sc{cvsroot} directory and
+directories above it in the tree; see @ref{Password
+authentication security}.
+
address@hidden Setuid
address@hidden Setgid
address@hidden Security, setuid
address@hidden Installed images (VMS)
+Some operating systems have features which allow a
+particular program to run with the ability to perform
+operations which the caller of the program could not.
+For example, the set user ID (setuid) or set group ID
+(setgid) features of unix or the installed image
+feature of VMS. @sc{cvs} was not written to use such
+features and therefore attempting to install @sc{cvs} in
+this fashion will provide protection against only
+accidental lapses; anyone who is trying to circumvent
+the measure will be able to do so, and depending on how
+you have set it up may gain access to more than just
address@hidden You may wish to instead consider pserver. It
+shares some of the same attributes, in terms of
+possibly providing a false sense of security or opening
+security holes wider than the ones you are trying to
+fix, so read the documentation on pserver security
+carefully if you are considering this option
+(@ref{Password authentication security}).
+
address@hidden Windows permissions
address@hidden File Permission issues specific to Windows
address@hidden Windows, and permissions
address@hidden File permissions, Windows-specific
address@hidden Permissions, Windows-specific
+
+Some file permission issues are specific to Windows
+operating systems (Windows 95, Windows NT, and
+presumably future operating systems in this family.
+Some of the following might apply to OS/2 but I'm not
+sure).
+
+If you are using local @sc{cvs} and the repository is on a
+networked file system which is served by the Samba SMB
+server, some people have reported problems with
+permissions. Enabling WRITE=YES in the samba
+configuration is said to fix/workaround it.
+Disclaimer: I haven't investigated enough to know the
+implications of enabling that option, nor do I know
+whether there is something which @sc{cvs} could be doing
+differently in order to avoid the problem. If you find
+something out, please let us know as described in
address@hidden
+
address@hidden Attic
address@hidden The attic
address@hidden Attic
+
+You will notice that sometimes @sc{cvs} stores an
address@hidden file in the @code{Attic}. For example, if the
address@hidden is @file{/usr/local/cvsroot} and we are
+talking about the file @file{backend.c} in the
+directory @file{yoyodyne/tc}, then the file normally
+would be in
+
address@hidden
+/usr/local/cvsroot/yoyodyne/tc/backend.c,v
address@hidden example
+
address@hidden
+but if it goes in the attic, it would be in
+
address@hidden
+/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v
address@hidden example
+
address@hidden
address@hidden Dead state
+instead. It should not matter from a user point of
+view whether a file is in the attic; @sc{cvs} keeps
+track of this and looks in the attic when it needs to.
+But in case you want to know, the rule is that the RCS
+file is stored in the attic if and only if the head
+revision on the trunk has state @code{dead}. A
address@hidden state means that file has been removed, or
+never added, for that revision. For example, if you
+add a file on a branch, it will have a trunk revision
+in @code{dead} state, and a branch revision in a
address@hidden state.
address@hidden Probably should have some more concrete examples
address@hidden here, or somewhere (not sure exactly how we should
address@hidden arrange the discussion of the dead state, versus
address@hidden discussion of the attic).
+
address@hidden CVS in repository
address@hidden The CVS directory in the repository
address@hidden CVS directory, in repository
+
+The @file{CVS} directory in each repository directory
+contains information such as file attributes (in a file
+called @file{CVS/fileattr}. In the
+future additional files may be added to this directory,
+so implementations should silently ignore additional
+files.
+
+This behavior is implemented only by @sc{cvs} 1.7 and
+later; for details see @ref{Watches Compatibility}.
+
+The format of the @file{fileattr} file is a series of entries
+of the following form (where @address@hidden and @address@hidden
+means the text between the braces can be repeated zero
+or more times):
+
address@hidden @var{filename} <tab> @var{attrname} = @var{attrval}
+ @{; @var{attrname} = @address@hidden <linefeed>
+
address@hidden is @samp{F} for a file, in which case the entry specifies the
+attributes for that file.
+
address@hidden is @samp{D},
+and @var{filename} empty, to specify default attributes
+to be used for newly added files.
+
+Other @var{ent-type} are reserved for future expansion. @sc{cvs} 1.9 and older
+will delete them any time it writes file attributes.
address@hidden 1.10 and later will preserve them.
+
+Note that the order of the lines is not significant;
+a program writing the fileattr file may
+rearrange them at its convenience.
+
+There is currently no way of quoting tabs or line feeds in the
+filename, @samp{=} in @var{attrname},
address@hidden;} in @var{attrval}, etc. Note: some implementations also
+don't handle a NUL character in any of the fields, but
+implementations are encouraged to allow it.
+
+By convention, @var{attrname} starting with @samp{_} is for an attribute given
+special meaning by @sc{cvs}; other @var{attrname}s are for user-defined
attributes
+(or will be, once implementations start supporting user-defined attributes).
+
+Built-in attributes:
+
address@hidden @code
address@hidden _watched
+Present means the file is watched and should be checked out
+read-only.
+
address@hidden _watchers
+Users with watches for this file. Value is
address@hidden > @var{type} @{ , @var{watcher} > @var{type} @}
+where @var{watcher} is a username, and @var{type}
+is zero or more of edit,unedit,commit separated by
address@hidden (that is, nothing if none; there is no "none" or "all" keyword).
+
address@hidden _editors
+Users editing this file. Value is
address@hidden > @var{val} @{ , @var{editor} > @var{val} @}
+where @var{editor} is a username, and @var{val} is
address@hidden@address@hidden, where
address@hidden is when the @code{cvs edit} command (or
+equivalent) happened,
+and @var{hostname} and @var{pathname} are for the working directory.
address@hidden table
+
+Example:
+
address@hidden FIXME: sanity.sh should contain a similar test case
address@hidden so we can compare this example from something from
address@hidden Real Life(TM). See cvsclient.texi (under Notify) for more
address@hidden discussion of the date format of _editors.
address@hidden
+Ffile1 _watched=;_watchers=joe>edit,mary>commit
+Ffile2 _watched=;_editors=sue>8 Jan 1975+workstn1+/home/sue/cvs
+D _watched=
address@hidden example
+
address@hidden
+means that the file @file{file1} should be checked out
+read-only. Furthermore, joe is watching for edits and
+mary is watching for commits. The file @file{file2}
+should be checked out read-only; sue started editing it
+on 8 Jan 1975 in the directory @file{/home/sue/cvs} on
+the machine @code{workstn1}. Future files which are
+added should be checked out read-only. To represent
+this example here, we have shown a space after
address@hidden, @samp{Ffile1}, and @samp{Ffile2}, but in fact
+there must be a single tab character there and no spaces.
+
address@hidden Locks
address@hidden CVS locks in the repository
+
address@hidden #cvs.rfl, technical details
address@hidden #cvs.pfl, technical details
address@hidden #cvs.wfl, technical details
address@hidden #cvs.lock, technical details
address@hidden Locks, cvs, technical details
+For an introduction to @sc{cvs} locks focusing on
+user-visible behavior, see @ref{Concurrency}. The
+following section is aimed at people who are writing
+tools which want to access a @sc{cvs} repository without
+interfering with other tools accessing the same
+repository. If you find yourself confused by concepts
+described here, like @dfn{read lock}, @dfn{write lock},
+and @dfn{deadlock}, you might consult the literature on
+operating systems or databases.
+
address@hidden #cvs.tfl
+Any file in the repository with a name starting
+with @file{#cvs.rfl.} is a read lock. Any file in
+the repository with a name starting with
address@hidden is a promotable read lock. Any file in
+the repository with a name starting with
address@hidden is a write lock. Old versions of @sc{cvs}
+(before @sc{cvs} 1.5) also created files with names starting
+with @file{#cvs.tfl}, but they are not discussed here.
+The directory @file{#cvs.lock} serves as a master
+lock. That is, one must obtain this lock first before
+creating any of the other locks.
+
+To obtain a read lock, first create the @file{#cvs.lock}
+directory. This operation must be atomic (which should
+be true for creating a directory under most operating
+systems). If it fails because the directory already
+existed, wait for a while and try again. After
+obtaining the @file{#cvs.lock} lock, create a file
+whose name is @file{#cvs.rfl.} followed by information
+of your choice (for example, hostname and process
+identification number). Then remove the
address@hidden directory to release the master lock.
+Then proceed with reading the repository. When you are
+done, remove the @file{#cvs.rfl} file to release the
+read lock.
+
+Promotable read locks are a concept you may not find in other literature on
+concurrency. They are used to allow a two (or more) pass process to only lock
+a file for read on the first (read) pass(es), then upgrade its read locks to
+write locks if necessary for a final pass, still assured that the files have
+not changed since they were first read. @sc{cvs} uses promotable read locks,
+for example, to prevent commit and tag verification passes from interfering
+with other reading processes. It can then lock only a single directory at a
+time for write during the write pass.
+
+To obtain a promotable read lock, first create the @file{#cvs.lock} directory,
+as with a non-promotable read lock. Then check
+that there are no files that start with
address@hidden If there are, remove the master @file{#cvs.lock} directory,
+wait awhile (CVS waits 30 seconds between lock attempts), and try again. If
+there are no other promotable locks, go ahead and create a file whose name is
address@hidden followed by information of your choice (for example, CVS uses
+its hostname and the process identification number of the CVS server process
+creating the lock). If versions of @sc{cvs} older than version 1.12.4 access
+your repository directly (not via a @sc{cvs} server of version 1.12.4 or
+later), then you should also create a read lock since older versions of CVS
+will ignore the promotable lock when attempting to create their own write lock.
+Then remove the master @file{#cvs.lock} directory in order to allow other
+processes to obtain read locks.
+
+To obtain a write lock, first create the
address@hidden directory, as with read locks. Then
+check that there are no files whose names start with
address@hidden and no files whose names start with @file{#cvs.pfl} that are
+not owned by the process attempting to get the write lock. If either exist,
+remove @file{#cvs.lock}, wait for a while, and try again. If
+there are no readers or promotable locks from other processes, then create a
+file whose name is @file{#cvs.wfl} followed by information of your choice
+(again, CVS uses the hostname and server process identification
+number). Remove your @file{#cvs.pfl} file if present. Hang on to the
address@hidden lock. Proceed
+with writing the repository. When you are done, first
+remove the @file{#cvs.wfl} file and then the
address@hidden directory. Note that unlike the
address@hidden file, the @file{#cvs.wfl} file is just
+informational; it has no effect on the locking operation
+beyond what is provided by holding on to the
address@hidden lock itself.
+
+Note that each lock (write lock or read lock) only locks
+a single directory in the repository, including
address@hidden and @file{CVS} but not including
+subdirectories which represent other directories under
+version control. To lock an entire tree, you need to
+lock each directory (note that if you fail to obtain
+any lock you need, you must release the whole tree
+before waiting and trying again, to avoid deadlocks).
+
+Note also that @sc{cvs} expects write locks to control
+access to individual @file{foo,v} files. @sc{rcs} has
+a scheme where the @file{,foo,} file serves as a lock,
+but @sc{cvs} does not implement it and so taking out a
address@hidden write lock is recommended. See the comments at
+rcs_internal_lockfile in the @sc{cvs} source code for
+further discussion/rationale.
+
address@hidden CVSROOT storage
address@hidden How files are stored in the CVSROOT directory
address@hidden CVSROOT, storage of files
+
+The @file{$CVSROOT/CVSROOT} directory contains the
+various administrative files. In some ways this
+directory is just like any other directory in the
+repository; it contains @sc{rcs} files whose names end
+in @samp{,v}, and many of the @sc{cvs} commands operate
+on it the same way. However, there are a few
+differences.
+
+For each administrative file, in addition to the
address@hidden file, there is also a checked out copy of the
+file. For example, there is an @sc{rcs} file
address@hidden,v} and a file @file{loginfo} which
+contains the latest revision contained in
address@hidden,v}. When you check in an administrative
+file, @sc{cvs} should print
+
address@hidden
+cvs commit: Rebuilding administrative file database
address@hidden example
+
address@hidden
+and update the checked out copy in
address@hidden/CVSROOT}. If it does not, there is
+something wrong (@pxref{BUGS}). To add your own files
+to the files to be updated in this fashion, you can add
+them to the @file{checkoutlist} administrative file
+(@pxref{checkoutlist}).
+
address@hidden modules.db
address@hidden modules.pag
address@hidden modules.dir
+By default, the @file{modules} file behaves as
+described above. If the modules file is very large,
+storing it as a flat text file may make looking up
+modules slow (I'm not sure whether this is as much of a
+concern now as when @sc{cvs} first evolved this
+feature; I haven't seen benchmarks). Therefore, by
+making appropriate edits to the @sc{cvs} source code
+one can store the modules file in a database which
+implements the @code{ndbm} interface, such as Berkeley
+db or GDBM. If this option is in use, then the modules
+database will be stored in the files @file{modules.db},
address@hidden, and/or @file{modules.dir}.
address@hidden I think fileattr also will use the database stuff.
address@hidden Anything else?
+
+For information on the meaning of the various
+administrative files, see @ref{Administrative files}.
+
address@hidden Working directory storage
address@hidden How data is stored in the working directory
+
address@hidden FIXME: Somewhere we should discuss timestamps (test
address@hidden case "stamps" in sanity.sh). But not here. Maybe
address@hidden in some kind of "working directory" chapter which
address@hidden would encompass the "Builds" one? But I'm not sure
address@hidden whether that is a good organization (is it based on
address@hidden what the user wants to do?).
+
address@hidden CVS directory, in working directory
+While we are discussing @sc{cvs} internals which may
+become visible from time to time, we might as well talk
+about what @sc{cvs} puts in the @file{CVS} directories
+in the working directories. As with the repository,
address@hidden handles this information and one can usually
+access it via @sc{cvs} commands. But in some cases it
+may be useful to look at it, and other programs, such
+as the @code{jCVS} graphical user interface or the
address@hidden package for emacs, may need to look at it.
+Such programs should follow the recommendations in this
+section if they hope to be able to work with other
+programs which use those files, including future
+versions of the programs just mentioned and the
+command-line @sc{cvs} client.
+
+The @file{CVS} directory contains several files.
+Programs which are reading this directory should
+silently ignore files which are in the directory but
+which are not documented here, to allow for future
+expansion.
+
+The files are stored according to the text file
+convention for the system in question. This means that
+working directories are not portable between systems
+with differing conventions for storing text files.
+This is intentional, on the theory that the files being
+managed by @sc{cvs} probably will not be portable between
+such systems either.
+
address@hidden @file
address@hidden Root
+This file contains the current @sc{cvs} root, as
+described in @ref{Specifying a repository}.
+
address@hidden Repository file, in CVS directory
address@hidden CVS/Repository file
address@hidden Repository
+This file contains the directory within the repository
+which the current directory corresponds with. It can
+be either an absolute pathname or a relative pathname;
address@hidden has had the ability to read either format
+since at least version 1.3 or so. The relative
+pathname is relative to the root, and is the more
+sensible approach, but the absolute pathname is quite
+common and implementations should accept either. For
+example, after the command
+
address@hidden
+cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc
address@hidden example
+
address@hidden
address@hidden will contain
+
address@hidden
+:local:/usr/local/cvsroot
address@hidden example
+
address@hidden
+and @file{Repository} will contain either
+
address@hidden
+/usr/local/cvsroot/yoyodyne/tc
address@hidden example
+
address@hidden
+or
+
address@hidden
+yoyodyne/tc
address@hidden example
+
+If the particular working directory does not correspond
+to a directory in the repository, then @file{Repository}
+should contain @file{CVSROOT/Emptydir}.
address@hidden Emptydir, in CVSROOT directory
address@hidden CVSROOT/Emptydir directory
+
address@hidden Entries file, in CVS directory
address@hidden CVS/Entries file
address@hidden Entries
+This file lists the files and directories in the
+working directory.
+The first character of each line indicates what sort of
+line it is. If the character is unrecognized, programs
+reading the file should silently skip that line, to
+allow for future expansion.
+
+If the first character is @samp{/}, then the format is:
+
address@hidden
+/@var{name}/@var{revision}/@address@hidden/@var{options}/@var{tagdate}
address@hidden example
+
address@hidden
+where @samp{[} and @samp{]} are not part of the entry,
+but instead indicate that the @samp{+} and conflict
+marker are optional. @var{name} is the name of the
+file within the directory. @var{revision} is the
+revision that the file in the working derives from, or
address@hidden for an added file, or @samp{-} followed by a
+revision for a removed file. @var{timestamp} is the
+timestamp of the file at the time that @sc{cvs} created
+it; if the timestamp differs with the actual
+modification time of the file it means the file has
+been modified. It is stored in
+the format used by the ISO C asctime() function (for
+example, @samp{Sun Apr 7 01:29:26 1996}). One may
+write a string which is not in that format, for
+example, @samp{Result of merge}, to indicate that the
+file should always be considered to be modified. This
+is not a special case; to see whether a file is
+modified a program should take the timestamp of the file
+and simply do a string compare with @var{timestamp}.
+If there was a conflict, @var{conflict} can be set to
+the modification time of the file after the file has been
+written with conflict markers (@pxref{Conflicts example}).
+Thus if @var{conflict} is subsequently the same as the actual
+modification time of the file it means that the user
+has obviously not resolved the conflict. @var{options}
+contains sticky options (for example @samp{-kb} for a
+binary file). @var{tagdate} contains @samp{T} followed
+by a tag name, or @samp{D} for a date, followed by a
+sticky tag or date. Note that if @var{timestamp}
+contains a pair of timestamps separated by a space,
+rather than a single timestamp, you are dealing with a
+version of @sc{cvs} earlier than @sc{cvs} 1.5 (not
+documented here).
+
+The timezone on the timestamp in CVS/Entries (local or
+universal) should be the same as the operating system
+stores for the timestamp of the file itself. For
+example, on Unix the file's timestamp is in universal
+time (UT), so the timestamp in CVS/Entries should be
+too. On @sc{vms}, the file's timestamp is in local
+time, so @sc{cvs} on @sc{vms} should use local time.
+This rule is so that files do not appear to be modified
+merely because the timezone changed (for example, to or
+from summer time).
address@hidden See comments and calls to gmtime() and friends in
address@hidden src/vers_ts.c (function time_stamp).
+
+If the first character of a line in @file{Entries} is
address@hidden, then it indicates a subdirectory. @samp{D}
+on a line all by itself indicates that the program
+which wrote the @file{Entries} file does record
+subdirectories (therefore, if there is such a line and
+no other lines beginning with @samp{D}, one knows there
+are no subdirectories). Otherwise, the line looks
+like:
+
address@hidden
+D/@var{name}/@var{filler1}/@var{filler2}/@var{filler3}/@var{filler4}
address@hidden example
+
address@hidden
+where @var{name} is the name of the subdirectory, and
+all the @var{filler} fields should be silently ignored,
+for future expansion. Programs which modify
address@hidden files should preserve these fields.
+
+The lines in the @file{Entries} file can be in any order.
+
address@hidden Entries.Log file, in CVS directory
address@hidden CVS/Entries.Log file
address@hidden Entries.Log
+This file does not record any information beyond that
+in @file{Entries}, but it does provide a way to update
+the information without having to rewrite the entire
address@hidden file, including the ability to preserve
+the information even if the program writing
address@hidden and @file{Entries.Log} abruptly aborts.
+Programs which are reading the @file{Entries} file
+should also check for @file{Entries.Log}. If the latter
+exists, they should read @file{Entries} and then apply
+the changes mentioned in @file{Entries.Log}. After
+applying the changes, the recommended practice is to
+rewrite @file{Entries} and then delete @file{Entries.Log}.
+The format of a line in @file{Entries.Log} is a single
+character command followed by a space followed by a
+line in the format specified for a line in
address@hidden The single character command is
address@hidden to indicate that the entry is being added,
address@hidden to indicate that the entry is being removed,
+or any other character to indicate that the entire line
+in @file{Entries.Log} should be silently ignored (for
+future expansion). If the second character of the line
+in @file{Entries.Log} is not a space, then it was
+written by an older version of @sc{cvs} (not documented
+here).
+
+Programs which are writing rather than reading can
+safely ignore @file{Entries.Log} if they so choose.
+
address@hidden Entries.Backup file, in CVS directory
address@hidden CVS/Entries.Backup file
address@hidden Entries.Backup
+This is a temporary file. Recommended usage is to
+write a new entries file to @file{Entries.Backup}, and
+then to rename it (atomically, where possible) to @file{Entries}.
+
address@hidden Entries.Static file, in CVS directory
address@hidden CVS/Entries.Static file
address@hidden Entries.Static
+The only relevant thing about this file is whether it
+exists or not. If it exists, then it means that only
+part of a directory was gotten and @sc{cvs} will
+not create additional files in that directory. To
+clear it, use the @code{update} command with the
address@hidden option, which will get the additional files
+and remove @file{Entries.Static}.
address@hidden FIXME: This needs to be better documented, in places
address@hidden other than Working Directory Storage.
address@hidden FIXCVS: The fact that this setting exists needs to
address@hidden be more visible to the user. For example "cvs
address@hidden status foo", in the case where the file would be
address@hidden gotten except for Entries.Static, might say
address@hidden something to distinguish this from other cases.
address@hidden One thing that periodically gets suggested is to
address@hidden have "cvs update" print something when it skips
address@hidden files due to Entries.Static, but IMHO that kind of
address@hidden noise pretty much makes the Entries.Static feature
address@hidden useless.
+
address@hidden Tag file, in CVS directory
address@hidden CVS/Tag file
address@hidden Sticky tags/dates, per-directory
address@hidden Per-directory sticky tags/dates
address@hidden Tag
+This file contains per-directory sticky tags or dates.
+The first character is @samp{T} for a branch tag,
address@hidden for a non-branch tag, or @samp{D} for a date,
+or another character to mean the file should be
+silently ignored, for future expansion. This character
+is followed by the tag or date. Note that
+per-directory sticky tags or dates are used for things
+like applying to files which are newly added; they
+might not be the same as the sticky tags or dates on
+individual files. For general information on sticky
+tags and dates, see @ref{Sticky tags}.
address@hidden FIXME: This needs to be much better documented,
address@hidden preferably not in the context of "working directory
address@hidden storage".
address@hidden FIXME: The Sticky tags node needs to discuss, or xref to
address@hidden someplace which discusses, per-directory sticky
address@hidden tags and the distinction with per-file sticky tags.
+
address@hidden Notify file, in CVS directory
address@hidden CVS/Notify file
address@hidden Notify
+This file stores notifications (for example, for
address@hidden or @code{unedit}) which have not yet been
+sent to the server. Its format is not yet documented
+here.
+
address@hidden Notify.tmp file, in CVS directory
address@hidden CVS/Notify.tmp file
address@hidden Notify.tmp
+This file is to @file{Notify} as @file{Entries.Backup}
+is to @file{Entries}. That is, to write @file{Notify},
+first write the new contents to @file{Notify.tmp} and
+then (atomically where possible), rename it to
address@hidden
+
address@hidden Base directory, in CVS directory
address@hidden CVS/Base directory
address@hidden Base
+If watches are in use, then an @code{edit} command
+stores the original copy of the file in the @file{Base}
+directory. This allows the @code{unedit} command to
+operate even if it is unable to communicate with the
+server.
+
address@hidden Baserev file, in CVS directory
address@hidden CVS/Baserev file
address@hidden Baserev
+The file lists the revision for each of the files in
+the @file{Base} directory. The format is:
+
address@hidden
address@hidden/@var{rev}/@var{expansion}
address@hidden example
+
address@hidden
+where @var{expansion} should be ignored, to allow for
+future expansion.
+
address@hidden Baserev.tmp file, in CVS directory
address@hidden CVS/Baserev.tmp file
address@hidden Baserev.tmp
+This file is to @file{Baserev} as @file{Entries.Backup}
+is to @file{Entries}. That is, to write @file{Baserev},
+first write the new contents to @file{Baserev.tmp} and
+then (atomically where possible), rename it to
address@hidden
+
address@hidden Template file, in CVS directory
address@hidden CVS/Template file
address@hidden Template
+This file contains the template specified by the
address@hidden file (@pxref{rcsinfo}). It is only used
+by the client; the non-client/server @sc{cvs} consults
address@hidden directly.
address@hidden table
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Intro administrative files
address@hidden The administrative files
address@hidden Administrative files (intro)
address@hidden Modules file
address@hidden CVSROOT, module name
address@hidden Defining modules (intro)
+
address@hidden FIXME: this node should be reorganized into "general
address@hidden information about admin files" and put the "editing
address@hidden admin files" stuff up front rather than jumping into
address@hidden the details of modules right away. Then the
address@hidden Administrative files node can go away, the information
address@hidden on each admin file distributed to a place appropriate
address@hidden to its function, and this node can contain a table
address@hidden listing each file and a @ref to its detailed description.
+
+The directory @file{$CVSROOT/CVSROOT} contains some @dfn{administrative
+files}. @xref{Administrative files}, for a complete description.
+You can use @sc{cvs} without any of these files, but
+some commands work better when at least the
address@hidden file is properly set up.
+
+The most important of these files is the @file{modules}
+file. It defines all modules in the repository. This
+is a sample @file{modules} file.
+
address@hidden FIXME: The CVSROOT line is a goofy example now that
address@hidden mkmodules doesn't exist.
address@hidden
+CVSROOT CVSROOT
+modules CVSROOT modules
+cvs gnu/cvs
+rcs gnu/rcs
+diff gnu/diff
+tc yoyodyne/tc
address@hidden example
+
+The @file{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
address@hidden The last four lines in the example
+above are examples of such lines.
+
address@hidden FIXME: might want to introduce the concept of options in modules
file
address@hidden (the old example which was here, -i mkmodules, is obsolete).
+
+The line that defines the module called @samp{modules}
+uses features that are not explained here.
address@hidden, for a full explanation of all the
+available features.
+
address@hidden FIXME: subsection without node is bogus
address@hidden Editing administrative files
address@hidden Editing administrative files
address@hidden Administrative files, editing them
+
+You edit the administrative files in the same way that you would edit
+any other module. Use @samp{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.
address@hidden @xref{Bad administrative files} for a hint
address@hidden about how to solve such situations.
address@hidden -- administrative file checking--
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Multiple repositories
address@hidden Multiple repositories
address@hidden Multiple repositories
address@hidden Repositories, multiple
address@hidden Many repositories
address@hidden Parallel repositories
address@hidden Disjoint repositories
address@hidden CVSROOT, 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 @code{CVSROOT} environment
+variable, the @samp{-d} option to @sc{cvs}, or (once
+you have checked out a working directory) by simply
+allowing @sc{cvs} to use the repository that was used
+to check out the working directory
+(@pxref{Specifying a repository}).
+
+The big advantage of having multiple repositories is
+that they can reside on different servers. With @sc{cvs}
+version 1.10, a single command cannot recurse into
+directories from different repositories. With development
+versions of @sc{cvs}, you can check out code from multiple
+servers into your working directory. @sc{cvs} will
+recurse and handle all the details of making
+connections to as many server machines as necessary to
+perform the requested command. Here is an example of
+how to set up a working directory:
+
address@hidden
+cvs -d server1:/cvs co dir1
+cd dir1
+cvs -d server2:/root co sdir
+cvs update
address@hidden example
+
+The @code{cvs co} commands set up the working
+directory, and then the @code{cvs update} command will
+contact server2, to update the dir1/sdir subdirectory,
+and server1, to update everything else.
+
address@hidden FIXME: Does the FAQ have more about this? I have a
address@hidden dim recollection, but I'm too lazy to check right now.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Creating a repository
address@hidden Creating a repository
+
address@hidden Repository, setting up
address@hidden Creating a repository
address@hidden Setting up a repository
+
+This section describes how to set up a @sc{cvs} repository for any
+sort of access method. After completing the setup described in this
+section, you should be able to access your @sc{cvs} repository immediately
+via the local access method and several remote access methods. For
+more information on setting up remote access to the repository you create
+in this section, please read the section on @xref{Remote repositories}.
+
+To set up a @sc{cvs} repository, first choose the
+machine and disk on which you want to store the
+revision history of the source files. CPU and memory
+requirements are modest, so most machines should be
+adequate. For details see @ref{Server requirements}.
address@hidden Possible that we should be providing a quick rule of
address@hidden thumb, like the 32M memory for the server. That
address@hidden might increase the number of people who are happy
address@hidden with the answer, without following the xref.
+
+To estimate disk space
+requirements, if you are importing RCS files from
+another system, the size of those files is the
+approximate initial size of your repository, or if you
+are starting without any version history, a rule of
+thumb is to allow for the server approximately three
+times the size of the code to be under @sc{cvs} for the
+repository (you will eventually outgrow this, but not
+for a while). On the machines on which the developers
+will be working, you'll want disk space for
+approximately one working directory for each developer
+(either the entire tree or a portion of it, depending
+on what each developer uses).
+
+The repository should be accessible
+(directly or via a networked file system) from all
+machines which want to use @sc{cvs} in server or local
+mode; the client machines need not have any access to
+it other than via the @sc{cvs} protocol. It is not
+possible to use @sc{cvs} to read from a repository
+which one only has read access to; @sc{cvs} needs to be
+able to create lock files (@pxref{Concurrency}).
+
address@hidden init (subcommand)
+To create a repository, run the @code{cvs init}
+command. It will set up an empty repository in the
address@hidden root specified in the usual way
+(@pxref{Repository}). For example,
+
address@hidden
+cvs -d /usr/local/cvsroot init
address@hidden example
+
address@hidden init} is careful to never overwrite any
+existing files in the repository, so no harm is done if
+you run @code{cvs init} on an already set-up
+repository.
+
address@hidden init} will enable history logging; if you
+don't want that, remove the history file after running
address@hidden init}. @xref{history file}.
+
address@hidden Backing up
address@hidden Backing up a repository
address@hidden Repository, backing up
address@hidden Backing up, repository
+
+There is nothing particularly magical about the files
+in the repository; for the most part it is possible to
+back them up just like any other files. However, there
+are a few issues to consider.
+
address@hidden Locks, cvs, and backups
address@hidden #cvs.rfl, and backups
+The first is that to be paranoid, one should either not
+use @sc{cvs} during the backup, or have the backup
+program lock @sc{cvs} while doing the backup. To not
+use @sc{cvs}, you might forbid logins to machines which
+can access the repository, turn off your @sc{cvs}
+server, or similar mechanisms. The details would
+depend on your operating system and how you have
address@hidden set up. To lock @sc{cvs}, you would create
address@hidden locks in each repository directory.
+See @ref{Concurrency}, for more on @sc{cvs} locks.
+Having said all this, if you just back up without any
+of these precautions, the results are unlikely to be
+particularly dire. Restoring from backup, the
+repository might be in an inconsistent state, but this
+would not be particularly hard to fix manually.
+
+When you restore a repository from backup, assuming
+that changes in the repository were made after the time
+of the backup, working directories which were not
+affected by the failure may refer to revisions which no
+longer exist in the repository. Trying to run @sc{cvs}
+in such directories will typically produce an error
+message. One way to get those changes back into the
+repository is as follows:
+
address@hidden @bullet
address@hidden
+Get a new working directory.
+
address@hidden
+Copy the files from the working directory from before
+the failure over to the new working directory (do not
+copy the contents of the @file{CVS} directories, of
+course).
+
address@hidden
+Working in the new working directory, use commands such
+as @code{cvs update} and @code{cvs diff} to figure out
+what has changed, and then when you are ready, commit
+the changes into the repository.
address@hidden itemize
+
address@hidden Moving a repository
address@hidden Moving a repository
address@hidden Repository, moving
address@hidden Moving a repository
address@hidden Copying a repository
+
+Just as backing up the files in the repository is
+pretty much like backing up any other files, if you
+need to move a repository from one place to another it
+is also pretty much like just moving any other
+collection of files.
+
+The main thing to consider is that working directories
+point to the repository. The simplest way to deal with
+a moved repository is to just get a fresh working
+directory after the move. Of course, you'll want to
+make sure that the old working directory had been
+checked in before the move, or you figured out some
+other way to make sure that you don't lose any
+changes. If you really do want to reuse the existing
+working directory, it should be possible with manual
+surgery on the @file{CVS/Repository} files. You can
+see @ref{Working directory storage}, for information on
+the @file{CVS/Repository} and @file{CVS/Root} files, but
+unless you are sure you want to bother, it probably
+isn't worth it.
address@hidden FIXME: Surgery on CVS/Repository should be avoided
address@hidden by making RELATIVE_REPOS the default.
address@hidden FIXME-maybe: might want some documented way to
address@hidden change the CVS/Root files in some particular tree.
address@hidden But then again, I don't know, maybe just having
address@hidden people do this in perl/shell/&c isn't so bad...
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Remote repositories
address@hidden Remote repositories
address@hidden Repositories, remote
address@hidden Remote repositories
address@hidden Client/Server Operation
address@hidden Server, CVS
address@hidden Remote repositories, port specification
address@hidden Repositories, remote, port specification
address@hidden Client/Server Operation, port specification
address@hidden pserver (client/server connection method), port specification
address@hidden kserver (client/server connection method), port specification
address@hidden gserver (client/server connection method), port specification
address@hidden port, specifying for remote repositories
+
+ Your working copy of the sources can be on a
+different machine than the repository. Using @sc{cvs}
+in this manner is known as @dfn{client/server}
+operation. You run @sc{cvs} on a machine which can
+mount your working directory, known as the
address@hidden, and tell it to communicate to a machine
+which can mount the repository, known as the
address@hidden Generally, using a remote
+repository is just like using a local one, except that
+the format of the repository name is:
+
address@hidden
+[:@var{method}:address@hidden:@var{password}]@@address@hidden:address@hidden/path/to/repository
address@hidden example
+
+Specifying a password in the repository name is not recommended during
+checkout, since this will cause @sc{cvs} to store a cleartext copy of the
+password in each created directory. @code{cvs login} first instead
+(@pxref{Password authentication client}).
+
+The details of exactly what needs to be set up depend
+on how you are connecting to the server.
+
address@hidden Should we try to explain which platforms are which?
address@hidden Platforms like unix and VMS, which only allow
address@hidden privileged programs to bind to sockets <1024 lose on
address@hidden :server:
address@hidden Platforms like Mac and VMS, whose rsh program is
address@hidden unusable or nonexistent, lose on :ext:
address@hidden Platforms like OS/2 and NT probably could plausibly
address@hidden default either way (modulo -b troubles).
+
address@hidden
+* Server requirements:: Memory and other resources for servers
+* The connection method:: Connection methods and method options
+* Connecting via rsh:: Using the @code{rsh} program to connect
+* Password authenticated:: Direct connections using passwords
+* GSSAPI authenticated:: Direct connections using GSSAPI
+* Kerberos authenticated:: Direct connections with Kerberos
+* Connecting via fork:: Using a forked @code{cvs server} to connect
+* Write proxies:: Distributing load across several CVS servers
address@hidden menu
+
address@hidden Server requirements
address@hidden Server requirements
+
+The quick answer to what sort of machine is suitable as
+a server is that requirements are modest---a server
+with 32M of memory or even less can handle a fairly
+large source tree with a fair amount of activity.
address@hidden Say something about CPU speed too? I'm even less sure
address@hidden what to say on that subject...
+
+The real answer, of course, is more complicated.
+Estimating the known areas of large memory consumption
+should be sufficient to estimate memory requirements.
+There are two such areas documented here; other memory
+consumption should be small by comparison (if you find
+that is not the case, let us know, as described in
address@hidden, so we can update this documentation).
+
+The first area of big memory consumption is large
+checkouts, when using the @sc{cvs} server. The server
+consists of two processes for each client that it is
+serving. Memory consumption on the child process
+should remain fairly small. Memory consumption on the
+parent process, particularly if the network connection
+to the client is slow, can be expected to grow to
+slightly more than the size of the sources in a single
+directory, or two megabytes, whichever is larger.
address@hidden "two megabytes" of course is SERVER_HI_WATER. But
address@hidden we don't mention that here because we are
address@hidden documenting the default configuration of CVS. If it
address@hidden is a "standard" thing to change that value, it
address@hidden should be some kind of run-time configuration.
address@hidden
address@hidden See cvsclient.texi for more on the design decision
address@hidden to not have locks in place while waiting for the
address@hidden client, which is what results in memory consumption
address@hidden as high as this.
+
+Multiplying the size of each @sc{cvs} server by the
+number of servers which you expect to have active at
+one time should give an idea of memory requirements for
+the server. For the most part, the memory consumed by
+the parent process probably can be swap space rather
+than physical memory.
address@hidden Has anyone verified that notion about swap space?
address@hidden I say it based pretty much on guessing that the
address@hidden ->text of the struct buffer_data only gets accessed
address@hidden in a first in, first out fashion, but I haven't
address@hidden looked very closely.
+
address@hidden What about disk usage in /tmp on the server? I think that
address@hidden it can be substantial, but I haven't looked at this
address@hidden again and tried to figure it out ("cvs import" is
address@hidden probably the worst case...).
+
+The second area of large memory consumption is
address@hidden, when checking in large files. This is
+required even for binary files. The rule of thumb is
+to allow about ten times the size of the largest file
+you will want to check in, although five times may be
+adequate. For example, if you want to check in a file
+which is 10 megabytes, you should have 100 megabytes of
+memory on the machine doing the checkin (the server
+machine for client/server, or the machine running
address@hidden for non-client/server). This can be swap
+space rather than physical memory. Because the memory
+is only required briefly, there is no particular need
+to allow memory for more than one such checkin at a
+time.
address@hidden The 5-10 times rule of thumb is from Paul Eggert for
address@hidden GNU diff. I don't think it is in the GNU diff
address@hidden manual or anyplace like that.
address@hidden
address@hidden Probably we could be saying more about
address@hidden non-client/server CVS.
address@hidden I would guess for non-client/server CVS in an NFS
address@hidden environment the biggest issues are the network and
address@hidden the NFS server.
+
+Resource consumption for the client is even more
+modest---any machine with enough capacity to run the
+operating system in question should have little
+trouble.
address@hidden Is that true? I think the client still wants to
address@hidden (bogusly) store entire files in memory at times.
+
+For information on disk space requirements, see
address@hidden a repository}.
+
address@hidden The connection method
address@hidden The connection method
+
+In its simplest form, the @var{method} portion of the repository string
+(@pxref{Remote repositories}) may be one of @samp{ext}, @samp{fork},
address@hidden, @samp{kserver}, @samp{local}, @samp{pserver}, and, on some
+platforms, @samp{server}.
+
+If @var{method} is not specified, and the repository
+name starts with a @samp{/}, then the default is @code{local}.
+If @var{method} is not specified, and the repository
+name does not start with a @samp{/}, then the default is @code{ext}
+or @code{server}, depending on your platform; both the @samp{ext}
+and @samp{server} methods are described in @ref{Connecting via rsh}.
+
address@hidden connection method options
address@hidden options, connection method
+The @code{ext}, @code{fork}, @code{gserver}, and @code{pserver} connection
+methods all accept optional method options, specified as part of the
address@hidden string, like so:
+
address@hidden
+:@var{method}[;@address@hidden:@var{other_connection_data}
address@hidden example
+
address@hidden is not sensitive to the case of @var{method} or @var{option},
though
+it may sometimes be sensitive to the case of @var{arg}. The possible method
+options are as follows:
+
address@hidden @code
address@hidden CVS_PROXY_PORT
address@hidden proxy, method option
address@hidden proxyport, method option
address@hidden proxies, web, connecting via
address@hidden web proxies, connecting via
address@hidden proxies, HTTP, connecting via
address@hidden HTTP proxies, connecting via
address@hidden address@hidden
address@hidden address@hidden
+These two method options can be used to connect via an HTTP tunnel style web
+proxy. @var{hostname} should be the name of the HTTP proxy server to connect
+through and @var{port} is the port number on the HTTP proxy server to connect
+via. @var{port} defaults to 8080.
+
address@hidden HTTP proxy server is not the same as a @sc{cvs} write proxy
+server - please see @ref{Write proxies} for more on @sc{cvs} write proxies.}
+
+For example, to connect pserver via a web proxy listening on port 8000 of
+www.myproxy.net, you would use a method of:
+
address@hidden
+:pserver;proxy=www.myproxy.net;proxyport=8000:@var{pserver_connection_string}
address@hidden example
+
address@hidden the above example, @var{pserver_connection_string} is still
+required to connect and authenticate to the CVS server, as noted in the
+upcoming sections on password authentication, @code{gserver}, and
address@hidden The example above only demonstrates a modification to the
address@hidden portion of the repository name.}
+
+These options first appeared in @sc{cvs} version 1.12.7 and are valid as
+modifcations to the @code{gserver} and @code{pserver} connection methods.
+
address@hidden CVS_RSH method option
address@hidden address@hidden
+This method option can be used with the @code{ext} method to specify the path
+the @sc{cvs} client will use to find the remote shell used to contact the
address@hidden server and takes precedence over any path specified in the
address@hidden environment variable (@pxref{Connecting via rsh}). For
+example, to connect to a @sc{cvs} server via the local
address@hidden/path/to/ssh/command} command, you could choose to specify the
following
address@hidden via the @code{CVS_RSH} method option:
+
address@hidden
+:ext;CVS_RSH=/path/to/ssh/command:@var{ext_connection_string}
address@hidden example
+
+This method option first appeared in @sc{cvs} version 1.12.11 and is valid only
+as a modifcation to the @code{ext} connection method.
+
address@hidden CVS_SERVER method option
address@hidden address@hidden
+This method option can be used with the @code{ext} and @code{fork} methods to
+specify the path @sc{cvs} will use to find the @sc{cvs} executable on the
address@hidden server and takes precedence over any path specified in the
address@hidden environment variable (@pxref{Connecting via rsh}). For
+example, to select the remote @file{/path/to/cvs/command} executable as your
address@hidden server application on the @sc{cvs} server machine, you could
choose to
+specify the following @var{path} via the @code{CVS_SERVER} method option:
+
address@hidden
+:ext;CVS_SERVER=/path/to/cvs/command:@var{ext_connection_string}
address@hidden example
+
address@hidden
+or, to select an executable named @samp{cvs-1.12.11}, assuming it is in your
address@hidden on the @sc{cvs} server:
+
address@hidden
+:ext;CVS_SERVER=cvs-1.12.11:@var{ext_connection_string}
address@hidden example
+
+This method option first appeared in @sc{cvs} version 1.12.11 and is valid
+as a modifcation to both the @code{ext} and @code{fork} connection methods.
+
address@hidden Redirect, method option
address@hidden address@hidden
+The @code{Redirect} method option determines whether the @sc{cvs} client will
+allow a @sc{cvs} server to redirect it to a different @sc{cvs} server, usually
+for write requests, as in a write proxy setup.
+
+A @var{boolean-state} of any value acceptable for boolean @file{CVSROOT/config}
+file options is acceptable here (@pxref{config}). For example, @samp{on},
address@hidden, @samp{true}, and @samp{false} are all valid values for
address@hidden @var{boolean-state} for the @code{Redirect} method option
+defaults to @samp{on}.
+
+This option will have no effect when talking to any non-secondary @sc{cvs}
+server. For more on write proxies and secondary servers, please see
address@hidden proxies}.
+
+This method option first appeared in @sc{cvs} version 1.12.11 and is valid only
+as a modifcation to the @code{ext} connection method.
address@hidden table
+
+As a further example, to combine both the @code{CVS_RSH} and @code{CVS_SERVER}
+options, a method specification like the following would work:
+
address@hidden
+:ext;CVS_RSH=/path/to/ssh/command;CVS_SERVER=/path/to/cvs/command:
address@hidden example
+
+This means that you would not need to have
+the @code{CVS_SERVER} or @code{CVS_RSH} environment
+variables set correctly. See @ref{Connecting via rsh}, for more details on
+these environment variables.
+
address@hidden Connecting via rsh
address@hidden Connecting with rsh
+
address@hidden rsh
address@hidden uses the @samp{rsh} protocol to perform these
+operations, so the remote user host needs to have a
address@hidden file which grants access to the local
+user. Note that the program that @sc{cvs} uses for this
+purpose may be specified using the @file{--with-rsh}
+flag to configure.
+
+For example, suppose you are the user @samp{mozart} on
+the local machine @samp{toe.example.com}, and the
+server machine is @samp{faun.example.org}. On
+faun, put the following line into the file
address@hidden in @samp{bach}'s home directory:
+
address@hidden
+toe.example.com mozart
address@hidden example
+
address@hidden
+Then test that @samp{rsh} is working with
+
address@hidden
+rsh -l bach faun.example.org 'echo $PATH'
address@hidden example
+
address@hidden CVS_SERVER, environment variable
+Next you have to make sure that @code{rsh} will be able
+to find the server. Make sure that the path which
address@hidden printed in the above example includes the
+directory containing a program named @code{cvs} which
+is the server. You need to set the path in
address@hidden, @file{.cshrc}, etc., not @file{.login}
+or @file{.profile}. Alternately, you can set the
+environment variable @code{CVS_SERVER} on the client
+machine to the filename of the server you want to use,
+for example @file{/usr/local/bin/cvs-1.6}.
+For the @code{ext} and @code{fork} methods, you may
+also specify @var{CVS_SERVER} as an otpion in the
address@hidden so that you may use different servers for
+differnt roots. See @ref{Remote repositories} for more
+details.
+
+There is no need to edit @file{inetd.conf} or start a
address@hidden server daemon.
+
address@hidden :server:, setting up
address@hidden :ext:, setting up
address@hidden Kerberos, using kerberized rsh
address@hidden SSH (rsh replacement)
address@hidden rsh replacements (Kerberized, SSH, &c)
+There are two access methods that you use in @code{CVSROOT}
+for rsh. @code{:server:} specifies an internal rsh
+client, which is supported only by some @sc{cvs} ports.
address@hidden:ext:} specifies an external rsh program. By
+default this is @code{rsh} (unless otherwise specified
+by the @file{--with-rsh} flag to configure) but you may set the
address@hidden environment variable to invoke another
+program which can access the remote server (for
+example, @code{remsh} on HP-UX 9 because @code{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 @code{rsh} is not
+suitable since it by default translates between CRLF
+and LF. The OS/2 @sc{cvs} port has a hack to pass @samp{-b}
+to @code{rsh} to get around this, but since this could
+potentially cause problems for programs other than the
+standard @code{rsh}, it may change in the future. If
+you set @code{CVS_RSH} to @code{SSH} or some other rsh
+replacement, the instructions in the rest of this
+section concerning @file{.rhosts} and so on are likely
+to be inapplicable; consult the documentation for your rsh
+replacement.
+
+You may choose to specify the @var{CVS_RSH} option as a method option
+in the @var{CVSROOT} string to allow you to use different connection tools
+for different roots (@pxref{The connection method}). For example, allowing
+some roots to use @code{CVS_RSH=remsh} and some to use
address@hidden for the @code{ext} method. See also
+the @ref{Remote repositories} for more details.
address@hidden See also the comment in src/client.c for rationale
address@hidden concerning "rsh" being the default and never
address@hidden "remsh".
+
+Continuing our example, supposing you want to access
+the module @file{foo} in the repository
address@hidden/usr/local/cvsroot/}, on machine
address@hidden, you are ready to go:
+
address@hidden
+cvs -d :ext:bach@@faun.example.org:/usr/local/cvsroot checkout foo
address@hidden example
+
address@hidden
+(The @file{bach@@} can be omitted if the username is
+the same on both the local and remote hosts.)
+
address@hidden Should we mention "rsh host echo hi" and "rsh host
address@hidden cat" (the latter followed by typing text and ^D)
address@hidden as troubleshooting techniques? Probably yes
address@hidden (people tend to have trouble setting this up),
address@hidden but this kind of thing can be hard to spell out.
+
address@hidden Password authenticated
address@hidden Direct connection with password authentication
+
+The @sc{cvs} client can also connect to the server
+using a password protocol. This is particularly useful
+if using @code{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.
+
address@hidden
+* Password authentication server:: Setting up the server
+* Password authentication client:: Using the client
+* Password authentication security:: What this method does and does not do
address@hidden menu
+
address@hidden Password authentication server
address@hidden Setting up the server for password authentication
+
+First of all, you probably want to tighten the
+permissions on the @file{$CVSROOT} and
address@hidden/CVSROOT} directories. See @ref{Password
+authentication security}, for more details.
+
address@hidden pserver (subcommand)
address@hidden Remote repositories, port specification
address@hidden Repositories, remote, port specification
address@hidden Client/Server Operation, port specification
address@hidden pserver (client/server connection method), port specification
address@hidden kserver (client/server connection method), port specification
address@hidden gserver (client/server connection method), port specification
address@hidden port, specifying for remote repositories
address@hidden Password server, setting up
address@hidden Authenticating server, setting up
address@hidden inetd, configuring for pserver
address@hidden xinetd, configuring for pserver
address@hidden FIXME: this isn't quite right regarding port
address@hidden numbers; CVS looks up "cvspserver" in
address@hidden /etc/services (on unix, but what about non-unix?).
+On the server side, the file @file{/etc/inetd.conf}
+needs to be edited so @code{inetd} knows to run the
+command @code{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 @code{CVS_AUTH_PORT} defined to
+something else, though. This can also be specified in the CVSROOT variable
+(@pxref{Remote repositories}) or overridden with the CVS_CLIENT_PORT
+environment variable (@pxref{Environment variables}).
+
+ If your @code{inetd} allows raw port numbers in
address@hidden/etc/inetd.conf}, then the following (all on a
+single line in @file{inetd.conf}) should be sufficient:
+
address@hidden
+2401 stream tcp nowait root /usr/local/bin/cvs
+cvs -f --allow-root=/usr/cvsroot pserver
address@hidden example
+
address@hidden
+(You could also use the
address@hidden option to specify a temporary directory.)
+
+The @samp{--allow-root} option specifies the allowable
address@hidden directory. Clients which attempt to use a
+different @sc{cvsroot} directory will not be allowed to
+connect. If there is more than one @sc{cvsroot}
+directory which you want to allow, repeat the option.
+(Unfortunately, many versions of @code{inetd} have very small
+limits on the number of arguments and/or the total length
+of the command. The usual solution to this problem is
+to have @code{inetd} run a shell script which then invokes
address@hidden with the necessary arguments.)
+
+ If your @code{inetd} wants a symbolic service
+name instead of a raw port number, then put this in
address@hidden/etc/services}:
+
address@hidden
+cvspserver 2401/tcp
address@hidden example
+
address@hidden
+and put @code{cvspserver} instead of @code{2401} in @file{inetd.conf}.
+
+If your system uses @code{xinetd} instead of @code{inetd},
+the procedure is slightly different.
+Create a file called @file{/etc/xinetd.d/cvspserver} containing the following:
+
address@hidden
+service cvspserver
address@hidden
+ port = 2401
+ socket_type = stream
+ protocol = tcp
+ wait = no
+ user = root
+ passenv = PATH
+ server = /usr/local/bin/cvs
+ server_args = -f --allow-root=/usr/cvsroot pserver
address@hidden
address@hidden example
+
address@hidden
+(If @code{cvspserver} is defined in @file{/etc/services}, you can omit
+the @code{port} line.)
+
+ Once the above is taken care of, restart your
address@hidden, or do whatever is necessary to force it
+to reread its initialization files.
+
+If you are having trouble setting this up, see
address@hidden
+
address@hidden CVS passwd file
address@hidden passwd (admin file)
+Because the client stores and transmits passwords in
+cleartext (almost---see @ref{Password authentication
+security}, for details), a separate @sc{cvs} password
+file is generally used, so people don't compromise
+their regular passwords when they access the
+repository. This file is
address@hidden/CVSROOT/passwd} (@pxref{Intro
+administrative files}). It uses a colon-separated
+format, similar to @file{/etc/passwd} on Unix systems,
+except that it has fewer fields: @sc{cvs} username,
+optional password, and an optional system username for
address@hidden to run as if authentication succeeds. Here is
+an example @file{passwd} file with five entries:
+
address@hidden
+anonymous:
+bach:ULtgRLXo7NRxs
+spwang:1sOp854gDF3DY
+melissa:tGX1fS8sun6rY:pubcvs
+qproj:XR4EZcEs0szik:pubcvs
address@hidden example
+
address@hidden
+(The passwords are encrypted according to the standard
+Unix @code{crypt()} function, so it is possible to
+paste in passwords directly from regular Unix
address@hidden/etc/passwd} files.)
+
+The first line in the example will grant access to any
address@hidden client attempting to authenticate as user
address@hidden, no matter what password they use,
+including an empty password. (This is typical for
+sites granting anonymous read-only access; for
+information on how to do the "read-only" part, see
address@hidden access}.)
+
+The second and third lines will grant access to
address@hidden and @code{spwang} if they supply their
+respective plaintext passwords.
+
address@hidden User aliases
+The fourth line will grant access to @code{melissa}, if
+she supplies the correct password, but her @sc{cvs}
+operations will actually run on the server side under
+the system user @code{pubcvs}. Thus, there need not be
+any system user named @code{melissa}, but there
address@hidden be one named @code{pubcvs}.
+
+The fifth line shows that system user identities can be
+shared: any client who successfully authenticates as
address@hidden will actually run as @code{pubcvs}, just
+as @code{melissa} does. That way you could create a
+single, shared system user for each project in your
+repository, and give each developer their own line in
+the @file{$CVSROOT/CVSROOT/passwd} file. The @sc{cvs}
+username on each line would be different, but the
+system username would be the same. The reason to have
+different @sc{cvs} usernames is that @sc{cvs} will log their
+actions under those names: when @code{melissa} commits
+a change to a project, the checkin is recorded in the
+project's history under the name @code{melissa}, not
address@hidden And the reason to have them share a
+system username is so that you can arrange permissions
+in the relevant area of the repository such that only
+that account has write-permission there.
+
+If the system-user field is present, all
+password-authenticated @sc{cvs} commands run as that
+user; if no system user is specified, @sc{cvs} simply
+takes the @sc{cvs} username as the system username and
+runs commands as that user. In either case, if there
+is no such user on the system, then the @sc{cvs}
+operation will fail (regardless of whether the client
+supplied a valid password).
+
+The password and system-user fields can both be omitted
+(and if the system-user field is omitted, then also
+omit the colon that would have separated it from the
+encrypted password). For example, this would be a
+valid @file{$CVSROOT/CVSROOT/passwd} file:
+
address@hidden
+anonymous::pubcvs
+fish:rKa5jzULzmhOo:kfogel
+sussman:1sOp854gDF3DY
address@hidden example
+
address@hidden
+When the password field is omitted or empty, then the
+client's authentication attempt will succeed with any
+password, including the empty string. However, the
+colon after the @sc{cvs} username is always necessary,
+even if the password is empty.
+
address@hidden can also fall back to use system authentication.
+When authenticating a password, the server first checks
+for the user in the @file{$CVSROOT/CVSROOT/passwd}
+file. If it finds the user, it will use that entry for
+authentication as described above. But if it does not
+find the user, or if the @sc{cvs} @file{passwd} file
+does not exist, then the server can try to authenticate
+the username and password using the operating system's
+user-lookup routines (this "fallback" behavior can be
+disabled by setting @code{SystemAuth=no} in the
address@hidden @file{config} file, @pxref{config}).
+
+The default fallback behavior is to look in
address@hidden/etc/passwd} for this system user unless your
+system has PAM (Pluggable Authentication Modules)
+and your @sc{cvs} server executable was configured to
+use it at compile time (using @code{./configure --enable-pam} - see the
+INSTALL file for more). In this case, PAM will be consulted instead.
+This means that @sc{cvs} can be configured to use any password
+authentication source PAM can be configured to use (possibilities
+include a simple UNIX password, NIS, LDAP, and others) in its
+global configuration file (usually @file{/etc/pam.conf}
+or possibly @file{/etc/pam.d/cvs}). See your PAM documentation
+for more details on PAM configuration.
+
+Note that PAM is an experimental feature in @sc{cvs} and feedback is
+encouraged. Please send a mail to one of the @sc{cvs} mailing lists
+(@code{info-cvs@@nongnu.org} or @code{bug-cvs@@nongnu.org}) if you use the
address@hidden PAM support.
+
address@hidden: Using PAM gives the system administrator much more
+flexibility about how @sc{cvs} users are authenticated but
+no more security than other methods. See below for more.}
+
+CVS needs an "auth", "account" and "session" module in the
+PAM configuration file. A typical PAM configuration
+would therefore have the following lines
+in @file{/etc/pam.conf} to emulate the standard @sc{cvs}
+system @file{/etc/passwd} authentication:
+
address@hidden
+cvs auth required pam_unix.so
+cvs account required pam_unix.so
+cvs session required pam_unix.so
address@hidden example
+
+The the equivalent @file{/etc/pam.d/cvs} would contain
+
address@hidden
+auth required pam_unix.so
+account required pam_unix.so
+session required pam_unix.so
address@hidden example
+
+Some systems require a full path to the module so that
address@hidden (Linux) would become something like
address@hidden/usr/lib/security/$ISA/pam_unix.so.1} (Sun Solaris).
+See the @file{contrib/pam} subdirectory of the @sc{cvs}
+source distribution for further example configurations.
+
+The PAM service name given above as "cvs" is just
+the service name in the default configuration and can be
+set using
address@hidden/configure --with-hardcoded-pam-service-name=<pam-service-name>}
+before compiling. @sc{cvs} can also be configured to use whatever
+name it is invoked as as its PAM service name using
address@hidden/configure --without-hardcoded-pam-service-name}, but this
+feature should not be used if you may not have control of the name
address@hidden will be invoked as.
+
+Be aware, also, that falling back to system
+authentication might be a security risk: @sc{cvs}
+operations would then be authenticated with that user's
+regular login password, and the password flies across
+the network in plaintext. See @ref{Password
+authentication security} for more on this.
+This may be more of a problem with PAM authentication
+because it is likely that the source of the system
+password is some central authentication service like
+LDAP which is also used to authenticate other services.
+
+On the other hand, PAM makes it very easy to change your password
+regularly. If they are given the option of a one-password system for
+all of their activities, users are often more willing to change their
+password on a regular basis.
+
+In the non-PAM configuration where the password is stored in the
address@hidden/passwd} file, it is difficult to change passwords on a
+regular basis since only administrative users (or in some cases
+processes that act as an administrative user) are typically given
+access to modify this file. Either there needs to be some
+hand-crafted web page or set-uid program to update the file, or the
+update needs to be done by submitting a request to an administrator to
+perform the duty by hand. In the first case, having to remember to
+update a separate password on a periodic basis can be difficult. In
+the second case, the manual nature of the change will typically mean
+that the password will not be changed unless it is absolutely
+necessary.
+
+Note that PAM administrators should probably avoid configuring
+one-time-passwords (OTP) for @sc{cvs} authentication/authorization. If
+OTPs are desired, the administrator may wish to encourage the use of
+one of the other Client/Server access methods. See the section on
address@hidden repositories} for a list of other methods.
+
+Right now, the only way to put a password in the
address@hidden @file{passwd} file is to paste it there from
+somewhere else. Someday, there may be a @code{cvs
+passwd} command.
+
+Unlike many of the files in @file{$CVSROOT/CVSROOT}, it
+is normal to edit the @file{passwd} file in-place,
+rather than via @sc{cvs}. This is because of the
+possible security risks of having the @file{passwd}
+file checked out to people's working copies. If you do
+want to include the @file{passwd} file in checkouts of
address@hidden/CVSROOT}, see @ref{checkoutlist}.
+
address@hidden We might also suggest using the @code{htpasswd} command
address@hidden from freely available web servers as well, but that
address@hidden would open up a can of worms in that the users next
address@hidden questions are likely to be "where do I get it?" and
address@hidden "how do I use it?"
address@hidden Also note that htpasswd, at least the version I had,
address@hidden likes to clobber the third field.
+
address@hidden Password authentication client
address@hidden Using the client with password authentication
address@hidden Login (subcommand)
address@hidden Password client, using
address@hidden Authenticated client, using
address@hidden :pserver:, setting up
+To run a @sc{cvs} command on a remote repository via
+the password-authenticating server, one specifies the
address@hidden protocol, optional username, repository host, an
+optional port number, and path to the repository. For example:
+
address@hidden
+cvs -d :pserver:faun.example.org:/usr/local/cvsroot checkout someproj
address@hidden example
+
address@hidden
+or
+
address@hidden
+CVSROOT=:pserver:bach@@faun.example.org:2401/usr/local/cvsroot
+cvs checkout someproj
address@hidden example
+
+However, unless you're connecting to a public-access
+repository (i.e., one where that username doesn't
+require a password), you'll need to supply a password or @dfn{log in} first.
+Logging in verifies your password with the repository and stores it in a file.
+It's done with the @code{login} command, which will
+prompt you interactively for the password if you didn't supply one as part of
address@hidden:
+
address@hidden
+cvs -d :pserver:bach@@faun.example.org:/usr/local/cvsroot login
+CVS password:
address@hidden example
+
address@hidden
+or
+
address@hidden
+cvs -d :pserver:bach:p4ss30rd@@faun.example.org:/usr/local/cvsroot login
address@hidden example
+
+After you enter the password, @sc{cvs} verifies it with
+the server. If the verification succeeds, then that
+combination of username, host, repository, and password
+is permanently recorded, so future transactions with
+that repository won't require you to run @code{cvs
+login}. (If verification fails, @sc{cvs} will exit
+complaining that the password was incorrect, and
+nothing will be recorded.)
+
+The records are stored, by default, in the file
address@hidden/.cvspass}. That file's format is
+human-readable, and to a degree human-editable, but
+note that the passwords are not stored in
+cleartext---they are trivially encoded to protect them
+from "innocent" compromise (i.e., inadvertent viewing
+by a system administrator or other non-malicious
+person).
+
address@hidden CVS_PASSFILE, environment variable
+You can change the default location of this file by
+setting the @code{CVS_PASSFILE} environment variable.
+If you use this variable, make sure you set it
address@hidden @code{cvs login} is run. If you were to
+set it after running @code{cvs login}, then later
address@hidden commands would be unable to look up the
+password for transmission to the server.
+
+Once you have logged in, all @sc{cvs} commands using
+that remote repository and username will authenticate
+with the stored password. So, for example
+
address@hidden
+cvs -d :pserver:bach@@faun.example.org:/usr/local/cvsroot checkout foo
address@hidden example
+
address@hidden
+should just work (unless the password changes on the
+server side, in which case you'll have to re-run
address@hidden login}).
+
+Note that if the @samp{:pserver:} were not present in
+the repository specification, @sc{cvs} would assume it
+should use @code{rsh} to connect with the server
+instead (@pxref{Connecting via rsh}).
+
+Of course, once you have a working copy checked out and
+are running @sc{cvs} commands from within it, there is
+no longer any need to specify the repository
+explicitly, because @sc{cvs} can deduce the repository
+from the working copy's @file{CVS} subdirectory.
+
address@hidden FIXME: seems to me this needs somewhat more
address@hidden explanation.
address@hidden Logout (subcommand)
+The password for a given remote repository can be
+removed from the @code{CVS_PASSFILE} by using the
address@hidden logout} command.
+
address@hidden Password authentication security
address@hidden Security considerations with password authentication
+
address@hidden Security, of pserver
+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.
+
address@hidden FIXME: The bit about "access to the repository
address@hidden implies general access to the system is *not* specific
address@hidden to pserver; it applies to kerberos and SSH and
address@hidden everything else too. Should reorganize the
address@hidden documentation to make this clear.
+The separate @sc{cvs} password file (@pxref{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
+non-read-only
+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 @sc{cvs} to prevent that,
+but no one has done so as of this writing.
address@hidden OpenBSD uses chroot() and copies the repository to
address@hidden provide anonymous read-only access (for details see
address@hidden http://www.openbsd.org/anoncvs.shar). While this
address@hidden closes the most obvious holes, I'm not sure it
address@hidden closes enough holes to recommend it (plus it is
address@hidden *very* easy to accidentally screw up a setup of this
address@hidden type).
+
+Note that because the @file{$CVSROOT/CVSROOT} directory
+contains @file{passwd} and other files which are used
+to check security, you must control the permissions on
+this directory as tightly as the permissions on
address@hidden/etc}. The same applies to the @file{$CVSROOT}
+directory itself and any directory
+above it in the tree. Anyone who has write access to
+such a directory will have the ability to become any
+user on the system. Note that these permissions are
+typically tighter than you would use if you are not
+using pserver.
address@hidden TODO: Would be really nice to document/implement a
address@hidden scheme where the CVS server can run as some non-root
address@hidden user, e.g. "cvs". CVSROOT/passwd would contain a
address@hidden bunch of entries of the form foo:xxx:cvs (or the "cvs"
address@hidden would be implicit). This would greatly reduce
address@hidden security risks such as those hinted at in the
address@hidden previous paragraph. I think minor changes to CVS
address@hidden might be required but mostly this would just need
address@hidden someone who wants to play with it, document it, &c.
+
+In summary, anyone who gets the password gets
+repository access (which may imply 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.
+
address@hidden GSSAPI authenticated
address@hidden Direct connection with GSSAPI
+
address@hidden GSSAPI
address@hidden Security, GSSAPI
address@hidden :gserver:, setting up
address@hidden Kerberos, using :gserver:
+GSSAPI is a generic interface to network security
+systems such as Kerberos 5.
+If you have a working GSSAPI library, you can have
address@hidden connect via a direct @sc{tcp} connection,
+authenticating with GSSAPI.
+
+To do this, @sc{cvs} needs to be compiled with GSSAPI
+support; when configuring @sc{cvs} it tries to detect
+whether GSSAPI libraries using Kerberos version 5 are
+present. You can also use the @file{--with-gssapi}
+flag to configure.
+
+The connection is authenticated using GSSAPI, but the
+message stream is @emph{not} authenticated by default.
+You must use the @code{-a} global option to request
+stream authentication.
+
+The data transmitted is @emph{not} encrypted by
+default. Encryption support must be compiled into both
+the client and the server; use the
address@hidden configure option to turn it on.
+You must then use the @code{-x} global option to
+request encryption.
+
+GSSAPI connections are handled on the server side by
+the same server which handles the password
+authentication server; see @ref{Password authentication
+server}. If you are using a GSSAPI mechanism such as
+Kerberos which provides for strong authentication, you
+will probably want to disable the ability to
+authenticate via cleartext passwords. To do so, create
+an empty @file{CVSROOT/passwd} password file, and set
address@hidden in the config file
+(@pxref{config}).
+
+The GSSAPI server uses a principal name of
+cvs/@var{hostname}, where @var{hostname} is the
+canonical name of the server host. You will have to
+set this up as required by your GSSAPI mechanism.
+
+To connect using GSSAPI, use the @samp{:gserver:} method. For
+example,
+
address@hidden
+cvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo
address@hidden example
+
address@hidden Kerberos authenticated
address@hidden Direct connection with Kerberos
+
address@hidden Kerberos, using :kserver:
address@hidden Security, Kerberos
address@hidden :kserver:, setting up
+The easiest way to use Kerberos is to use the Kerberos
address@hidden, as described in @ref{Connecting via rsh}.
+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 @sc{tcp} connection,
+authenticating with Kerberos.
+
+This section concerns the Kerberos network security
+system, version 4. Kerberos version 5 is supported via
+the GSSAPI generic network security interface, as
+described in the previous section.
+
+To do this, @sc{cvs} needs to be compiled with Kerberos
+support; when configuring @sc{cvs} it tries to detect
+whether Kerberos is present or you can use the
address@hidden flag to configure.
+
+The data transmitted is @emph{not} encrypted by
+default. Encryption support must be compiled into both
+the client and server; use the
address@hidden configure option to turn it
+on. You must then use the @code{-x} global option to
+request encryption.
+
+The CVS client will attempt to connect to port 1999 by default.
+
address@hidden kinit
+When you want to use @sc{cvs}, get a ticket in the
+usual way (generally @code{kinit}); it must be a ticket
+which allows you to log into the server machine. Then
+you are ready to go:
+
address@hidden
+cvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo
address@hidden example
+
+Previous versions of @sc{cvs} would fall back to a
+connection via rsh; this version will not do so.
+
address@hidden Connecting via fork
address@hidden Connecting with fork
+
address@hidden fork, access method
address@hidden :fork:, setting up
+This access method allows you to connect to a
+repository on your local disk via the remote protocol.
+In other words it does pretty much the same thing as
address@hidden:local:}, but various quirks, bugs and the like are
+those of the remote @sc{cvs} rather than the local
address@hidden
+
+For day-to-day operations you might prefer either
address@hidden:local:} or @code{:fork:}, depending on your
+preferences. Of course @code{:fork:} comes in
+particularly handy in testing or
+debugging @code{cvs} and the remote protocol.
+Specifically, we avoid all of the network-related
+setup/configuration, timeouts, and authentication
+inherent in the other remote access methods but still
+create a connection which uses the remote protocol.
+
+To connect using the @code{fork} method, use
address@hidden:fork:} and the pathname to your local
+repository. For example:
+
address@hidden
+cvs -d :fork:/usr/local/cvsroot checkout foo
address@hidden example
+
address@hidden CVS_SERVER, and :fork:
+As with @code{:ext:}, the server is called @samp{cvs}
+by default, or the value of the @code{CVS_SERVER}
+environment variable.
+
+
address@hidden Write proxies
address@hidden Distributing load across several CVS servers
+
address@hidden PrimaryServer, in CVSROOT/config
address@hidden Primary server
address@hidden Secondary server
address@hidden proxy, write
address@hidden write proxy
address@hidden can be configured to distribute usage across several @sc{cvs}
+servers. This is accomplished by means of one or more @dfn{write proxies}, or
address@hidden servers}, for a single @dfn{primary server}.
+
+When a @sc{cvs} client accesses a secondary server and only sends read
+requests, then the secondary server handles the entire request. If the client
+sends any write requests, however, the secondary server asks the client to
+redirect its write request to the primary server, if the client supports
+redirect requests, and otherwise becomes a transparent proxy for the primary
+server, which actually handles the write request.
+
+In this manner, any number of read-only secondary servers may be configured as
+write proxies for the primary server, effectively distributing the load from
+all read operations between the secondary servers and restricting the load on
+the primary server to write operations and pushing changes to the secondaries.
+
+Primary servers will not automatically push changes to secondaries. This must
+be configured via @file{loginfo}, @file{postadmin}, @file{posttag}, &
address@hidden scripts (@pxref{Trigger Scripts}) like the following:
+
address@hidden
+ALL rsync -gopr -essh ./ secondary:/cvsroot/%p &
address@hidden example
+
+You would probably actually want to lock directories for write on the secondary
+and for read on the primary before running the @samp{rsync} in the above
+example, but describing such a setup is beyond the scope of this document.
+
+A secondary advantage of a write proxy setup is that users pointing at the
+secondary server can still execute fast read operations while on a network that
+connects to the primary over a slow link or even one where the link to the
+primary is periodically broken. Only write operations will require the network
+link to the primary.
+
+To configure write proxies, the primary must be specified with the
address@hidden option in @file{CVSROOT/config} (@pxref{config}). For the
+transparent proxy mode to work, all secondary servers must also be running the
+same version of the @sc{cvs} server, or at least one that provides the same
+list of supported requests to the client as the primary server. This is not
+necessary for redirection.
+
+Once a primary server is configured, secondary servers may be configured by:
+
address@hidden
address@hidden
+Duplicating the primary repository at the new location.
address@hidden
+Setting up the @file{loginfo}, @file{postadmin}, @file{posttag}, and
address@hidden files on the primary to propagate writes to the new secondary.
address@hidden
+Configure remote access to the secondary(ies) as you would configure access
+to any other CVS server (@pxref{Remote repositories}).
address@hidden
+Ensuring that @address@hidden is passed to
address@hidden incovations of the secondary server if the path to the @sc{cvs}
+repository directory is different on the two servers and you wish to support
+clients that do not handle the @samp{Redirect} resopnse (CVS 1.12.9 and earlier
+clients do not handle the @samp{Redirect} response).
+
+Please note, again, that writethrough proxy suport requires
address@hidden@var{secondary-cvsroot}} to be specified for @strong{all}
+incovations of the secondary server, not just @samp{pserver} invocations.
+This may require a wrapper script for the @sc{cvs} executable
+on your server machine.
address@hidden enumerate
+
+
address@hidden
---------------------------------------------------------------------
address@hidden Read-only access
address@hidden Read-only repository access
address@hidden Read-only repository access
address@hidden readers (admin file)
address@hidden writers (admin file)
+
+ It is possible to grant read-only repository
+access to people using the password-authenticated
+server (@pxref{Password authenticated}). (The
+other access methods do not have explicit support for
+read-only users because those methods all assume login
+access to the repository machine anyway, and therefore
+the user can do whatever local file permissions allow
+her to do.)
+
+ A user who has read-only access can do only
+those @sc{cvs} operations which do not modify the
+repository, except for certain ``administrative'' files
+(such as lock files and the history file). It may be
+desirable to use this feature in conjunction with
+user-aliasing (@pxref{Password authentication server}).
+
+Unlike with previous versions of @sc{cvs}, read-only
+users should be able merely to read the repository, and
+not to execute programs on the server or otherwise gain
+unexpected levels of access. Or to be more accurate,
+the @emph{known} holes have been plugged. Because this
+feature is new and has not received a comprehensive
+security audit, you should use whatever level of
+caution seems warranted given your attitude concerning
+security.
+
+ There are two ways to specify read-only access
+for a user: by inclusion, and by exclusion.
+
+ "Inclusion" means listing that user
+specifically in the @file{$CVSROOT/CVSROOT/readers}
+file, which is simply a newline-separated list of
+users. Here is a sample @file{readers} file:
+
address@hidden
+melissa
+splotnik
+jrandom
address@hidden example
+
address@hidden
+ (Don't forget the newline after the last user.)
+
+ "Exclusion" means explicitly listing everyone
+who has @emph{write} access---if the file
+
address@hidden
+$CVSROOT/CVSROOT/writers
address@hidden example
+
address@hidden
+exists, then only
+those users listed in it have write access, and
+everyone else has read-only access (of course, even the
+read-only users still need to be listed in the
address@hidden @file{passwd} file). The
address@hidden file has the same format as the
address@hidden file.
+
+ Note: if your @sc{cvs} @file{passwd}
+file maps cvs users onto system users (@pxref{Password
+authentication server}), make sure you deny or grant
+read-only access using the @emph{cvs} usernames, not
+the system usernames. That is, the @file{readers} and
address@hidden files contain cvs usernames, which may
+or may not be the same as system usernames.
+
+ Here is a complete description of the server's
+behavior in deciding whether to grant read-only or
+read-write access:
+
+ If @file{readers} exists, and this user is
+listed in it, then she gets read-only access. Or if
address@hidden exists, and this user is NOT listed in
+it, then she also gets read-only access (this is true
+even if @file{readers} exists but she is not listed
+there). Otherwise, she gets full read-write access.
+
+ Of course there is a conflict if the user is
+listed in both files. This is resolved in the more
+conservative way, it being better to protect the
+repository too much than too little: such a user gets
+read-only access.
+
address@hidden Server temporary directory
address@hidden Temporary directories for the server
address@hidden Temporary directories, and server
address@hidden Server, temporary directories
+
+While running, the @sc{cvs} server creates temporary
+directories. They are named
+
address@hidden
address@hidden
address@hidden example
+
address@hidden
+where @var{pid} is the process identification number of
+the server.
+They are located in the directory specified by
+the @samp{-T} global option (@pxref{Global options}),
+the @code{TMPDIR} environment variable (@pxref{Environment variables}),
+or, failing that, @file{/tmp}.
+
+In most cases the server will remove the temporary
+directory when it is done, whether it finishes normally
+or abnormally. However, there are a few cases in which
+the server does not or cannot remove the temporary
+directory, for example:
+
address@hidden @bullet
address@hidden
+If the server aborts due to an internal server error,
+it may preserve the directory to aid in debugging
+
address@hidden
+If the server is killed in a way that it has no way of
+cleaning up (most notably, @samp{kill -KILL} on unix).
+
address@hidden
+If the system shuts down without an orderly shutdown,
+which tells the server to clean up.
address@hidden itemize
+
+In cases such as this, you will need to manually remove
+the @address@hidden directories. As long as
+there is no server running with process identification
+number @var{pid}, it is safe to do so.
+
address@hidden
---------------------------------------------------------------------
address@hidden Starting a new project
address@hidden Starting a project with CVS
address@hidden Starting a project with CVS
address@hidden Creating a project
+
address@hidden --moduledb--
+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 @sc{cvs} does have some
+quirks particularly in the area of renaming
+directories. @xref{Moving files}.
+
+What to do next depends on the situation at hand.
+
address@hidden
+* Setting up the files:: Getting the files into the repository
+* Defining the module:: How to make a module of the files
address@hidden menu
address@hidden -- File permissions!
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Setting up the files
address@hidden 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.
+
address@hidden -- The contributed scripts
address@hidden
+* From files:: This method is useful with old projects
+ where files already exists.
+* From other version control systems:: Old projects where you want to
+ preserve history from another system.
+* From scratch:: Creating a directory tree from scratch.
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden From files
address@hidden Creating a directory tree from a number of files
address@hidden Importing files
+
+When you begin using @sc{cvs}, you will probably already have several
+projects that can be
+put under @sc{cvs} control. In these cases the easiest way is to use the
address@hidden command. An example is probably the easiest way to
+explain how to use it. If the files you want to install in
address@hidden reside in @address@hidden, and you want them to appear in the
+repository as @file{$CVSROOT/yoyodyne/@var{rdir}}, you can do this:
+
address@hidden
+$ cd @var{wdir}
+$ cvs import -m "Imported sources" yoyodyne/@var{rdir} yoyo start
address@hidden example
+
+Unless you supply a log message with the @samp{-m}
+flag, @sc{cvs} starts an editor and prompts for a
+message. The string @samp{yoyo} is a @dfn{vendor tag},
+and @samp{start} is a @dfn{release tag}. They may fill
+no purpose in this context, but since @sc{cvs} requires
+them they must be present. @xref{Tracking sources}, for
+more information about them.
+
+You can now verify that it worked, and remove your
+original source directory.
address@hidden FIXME: Need to say more about "verify that it
address@hidden worked". What should the user look for in the output
address@hidden from "diff -r"?
+
address@hidden
+$ cd ..
+$ cvs checkout yoyodyne/@var{rdir} # @r{Explanation below}
+$ diff -r @var{wdir} yoyodyne/@var{rdir}
+$ rm -r @var{wdir}
address@hidden example
+
address@hidden
+Erasing the original sources is a good idea, to make sure that you do
+not accidentally edit them in @var{wdir}, bypassing @sc{cvs}.
+Of course, it would be wise to make sure that you have
+a backup of the sources before you remove them.
+
+The @code{checkout} 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},
+as it did in the example above.
+
+It is a good idea to check that the permissions
address@hidden sets on the directories inside @code{$CVSROOT}
+are reasonable, and that they belong to the proper
+groups. @xref{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. @xref{Wrappers}.
+
address@hidden The node name is too long, but I am having trouble
address@hidden thinking of something more concise.
address@hidden From other version control systems
address@hidden Creating Files From Other Version Control Systems
address@hidden Importing files, from other version control systems
+
+If you have a project which you are maintaining with
+another version control system, such as @sc{rcs}, you
+may wish to put the files from that project into
address@hidden, and preserve the revision history of the
+files.
+
address@hidden @asis
address@hidden RCS, importing files from
address@hidden From RCS
+If you have been using @sc{rcs}, find the @sc{rcs}
+files---usually a file named @file{foo.c} will have its
address@hidden file in @file{RCS/foo.c,v} (but it could be
+other places; consult the @sc{rcs} documentation for
+details). Then create the appropriate directories in
address@hidden if they do not already exist. Then copy the
+files into the appropriate directories in the @sc{cvs}
+repository (the name in the repository must be the name
+of the source file with @samp{,v} added; the files go
+directly in the appropriate directory of the repository,
+not in an @file{RCS} subdirectory). This is one of the
+few times when it is a good idea to access the @sc{cvs}
+repository directly, rather than using @sc{cvs}
+commands. Then you are ready to check out a new
+working directory.
address@hidden Someday there probably should be a "cvs import -t
address@hidden rcs" or some such. It could even create magic
address@hidden branches. It could also do something about the case
address@hidden where the RCS file had a (non-magic) "0" branch.
+
+The @sc{rcs} file should not be locked when you move it
+into @sc{cvs}; if it is, @sc{cvs} will have trouble
+letting you operate on it.
address@hidden What is the easiest way to unlock your files if you
address@hidden have them locked? Especially if you have a lot of them?
address@hidden This is a CVS bug/misfeature; importing RCS files
address@hidden should ignore whether they are locked and leave them in
address@hidden an unlocked state. Yet another reason for a separate
address@hidden "import RCS file" command.
+
address@hidden How many is "many"? Or do they just import RCS files?
address@hidden From another version control system
+Many version control systems have the ability to export
address@hidden files in the standard format. If yours does,
+export the @sc{rcs} files and then follow the above
+instructions.
+
+Failing that, probably your best bet is to write a
+script that will check out the files one revision at a
+time using the command line interface to the other
+system, and then check the revisions into @sc{cvs}.
+The @file{sccs2rcs} script mentioned below may be a
+useful example to follow.
+
address@hidden SCCS, importing files from
address@hidden From SCCS
+There is a script in the @file{contrib} directory of
+the @sc{cvs} source distribution called @file{sccs2rcs}
+which converts @sc{sccs} files to @sc{rcs} files.
+Note: you must run it on a machine which has both
address@hidden and @sc{rcs} installed, and like everything
+else in contrib it is unsupported (your mileage may
+vary).
+
address@hidden PVCS, importing files from
address@hidden From PVCS
+There is a script in the @file{contrib} directory of
+the @sc{cvs} source distribution called @file{pvcs_to_rcs}
+which converts @sc{pvcs} archives to @sc{rcs} files.
+You must run it on a machine which has both
address@hidden and @sc{rcs} installed, and like everything
+else in contrib it is unsupported (your mileage may
+vary). See the comments in the script for details.
address@hidden table
address@hidden CMZ and/or PATCHY were systems that were used in the
address@hidden high energy physics community (especially for
address@hidden CERNLIB). CERN has replaced them with CVS, but the
address@hidden CAR format seems to live on as a way to submit
address@hidden changes. There is a program car2cvs which converts
address@hidden but I'm not sure where one gets a copy.
address@hidden Not sure it is worth mentioning here, since it would
address@hidden appear to affect only one particular community.
address@hidden Best page for more information is:
address@hidden http://wwwcn1.cern.ch/asd/cvs/index.html
address@hidden See also:
address@hidden http://ecponion.cern.ch/ecpsa/cernlib.html
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden From scratch
address@hidden Creating a directory tree from scratch
+
address@hidden Also/instead should be documenting
address@hidden $ cvs co -l .
address@hidden $ mkdir tc
address@hidden $ cvs add tc
address@hidden $ cd tc
address@hidden $ mkdir man
address@hidden $ cvs add man
address@hidden etc.
address@hidden Using import to create the directories only is
address@hidden probably a somewhat confusing concept.
+For a new project, the easiest thing to do is probably
+to create an empty directory structure, like this:
+
address@hidden
+$ mkdir tc
+$ mkdir tc/man
+$ mkdir tc/testing
address@hidden example
+
+After that, you use the @code{import} command to create
+the corresponding (empty) directory structure inside
+the repository:
+
address@hidden
+$ cd tc
+$ cvs import -m "Created directory structure" yoyodyne/@var{dir} yoyo start
address@hidden example
+
+This will add yoyodyne/@var{dir} as a directory under
address@hidden
+
+Use @code{checkout} to get the new project. Then, use @code{add}
+to add files (and new directories) as needed.
+
address@hidden
+$ cd ..
+$ cvs co yoyodyne/@var{dir}
address@hidden example
+
+Check that the permissions @sc{cvs} sets on the
+directories inside @code{$CVSROOT} are reasonable.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Defining the module
address@hidden Defining the module
address@hidden Defining a module
address@hidden Editing the modules file
address@hidden Module, defining
address@hidden Modules file, changing
+
+The next step is to define the module in the
address@hidden 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.
+
address@hidden
address@hidden
+Get a working copy of the modules file.
+
address@hidden
+$ cvs checkout CVSROOT/modules
+$ cd CVSROOT
address@hidden example
+
address@hidden
+Edit the file and insert a line that defines the module. @xref{Intro
+administrative files}, for an introduction. @xref{modules}, for a full
+description of the modules file. You can use the
+following line to define the module @samp{tc}:
+
address@hidden
+tc yoyodyne/tc
address@hidden example
+
address@hidden
+Commit your changes to the modules file.
+
address@hidden
+$ cvs commit -m "Added the tc module." modules
address@hidden example
+
address@hidden
+Release the modules module.
+
address@hidden
+$ cd ..
+$ cvs release -d CVSROOT
address@hidden example
address@hidden enumerate
+
address@hidden
---------------------------------------------------------------------
address@hidden Revisions
address@hidden Revisions
+
+For many uses of @sc{cvs}, one doesn't need to worry
+too much about revision numbers; @sc{cvs} assigns
+numbers such as @code{1.1}, @code{1.2}, and so on, and
+that is all one needs to know. However, some people
+prefer to have more knowledge and control concerning
+how @sc{cvs} assigns revision numbers.
+
+If one wants to keep track of a set of revisions
+involving more than one file, such as which revisions
+went into a particular release, one uses a @dfn{tag},
+which is a symbolic revision which can be assigned to a
+numeric revision in each file.
+
address@hidden
+* Revision numbers:: The meaning of a revision number
+* Versions revisions releases:: Terminology used in this manual
+* Assigning revisions:: Assigning revisions
+* Tags:: Tags--Symbolic revisions
+* Tags (builtin):: Tags--builtin
+* Tagging the working directory:: The cvs tag command
+* Tagging by date/tag:: The cvs rtag command
+* Modifying tags:: Adding, renaming, and deleting tags
+* Tagging add/remove:: Tags with adding and removing files
+* Sticky tags:: Certain tags are persistent
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Revision numbers
address@hidden Revision numbers
address@hidden Revision numbers
address@hidden Revision tree
address@hidden Linear development
address@hidden Number, revision-
address@hidden Decimal revision number
address@hidden Branch number
address@hidden Number, branch
+
+Each version of a file has a unique @dfn{revision
+number}. Revision numbers look like @samp{1.1},
address@hidden, @samp{1.3.2.2} or even @samp{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.
+
address@hidden
+ +-----+ +-----+ +-----+ +-----+ +-----+
+ ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
+ +-----+ +-----+ +-----+ +-----+ +-----+
address@hidden example
+
+It is also possible to end up with numbers containing
+more than one period, for example @samp{1.3.2.2}. Such
+revisions represent revisions on branches
+(@pxref{Branching and merging}); such revision numbers
+are explained in detail in @ref{Branches and
+revisions}.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Versions revisions releases
address@hidden Versions, revisions and releases
address@hidden Revisions, versions and releases
address@hidden Versions, revisions and releases
address@hidden Releases, revisions and versions
+
+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}.
+
+Versions in the first sense are called @dfn{revisions}
+in this document, and versions in the second sense are
+called @dfn{releases}. To avoid confusion, the word
address@hidden is almost never used in this document.
+
address@hidden Assigning revisions
address@hidden Assigning revisions
+
address@hidden We avoid the "major revision" terminology. It seems
address@hidden like jargon. Hopefully "first number" is clear enough.
address@hidden
address@hidden Well, in the context of software release numbers,
address@hidden "major" and "minor" release or version numbers are
address@hidden documented in at least the GNU Coding Standards, but I'm
address@hidden still not sure I find that a valid reason to apply the
address@hidden terminology to RCS revision numbers. "First", "Second",
address@hidden "subsequent", and so on is almost surely clearer,
address@hidden especially to a novice reader. -DRP
+By default, @sc{cvs} will assign numeric revisions by
+leaving the first number the same and incrementing the
+second number. For example, @code{1.1}, @code{1.2},
address@hidden, etc.
+
+When adding a new file, the second number will always
+be one and the first number will equal the highest
+first number of any file in that directory. For
+example, the current directory contains files whose
+highest numbered revisions are @code{1.7}, @code{3.1},
+and @code{4.12}, then an added file will be given the
+numeric revision @code{4.1}.
+(When using client/server @sc{cvs},
+only files that are actually sent to the server are considered.)
+
address@hidden This is sort of redundant with something we said a
address@hidden while ago. Somewhere we need a better way of
address@hidden introducing how the first number can be anything
address@hidden except "1", perhaps. Also I don't think this
address@hidden presentation is clear on why we are discussing releases
address@hidden and first numbers of numeric revisions in the same
address@hidden breath.
+Normally there is no reason to care
+about the revision numbers---it is easier to treat them
+as internal numbers that @sc{cvs} maintains, and tags
+provide a better way to distinguish between things like
+release 1 versus release 2 of your product
+(@pxref{Tags}). However, if you want to set the
+numeric revisions, the @samp{-r} option to @code{cvs
+commit} can do that. The @samp{-r} option implies the
address@hidden option, in the sense that it causes the
+files to be committed even if they are not modified.
+
+For example, to bring all your files up to
+revision 3.0 (including those that haven't changed),
+you might invoke:
+
address@hidden
+$ cvs commit -r 3.0
address@hidden example
+
+Note that the number you specify with @samp{-r} must be
+larger than any existing revision number. That is, if
+revision 3.0 exists, you cannot @samp{cvs commit
+-r 1.3}. If you want to maintain several releases in
+parallel, you need to use a branch (@pxref{Branching and merging}).
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Tags
address@hidden Tags--Symbolic revisions
address@hidden Tags
+
+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 @sc{cvs} the revision numbers might change several times
+between two releases. As an example, some of the
+source files that make up @sc{rcs} 5.6 have the following
+revision numbers:
address@hidden RCS revision numbers
+
address@hidden
+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
address@hidden example
+
address@hidden tag (subcommand), introduction
address@hidden Tags, symbolic name
address@hidden Symbolic name (tag)
address@hidden Name, symbolic (tag)
address@hidden HEAD, as reserved tag name
address@hidden BASE, as reserved tag name
+You can use the @code{tag} command to give a symbolic name to a
+certain revision of a file. You can use the @samp{-v} flag to the
address@hidden command to see all tags that a file has, and
+which revision numbers they represent. Tag names must
+start with an uppercase or lowercase letter and can
+contain uppercase and lowercase letters, digits,
address@hidden, and @samp{_}. The two tag names @code{BASE}
+and @code{HEAD} are reserved for use by @sc{cvs}. It
+is expected that future names which are special to
address@hidden will be specially named, for example by
+starting with @samp{.}, rather than being named analogously to
address@hidden and @code{HEAD}, to avoid conflicts with
+actual tag names.
address@hidden Including a character such as % or = has also been
address@hidden suggested as the naming convention for future
address@hidden special tag names. Starting with . is nice because
address@hidden that is not a legal tag name as far as RCS is concerned.
address@hidden FIXME: CVS actually accepts quite a few characters
address@hidden in tag names, not just the ones documented above
address@hidden (see RCS_check_tag). RCS
address@hidden defines legitimate tag names by listing illegal
address@hidden characters rather than legal ones. CVS is said to lose its
address@hidden mind if you try to use "/" (try making such a tag sticky
address@hidden and using "cvs status" client/server--see remote
address@hidden protocol format for entries line for probable cause).
address@hidden TODO: The testsuite
address@hidden should test for whatever are documented above as
address@hidden officially-OK tag names, and CVS should at least reject
address@hidden characters that won't work, like "/".
+
+You'll want to choose some convention for naming tags,
+based on information such as the name of the program
+and the version number of the release. For example,
+one might take the name of the program, immediately
+followed by the version number with @samp{.} changed to
address@hidden, so that @sc{cvs} 1.9 would be tagged with the name
address@hidden If you choose a consistent convention,
+then you won't constantly be guessing whether a tag is
address@hidden or @code{cvs1_9} or what. You might
+even want to consider enforcing your convention in the
address@hidden file (@pxref{taginfo}).
address@hidden Might be nice to say more about using taginfo this
address@hidden way, like giving an example, or pointing out any particular
address@hidden issues which arise.
+
address@hidden Adding a tag
address@hidden Tags, example
+The following example shows how you can add a tag to a
+file. The commands must be issued inside your working
+directory. That is, you should issue the
+command in the directory where @file{backend.c}
+resides.
+
address@hidden
+$ cvs tag rel-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 /u/cvsroot/yoyodyne/tc/backend.c,v
+ Sticky Tag: (none)
+ Sticky Date: (none)
+ Sticky Options: (none)
+
+ Existing Tags:
+ rel-0-4 (revision: 1.4)
+
address@hidden example
+
+For a complete summary of the syntax of @code{cvs tag},
+including the various options, see @ref{Invoking CVS}.
+
+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.
+
address@hidden
+$ cvs tag rel-1-0 .
+cvs tag: Tagging .
+T Makefile
+T backend.c
+T driver.c
+T frontend.c
+T parser.c
address@hidden example
+
address@hidden
+(When you give @sc{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. @xref{Recursive behavior}.)
+
address@hidden Retrieving an old revision using tags
address@hidden Tags, retrieving old revisions
+The @code{checkout} command has a flag, @samp{-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 @samp{tc} at
+any time in the future:
+
address@hidden
+$ cvs checkout -r rel-1-0 tc
address@hidden example
+
address@hidden
+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 on any branch at any given date.
address@hidden options}. When specifying @samp{-r} or @samp{-D} to
+any of these commands, you will need beware of sticky
+tags; see @ref{Sticky tags}.
+
+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:
+
address@hidden
address@hidden
+ 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
address@hidden group
address@hidden example
+
+At some time in the past, the @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:
+
address@hidden
address@hidden
+ 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
address@hidden group
address@hidden example
+
address@hidden Tags (builtin)
address@hidden Tags--builtin
address@hidden Tags (builtin)
+
address@hidden
+The following builtin tags are available:
+
+HEAD BASE .head .base .trunk .root .origin .prev .next .commitid
+
address@hidden
+The builtin tags can be separated into categories:
+
address@hidden
address@hidden A. Static tags:
+Static tags always mark a specific revision, no matter
+how they are used.
+Static tags are: Symbolic tags, numeric revision numbers, commitids
+
address@hidden B. Dynamic tags:
+Dynamic tags specify a specific revision depending
+on the the revision they are based upon.
+Dynamic tags are: HEAD, BASE, '.head', '.root', '.prev',
+'.next', '.origin', '.base'
+
address@hidden C. Branch tags:
+Branch tags are ambiguous regarding static/dynamic
+behavior. Taken standalone, a branch tag points onto
+the most recent revision of a branch, impersonating
+static behavior. However, branch tags are dynamic tags
+as their focus changes when a branch is updated.
address@hidden itemize
+
address@hidden
+The different tags may be combined. For describing
+combined behavior, another definition is required:
+
address@hidden
address@hidden Absolute tags:
+Absolute tag means a tag that specifies either a revision or a trunk/branch.
+'.trunk', '.base', '1.2.3.4', '.commitid.1.2.3.4' and symbolic tags/branch
+tags are absolute tags.
+
address@hidden Relative tags:
+Relative tag means a tag that specifies a revision
+relative to a certain starting point.
+'.prev', '.next', '.root', '.origin' and '.head'
+are relative tags.
address@hidden itemize
+
address@hidden
+Combination of builtin tags:
+
+The builtin tags may be combined. Combined tags are resolved from
+left to right. When using tags with directories, combined tags need
+to start with an absolute tag. Relative tags can be appended. If a
+relative tag follows an absolute tag, the result will be absolute.
+
+When using tags with files only, the tag does not need to be absolute.
+If a relative tag is used, the absolute position is taken from:
+
address@hidden
address@hidden The sandbox revisions revision number
address@hidden The sandbox revision's tag
address@hidden The sandbox revision's dir-tag
address@hidden The mainline
address@hidden enumerate
+
address@hidden
+in this order, whatever is first available.
+
+If a combined tag with relative extensions is used for commands that change
+the local sandbox and set sticky tags, the resulting numeric revision is used
+for sticky tagging in case the last tag is either '.prev' or '.next'.
+
address@hidden
+Following the mainline (backwards):
+
+Starting from a specific rev. number X on the trunk or a branch, the line is
+followed backwards up to the first revision Z on the trunk. It doesn't matter
+if there are dead or missing revisions in between. If revision Z is dead,
+and its the 1.1 rev., stop here.
+If 1.1 is not dead, and 1.1 was created at the same time the first vendor
+branch rev. was created, jump to the vendor branch, and take the latest
+revision prior to the date of Y (Z is the predecessor of Y).
+Otherwise take 1.1.
+
address@hidden
+Focused branch:
+
+The 'focused branch' is used as a synonym for either the trunk or the branch,
+depending on the sticky tag of the addressed file or the workdir.
+
address@hidden
+What the tags mean:
+
+'.trunk': Serves as a synonym for the trunk-branch. Resolves to the
+most recent revision of the mainline, and allows to be used as a
+branch tag. Combination with a date ('xxx -r ".trunk:2005-03-08 18:00:00")
+is possible.
+
+'.origin': Will always resolve to the very first revision. If a file has
+been added on a branch, .origin will resolve to the first revision on
+that branch, otherwise it will follow the mainline.
+
+'.root': Will resolv to the first revision on a branch, the revision
+which is shared with its parent.
+
+'.base': The current sandbox revision. May only be used standalone.
+
+'.head': The most recent revision on the focused branch.
+
+'.prev': The previous revision on the focused branch. Follows the mainline.
+
+'.next': The next revision on the trunk/branch.
+
+'.commitid': Prefix for a following commitid, separated by a dot.
+
address@hidden
+Warning (when using '.origin' or '.root' with directories):
+
+While file1.root.head from the branch of a branch could yield
+the head of the first branch, file2.root.head could yield the
+head of the trunk. This must be taken into account since tags
+can be spread over a project in unpredictible manner, and there
+is no guarantee that a combined tag resolves to something usefull
+under all circumstances.
+
address@hidden
+Examples:
+
address@hidden
+cvs diff -r .base.prev test.txt
+cvs update -r .trunk.prev.prev
address@hidden example
+
address@hidden
+Backward compatibility:
+
+The '.head' and '.base' are a replacement for the well known
+HEAD and BASE tags. However there is a slight difference:
+
+When '.head' is used as a relative tag, it resolves to the
+head of trunk or branch depending on the current sandbox state.
+If '.head' shall be used as an absolute tag (i.e. to ignore a
+sticky dir tag), '.trunk' or any other absolute tag must be
+prepended.
+
address@hidden
+CVSNT compatibility:
+
+Instead of '.commitid', CVSNT uses '@@' as a prefix for a
+following commitid. If '@@<' is used, the previous revision is
+addressed. This is similar to '.commitid.xyzxyzxyzxyzxyzx.prev'.
+Usage of the CVSNT '@@' syntax is not supported in combined tags.
+
address@hidden
+Examples:
+
address@hidden
+cvs diff -r @@xyzxyzxyzxyzxyzx test.txt
+cvs diff -r @@<xyzxyzxyzxyzxyzx test.txt
+cvs diff -r .commitid.xyzxyzxyzxyzxyzx test.txt
+cvs diff -r .commitid.xyzxyzxyzxyzxyzx.prev test.txt
address@hidden example
+
address@hidden Tagging the working directory
address@hidden Specifying what to tag from the working directory
+
address@hidden tag (subcommand)
+The example in the previous section demonstrates one of
+the most common ways to choose which revisions to tag.
+Namely, running the @code{cvs tag} command without
+arguments causes @sc{cvs} to select the revisions which
+are checked out in the current working directory. For
+example, if the copy of @file{backend.c} in working
+directory was checked out from revision 1.4, then
address@hidden will tag revision 1.4. Note that the tag is
+applied immediately to revision 1.4 in the repository;
+tagging is not like modifying a file, or other
+operations in which one first modifies the working
+directory and then runs @code{cvs commit} to transfer
+that modification to the repository.
+
+One potentially surprising aspect of the fact that
address@hidden tag} operates on the repository is that you
+are tagging the checked-in revisions, which may differ
+from locally modified files in your working directory.
+If you want to avoid doing this by mistake, specify the
address@hidden option to @code{cvs tag}. If there are any
+locally modified files, @sc{cvs} will abort with an
+error before it tags any files:
+
address@hidden
+$ cvs tag -c rel-0-4
+cvs tag: backend.c is locally modified
+cvs [tag aborted]: correct the above errors first!
address@hidden example
+
address@hidden Tagging by date/tag
address@hidden Specifying what to tag by date or revision
address@hidden rtag (subcommand)
+
+The @code{cvs rtag} command tags the repository as of a
+certain date or time (or can be used to tag the latest
+revision). @code{rtag} works directly on the
+repository contents (it requires no prior checkout and
+does not look for a working directory).
+
+The following options specify which date or revision to
+tag. See @ref{Common options}, for a complete
+description of them.
+
address@hidden @code
address@hidden -D @var{date}
+Tag the most recent revision no later than @var{date}.
+
address@hidden -f
+Only useful with the @samp{-D} or @samp{-r}
+flags. If no matching revision is found, use the most
+recent revision (instead of ignoring the file).
+
address@hidden -r @var{tag}[:@var{date}]
+Tag the revision already tagged with @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{Common options}.
address@hidden table
+
+The @code{cvs tag} command also allows one to specify
+files by revision or date, using the same @samp{-r},
address@hidden, and @samp{-f} options. However, this
+feature is probably not what you want. The reason is
+that @code{cvs tag} chooses which files to tag based on
+the files that exist in the working directory, rather
+than the files which existed as of the given tag/date.
+Therefore, you are generally better off using @code{cvs
+rtag}. The exceptions might be cases like:
+
address@hidden
+cvs tag -r 1.4 stable backend.c
address@hidden example
+
address@hidden Modifying tags
address@hidden Deleting, moving, and renaming tags
+
address@hidden Also see:
address@hidden "How do I move or rename a magic branch tag?"
address@hidden in the FAQ (I think the issues it talks about still
address@hidden apply, but this could use some sanity.sh work).
+
+Normally one does not modify tags. They exist in order
+to record the history of the repository and so deleting
+them or changing their meaning would, generally, not be
+what you want.
+
+However, there might be cases in which one uses a tag
+temporarily or accidentally puts one in the wrong
+place. Therefore, one might delete, move, or rename a
+tag.
+
address@hidden
address@hidden: the commands in this section are
+dangerous; they permanently discard historical
+information and it can be difficult or impossible to
+recover from errors. If you are a @sc{cvs}
+administrator, you may consider restricting these
+commands with the @file{taginfo} file (@pxref{taginfo}).}
+
address@hidden Deleting tags
address@hidden Deleting branch tags
address@hidden Removing tags
address@hidden Removing branch tags
address@hidden Tags, deleting
address@hidden Branch tags, deleting
+To delete a tag, specify the @samp{-d} option to either
address@hidden tag} or @code{cvs rtag}. For example:
+
address@hidden
+cvs rtag -d rel-0-4 tc
address@hidden example
+
address@hidden
+deletes the non-branch tag @code{rel-0-4} from the module @code{tc}.
+In the event that branch tags are encountered within the repository
+with the given name, a warning message will be issued and the branch
+tag will not be deleted. If you are absolutely certain you know what
+you are doing, the @code{-B} option may be specified to allow deletion
+of branch tags. In that case, any non-branch tags encountered will
+trigger warnings and will not be deleted.
+
address@hidden
address@hidden: Moving branch tags is very dangerous! If you think
+you need the @code{-B} option, think again and ask your @sc{cvs}
+administrator about it (if that isn't you). There is almost certainly
+another way to accomplish what you want to accomplish.}
+
address@hidden Moving tags
address@hidden Moving branch tags
address@hidden Tags, moving
address@hidden Branch tags, moving
+When we say @dfn{move} a tag, we mean to make the same
+name point to different revisions. For example, the
address@hidden tag may currently point to revision 1.4
+of @file{backend.c} and perhaps we want to make it
+point to revision 1.6. To move a non-branch tag, specify the
address@hidden option to either @code{cvs tag} or @code{cvs
+rtag}. For example, the task just mentioned might be
+accomplished as:
+
address@hidden
+cvs tag -r 1.6 -F stable backend.c
address@hidden example
+
address@hidden
+If any branch tags are encountered in the repository
+with the given name, a warning is issued and the branch
+tag is not disturbed. If you are absolutely certain you
+wish to move the branch tag, the @code{-B} option may be specified.
+In that case, non-branch tags encountered with the given
+name are ignored with a warning message.
+
address@hidden
address@hidden: Moving branch tags is very dangerous! If you think you
+need the @code{-B} option, think again and ask your @sc{cvs}
+administrator about it (if that isn't you). There is almost certainly
+another way to accomplish what you want to accomplish.}
+
address@hidden Renaming tags
address@hidden Tags, renaming
+When we say @dfn{rename} a tag, we mean to make a
+different name point to the same revisions as the old
+tag. For example, one may have misspelled the tag name
+and want to correct it (hopefully before others are
+relying on the old spelling). To rename a tag, first
+create a new tag using the @samp{-r} option to
address@hidden rtag}, and then delete the old name. (Caution:
+this method will not work with branch tags.)
+This leaves the new tag on exactly the
+same files as the old tag. For example:
+
address@hidden
+cvs rtag -r old-name-0-4 rel-0-4 tc
+cvs rtag -d old-name-0-4 tc
address@hidden example
+
address@hidden Tagging add/remove
address@hidden Tagging and adding and removing files
+
+The subject of exactly how tagging interacts with
+adding and removing files is somewhat obscure; for the
+most part @sc{cvs} will keep track of whether files
+exist or not without too much fussing. By default,
+tags are applied to only files which have a revision
+corresponding to what is being tagged. Files which did
+not exist yet, or which were already removed, simply
+omit the tag, and @sc{cvs} knows to treat the absence
+of a tag as meaning that the file didn't exist as of
+that tag.
+
+However, this can lose a small amount of information.
+For example, suppose a file was added and then removed.
+Then, if the tag is missing for that file, there is no
+way to know whether the tag refers to the time before
+the file was added, or the time after it was removed.
+If you specify the @samp{-r} option to @code{cvs rtag},
+then @sc{cvs} tags the files which have been removed,
+and thereby avoids this problem. For example, one
+might specify @code{-r HEAD} to tag the head.
+
+On the subject of adding and removing files, the
address@hidden rtag} command has a @samp{-a} option which
+means to clear the tag from removed files that would
+not otherwise be tagged. For example, one might
+specify this option in conjunction with @samp{-F} when
+moving a tag. If one moved a tag without @samp{-a},
+then the tag in the removed files might still refer to
+the old revision, rather than reflecting the fact that
+the file had been removed. I don't think this is
+necessary if @samp{-r} is specified, as noted above.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Sticky tags
address@hidden Sticky tags
address@hidden Sticky tags
address@hidden Tags, sticky
+
address@hidden A somewhat related issue is per-directory sticky
address@hidden tags (see comment at CVS/Tag in node Working
address@hidden directory storage); we probably want to say
address@hidden something like "you can set a sticky tag for only
address@hidden some files, but you don't want to" or some such.
+
+Sometimes a working copy's revision has extra data
+associated with it, for example it might be on a branch
+(@pxref{Branching and merging}), or restricted to
+versions prior to a certain date by @samp{checkout -D}
+or @samp{update -D}. Because this data persists --
+that is, it applies to subsequent commands in the
+working copy -- we refer to it as @dfn{sticky}.
+
+Most of the time, stickiness is an obscure aspect of
address@hidden that you don't need to think about. However,
+even if you don't want to use the feature, you may need
+to know @emph{something} about sticky tags (for
+example, how to avoid them!).
+
+You can use the @code{status} command to see if any
+sticky tags or dates are set:
+
address@hidden
+$ cvs status 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 /u/cvsroot/yoyodyne/tc/driver.c,v
+ Sticky Tag: rel-1-0-patches (branch: 1.7.2)
+ Sticky Date: (none)
+ Sticky Options: (none)
+
address@hidden example
+
address@hidden Resetting sticky tags
address@hidden Sticky tags, resetting
address@hidden Deleting sticky tags
+The sticky tags will remain on your working files until
+you delete them with @samp{cvs update -A}. The
address@hidden option merges local changes into the version of the
+file from the head of the trunk, removing any sticky tags,
+dates, or options. See @ref{update} for more on the operation
+of @code{cvs update}.
+
address@hidden Sticky date
+The most common use of sticky tags is to identify which
+branch one is working on, as described in
address@hidden branches}. However, non-branch
+sticky tags have uses as well. 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}. 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}
+commands will
+not retrieve the latest revision until you reset the
+tag with @code{cvs update -A}. Likewise, use of the
address@hidden option to @code{update} or @code{checkout}
+sets a @dfn{sticky date}, which, similarly, causes that
+date to be used for future retrievals.
+
+People often want to retrieve an old version of
+a file without setting a sticky tag. This can
+be done with the @samp{-p} option to @code{checkout} or
address@hidden, which sends the contents of the file to
+standard output. For example:
address@hidden
+$ cvs update -p -r 1.1 file1 >file1
+===================================================================
+Checking out file1
+RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
+VERS: 1.1
+***************
+$
address@hidden example
+
+However, this isn't the easiest way, if you are asking
+how to undo a previous checkin (in this example, put
address@hidden back to the way it was as of revision
+1.1). In that case you are better off using the
address@hidden option to @code{update}; for further
+discussion see @ref{Merging two revisions}.
+
address@hidden
---------------------------------------------------------------------
address@hidden Branching and merging
address@hidden Branching and merging
address@hidden Branching
address@hidden Merging
address@hidden Copying changes
address@hidden Main trunk and branches
address@hidden Revision tree, making branches
address@hidden Branches, copying changes between
address@hidden Changes, copying between branches
address@hidden Modifications, copying between branches
+
address@hidden allows you to isolate changes onto a separate
+line of development, known as a @dfn{branch}. When you
+change files on a branch, those changes do not appear
+on the main trunk or other branches.
+
+Later you can move changes from one branch to another
+branch (or the main trunk) by @dfn{merging}. Merging
+involves first running @code{cvs update -j}, to merge
+the changes into the working directory.
+You can then commit that revision, and thus effectively
+copy the changes onto another branch.
+
address@hidden
+* Branches motivation:: What branches are good for
+* Creating a branch:: Creating a branch
+* Accessing branches:: Checking out and updating branches
+* Branches and revisions:: Branches are reflected in revision numbers
+* Magic branch numbers:: Magic branch numbers
+* Merging a branch:: Merging an entire branch
+* Merging more than once:: Merging from a branch several times
+* Merging two revisions:: Merging differences between two revisions
+* Merging adds and removals:: What if files are added or removed?
+* Merging and keywords:: Avoiding conflicts due to keyword substitution
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Branches motivation
address@hidden What branches are good for
address@hidden Branches motivation
address@hidden What branches are good for
address@hidden Motivation for branches
+
address@hidden FIXME: this node mentions one way to use branches,
address@hidden but it is by no means the only way. For example,
address@hidden the technique of committing a new feature on a branch,
address@hidden until it is ready for the main trunk. The whole
address@hidden thing is generally speaking more akin to the
address@hidden "Revision management" node although it isn't clear to
address@hidden me whether policy matters should be centralized or
address@hidden distributed throughout the relevant sections.
+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 (@pxref{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
+bug fix release based on the newest sources.
+
+The thing to do in a situation like this is to create a @dfn{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 elect to either incorporate them on
+the main trunk, or leave them on the branch.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Creating a branch
address@hidden Creating a branch
address@hidden Creating a branch
address@hidden Branch, creating a
address@hidden tag (subcommand), creating a branch using
address@hidden rtag (subcommand), creating a branch using
+
+You can create a branch with @code{tag -b}; for
+example, assuming you're in a working copy:
+
address@hidden
+$ cvs tag -b rel-1-0-patches
address@hidden example
+
address@hidden FIXME: we should be more explicit about the value of
address@hidden having a tag on the branchpoint. For example
address@hidden "cvs tag rel-1-0-patches-branchpoint" before
address@hidden the "cvs tag -b". This points out that
address@hidden rel-1-0-patches is a pretty awkward name for
address@hidden this example (more so than for the rtag example
address@hidden below).
+
+This splits off a branch based on the current revisions
+in the working copy, assigning that branch the name
address@hidden
+
+It is important to understand that branches get created
+in the repository, not in the working copy. Creating a
+branch based on current revisions, as the above example
+does, will @emph{not} automatically switch the working
+copy to be on the new branch. For information on how
+to do that, see @ref{Accessing branches}.
+
+You can also create a branch without reference to any
+working copy, by using @code{rtag}:
+
address@hidden
+$ cvs rtag -b -r rel-1-0 rel-1-0-patches tc
address@hidden example
+
address@hidden rel-1-0} says that this branch should be
+rooted at the revision that
+corresponds to the tag @samp{rel-1-0}. It need not
+be the most recent revision -- it's often useful to
+split a branch off an old revision (for example, when
+fixing a bug in a past release otherwise known to be
+stable).
+
+As with @samp{tag}, the @samp{-b} flag tells
address@hidden to create a branch (rather than just a
+symbolic revision name). Note that the numeric
+revision number that matches @samp{rel-1-0} will
+probably be different from file to file.
+
+So, the full effect of the command is to create a new
+branch -- named @samp{rel-1-0-patches} -- in module
address@hidden, rooted in the revision tree at the point tagged
+by @samp{rel-1-0}.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Accessing branches
address@hidden Accessing branches
address@hidden Check out a branch
address@hidden Retrieve a branch
address@hidden Access a branch
address@hidden Identifying a branch
address@hidden Branch, check out
address@hidden Branch, retrieving
address@hidden Branch, accessing
address@hidden Branch, identifying
+
+You can retrieve a branch in one of two ways: by
+checking it out fresh from the repository, or by
+switching an existing working copy over to the branch.
+
+To check out a branch from the repository, invoke
address@hidden with the @samp{-r} flag, followed by
+the tag name of the branch (@pxref{Creating a branch}):
+
address@hidden
+$ cvs checkout -r rel-1-0-patches tc
address@hidden example
+
+Or, if you already have a working copy, you can switch
+it to a given branch with @samp{update -r}:
+
address@hidden
+$ cvs update -r rel-1-0-patches tc
address@hidden example
+
address@hidden
+or equivalently:
+
address@hidden
+$ cd tc
+$ cvs update -r rel-1-0-patches
address@hidden example
+
+It does not matter if the working copy was originally
+on the main trunk or on some other branch -- the above
+command will switch it to the named branch. And
+similarly to a regular @samp{update} command,
address@hidden -r} merges any changes you have made,
+notifying you of conflicts where they occur.
+
+Once you have a working copy tied to a particular
+branch, it remains there until you tell it otherwise.
+This means that changes checked in from the working
+copy will add new revisions on that branch, while
+leaving the main trunk and other branches unaffected.
+
address@hidden Branches, sticky
+To find out what branch a working copy is on, you can
+use the @samp{status} command. In its output, look for
+the field named @samp{Sticky tag} (@pxref{Sticky tags})
+-- that's @sc{cvs}'s way of telling you the branch, if
+any, of the current working files:
+
address@hidden
+$ 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 /u/cvsroot/yoyodyne/tc/driver.c,v
+ Sticky Tag: rel-1-0-patches (branch: 1.7.2)
+ Sticky Date: (none)
+ Sticky Options: (none)
+
+ Existing Tags:
+ rel-1-0-patches (branch: 1.7.2)
+ rel-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 /u/cvsroot/yoyodyne/tc/backend.c,v
+ Sticky Tag: rel-1-0-patches (branch: 1.4.2)
+ Sticky Date: (none)
+ Sticky Options: (none)
+
+ Existing Tags:
+ rel-1-0-patches (branch: 1.4.2)
+ rel-1-0 (revision: 1.4)
+ rel-0-4 (revision: 1.4)
+
address@hidden example
+
+Don't be confused by the fact that the branch numbers
+for each file are different (@samp{1.7.2} and
address@hidden respectively). The branch tag is the
+same, @samp{rel-1-0-patches}, and the files are
+indeed on the same branch. The numbers simply reflect
+the point in each file's revision history at which the
+branch was made. In the above example, one can deduce
+that @samp{driver.c} had been through more changes than
address@hidden before this branch was created.
+
+See @ref{Branches and revisions} for details about how
+branch numbers are constructed.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Branches and revisions
address@hidden Branches and revisions
address@hidden Branch number
address@hidden Number, branch
address@hidden Revision numbers (branches)
+
+Ordinarily, a file's revision history is a linear
+series of increments (@pxref{Revision numbers}):
+
address@hidden
+ +-----+ +-----+ +-----+ +-----+ +-----+
+ ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
+ +-----+ +-----+ +-----+ +-----+ +-----+
address@hidden example
+
+However, @sc{cvs} is not limited to linear development. The
address@hidden tree} can be split into @dfn{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 @dfn{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.
+
address@hidden 3500
+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.
+
address@hidden
address@hidden This example used to have a 1.2.2.4 revision, which
address@hidden might help clarify that development can continue on
address@hidden 1.2.2. Might be worth reinstating if it can be done
address@hidden without overfull hboxes.
address@hidden
+ +-------------+
+ 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.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 !
+ +---------+ +---------+ +---------+
+
address@hidden group
address@hidden example
+
address@hidden -- However, at least for me the figure is not enough. I
suggest more
address@hidden -- text to accompany it. "A picture is worth a thousand
words", so you
address@hidden -- have to make sure the reader notices the couple of hundred
words
address@hidden -- *you* had in mind more than the others!
+
address@hidden -- Why an even number of segments? This section implies that
this is
address@hidden -- how the main trunk is distinguished from branch roots, but
you never
address@hidden -- explicitly say that this is the purpose of the [by itself
rather
address@hidden -- surprising] restriction to an even number of segments.
+
+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
address@hidden 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 @sc{cvs}
+(@pxref{Magic branch numbers}). The branch 1.1.1 has a
+special meaning. @xref{Tracking sources}.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Magic branch numbers
address@hidden Magic branch numbers
+
address@hidden Want xref to here from "log"?
+
+This section describes a @sc{cvs} feature called
address@hidden branches}. For most purposes, you need not
+worry about magic branches; @sc{cvs} handles them for
+you. However, they are visible to you in certain
+circumstances, so it may be useful to have some idea of
+how it works.
+
+Externally, branch numbers consist of an odd number of
+dot-separated decimal integers. @xref{Revision
+numbers}. That is not the whole truth, however. For
+efficiency reasons @sc{cvs} sometimes inserts an extra 0
+in the second rightmost position (1.2.4 becomes
+1.2.0.4, 8.9.10.11.12 becomes 8.9.10.11.0.12 and so
+on).
+
address@hidden does a pretty good job at hiding these so
+called magic branches, but in a few places the hiding
+is incomplete:
+
address@hidden @bullet
address@hidden
address@hidden This is in ignore as I'm taking their word for it,
address@hidden that this was fixed
address@hidden a long time ago. But before deleting this
address@hidden entirely, I'd rather verify it (and add a test
address@hidden case to the testsuite).
address@hidden
+The magic branch can appear in the output from
address@hidden status} in vanilla @sc{cvs} 1.3. This is
+fixed in @sc{cvs} 1.3-s2.
+
address@hidden ignore
address@hidden
+The magic branch number appears in the output from
address@hidden log}.
address@hidden What output should appear instead?
+
address@hidden
+You cannot specify a symbolic branch name to @code{cvs
+admin}.
+
address@hidden itemize
+
address@hidden Can CVS do this automatically the first time
address@hidden you check something in to that branch? Should
address@hidden it?
+You can use the @code{admin} command to reassign a
+symbolic name to a branch the way @sc{rcs} expects it
+to be. If @code{R4patches} is assigned to the branch
+1.4.2 (magic branch number 1.4.0.2) in file
address@hidden you can do this:
+
address@hidden
+$ cvs admin -NR4patches:1.4.2 numbers.c
address@hidden example
+
+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).
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Merging a branch
address@hidden Merging an entire branch
address@hidden Merging a branch
address@hidden -j (merging branches)
+
+You can merge changes made on a branch into your working copy by giving
+the @samp{-j @var{branchname}} flag to the @code{update} subcommand. With one
address@hidden @var{branchname}} option it merges the changes made between the
+greatest common ancestor (GCA) of the branch and the destination revision (in
+the simple case below the GCA is the point where the branch forked) and the
+newest revision on that branch into your working copy.
+
address@hidden Join
+The @samp{-j} stands for ``join''.
+
address@hidden Branch merge example
address@hidden Example, branch merge
address@hidden Merge, branch example
+Consider this revision tree:
+
address@hidden
++-----+ +-----+ +-----+ +-----+
+! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- The main trunk
++-----+ +-----+ +-----+ +-----+
+ !
+ !
+ ! +---------+ +---------+
+Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+ +---------+ +---------+
address@hidden example
+
address@hidden
+The branch 1.2.2 has been given the tag (symbolic name) @samp{R1fix}. The
+following example assumes that the module @samp{mod} contains only one
+file, @file{m.c}.
+
address@hidden
+$ cvs checkout mod # @r{Retrieve the latest revision, 1.4}
+
+$ cvs update -j R1fix m.c # @r{Merge all changes made on the branch,}
+ # @r{i.e. the changes between revision 1.2}
+ # @r{and 1.2.2.2, into your working copy}
+ # @r{of the file.}
+
+$ cvs commit -m "Included R1fix" # @r{Create revision 1.5.}
address@hidden example
+
+A conflict can result from a merge operation. If that
+happens, you should resolve it before committing the
+new revision. @xref{Conflicts example}.
+
+If your source files contain keywords (@pxref{Keyword substitution}),
+you might be getting more conflicts than strictly necessary. See
address@hidden and keywords}, for information on how to avoid this.
+
+The @code{checkout} command also supports the @samp{-j @var{branchname}} flag.
The
+same effect as above could be achieved with this:
+
address@hidden
+$ cvs checkout -j R1fix mod
+$ cvs commit -m "Included R1fix"
address@hidden example
+
+It should be noted that @code{update -j @var{tagname}} will also work but may
+not produce the desired result. @xref{Merging adds and removals}, for more.
+
address@hidden Merging more than once
address@hidden Merging from a branch several times
+
+Continuing our example, the revision tree now looks
+like this:
+
address@hidden
++-----+ +-----+ +-----+ +-----+ +-----+
+! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
++-----+ +-----+ +-----+ +-----+ +-----+
+ ! *
+ ! *
+ ! +---------+ +---------+
+Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+ +---------+ +---------+
address@hidden example
+
address@hidden
+where the starred line represents the merge from the
address@hidden branch to the main trunk, as just
+discussed.
+
+Now suppose that development continues on the
address@hidden branch:
+
address@hidden
++-----+ +-----+ +-----+ +-----+ +-----+
+! 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 !
+ +---------+ +---------+ +---------+
address@hidden example
+
address@hidden
+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} command again, @sc{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
address@hidden options, and @sc{cvs} merges the changes from
+the first revision to the second revision. For
+example, in this case the simplest way would be
+
address@hidden
+cvs update -j 1.2.2.2 -j R1fix m.c # @r{Merge changes from 1.2.2.2 to the}
+ # @r{head of the R1fix branch}
address@hidden example
+
+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:
+
address@hidden
+cvs update -j R1fix:yesterday -j R1fix m.c
address@hidden example
+
+Better yet, tag the R1fix branch after every merge into
+the trunk, and then use that tag for subsequent merges:
+
address@hidden
+cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
address@hidden example
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Merging two revisions
address@hidden Merging differences between any two revisions
address@hidden Merging two revisions
address@hidden Revisions, merging differences between
address@hidden Differences, merging
+
+With two @samp{-j @var{revision}} flags, the @code{update}
+(and @code{checkout}) command can merge the differences
+between any two revisions into your working file.
+
address@hidden Undoing a change
address@hidden Removing a change
address@hidden
+$ cvs update -j 1.5 -j 1.3 backend.c
address@hidden example
+
address@hidden
+will undo 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.
+You almost always use symbolic
+tags rather than revision numbers when operating on
+multiple files.
+
address@hidden Restoring old version of removed file
address@hidden Resurrecting old version of dead file
+Specifying two @samp{-j} options can also undo file
+removals or additions. For example, suppose you have
+a file
+named @file{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:
+
address@hidden
+$ cvs update -j 1.2 -j 1.1 file1
+U file1
+$ 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
+$
address@hidden example
+
address@hidden Merging adds and removals
address@hidden Merging can add or remove files
+
+If the changes which you are merging involve removing
+or adding some files, @code{update -j} will reflect
+such additions or removals.
+
address@hidden FIXME: This example needs a lot more explanation.
address@hidden We also need other examples for some of the other
address@hidden cases (not all--there are too many--as long as we present a
address@hidden coherent general principle).
+For example:
address@hidden
+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
address@hidden example
+
+After these commands are executed and a @samp{cvs commit} is done,
+file @file{a} will be removed and file @file{d} added in the main branch.
address@hidden (which was determined by trying it)
+
+Note that using a single static tag (@samp{-j @var{tagname}})
+rather than a dynamic tag (@samp{-j @var{branchname}}) to merge
+changes from a branch will usually not remove files which were removed on the
+branch since @sc{cvs} does not automatically add static tags to dead revisions.
+The exception to this rule occurs when
+a static tag has been attached to a dead revision manually. Use the branch tag
+to merge all changes from the branch or use two static tags as merge endpoints
+to be sure that all intended changes are propagated in the merge.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Merging and keywords
address@hidden Merging and keywords
address@hidden Merging, and keyword substitution
address@hidden Keyword substitution, and merging
address@hidden -j (merging branches), and keyword substitution
address@hidden -kk, to avoid conflicts during a merge
+
+If you merge files containing keywords (@pxref{Keyword
+substitution}), you will normally get numerous
+conflicts during the merge, because the keywords are
+expanded differently in the revisions which you are
+merging.
+
+Therefore, you will often want to specify the
address@hidden (@pxref{Substitution modes}) switch to the
+merge command line. By substituting just the name of
+the keyword, not the expanded value of that keyword,
+this option ensures that the revisions which you are
+merging will be the same as each other, and avoid
+spurious conflicts.
+
+For example, suppose you have a file like this:
+
address@hidden
+ +---------+
+ _! 1.1.2.1 ! <- br1
+ / +---------+
+ /
+ /
++-----+ +-----+
+! 1.1 !----! 1.2 !
++-----+ +-----+
address@hidden example
+
address@hidden
+and your working directory is currently on the trunk
+(revision 1.2). Then you might get the following
+results from a merge:
+
address@hidden
+$ cat file1
+key address@hidden: 1.2 $
+. . .
+$ cvs update -j br1
+U file1
+RCS file: /cvsroot/first-dir/file1,v
+retrieving revision 1.1
+retrieving revision 1.1.2.1
+Merging differences between 1.1 and 1.1.2.1 into file1
+rcsmerge: warning: conflicts during merge
+$ cat file1
address@hidden<<<<<<< file1
+key address@hidden: 1.2 $
address@hidden
+key address@hidden: 1.1.2.1 $
address@hidden>>>>>>> 1.1.2.1
+. . .
address@hidden example
+
+What happened was that the merge tried to merge the
+differences between 1.1 and 1.1.2.1 into your working
+directory. So, since the keyword changed from
address@hidden: 1.1} to @code{Revision: 1.1.2.1},
address@hidden tried to merge that change into your working
+directory, which conflicted with the fact that your
+working directory had contained @code{Revision: 1.2}.
+
+Here is what happens if you had used @samp{-kk}:
+
address@hidden
+$ cat file1
+key address@hidden: 1.2 $
+. . .
+$ cvs update -kk -j br1
+U file1
+RCS file: /cvsroot/first-dir/file1,v
+retrieving revision 1.1
+retrieving revision 1.1.2.1
+Merging differences between 1.1 and 1.1.2.1 into file1
+$ cat file1
+key address@hidden
+. . .
address@hidden example
+
+What is going on here is that revision 1.1 and 1.1.2.1
+both expand as plain @code{Revision}, and therefore
+merging the changes between them into the working
+directory need not change anything. Therefore, there
+is no conflict.
+
address@hidden: In versions of @sc{cvs} prior to 1.12.2, there was a
+major problem with using @samp{-kk} on merges. Namely, @samp{-kk}
+overrode any default keyword expansion mode set in the archive file in
+the repository. This could, unfortunately for some users, cause data
+corruption in binary files (with a default keyword expansion mode set
+to @samp{-kb}). Therefore, when a repository contained binary files,
+conflicts had to be dealt with manually rather than using @samp{-kk} in
+a merge command.}
+
+In @sc{cvs} version 1.12.2 and later, the keyword expansion mode
+provided on the command line to any @sc{cvs} command no longer
+overrides the @samp{-kb} keyword expansion mode setting for binary
+files, though it will still override other default keyword expansion
+modes. You can now safely merge using @samp{-kk} to avoid spurious conflicts
+on lines containing RCS keywords, even when your repository contains
+binary files.
+
address@hidden
---------------------------------------------------------------------
address@hidden Recursive behavior
address@hidden Recursive behavior
address@hidden Recursive (directory descending)
address@hidden Directory, descending
address@hidden Descending directories
address@hidden Subdirectories
+
+Almost all of the subcommands of @sc{cvs} work
+recursively when you specify a directory as an
+argument. For instance, consider this directory
+structure:
+
address@hidden
+ @code{$HOME}
+ |
+ address@hidden
+ | |
+ address@hidden
+ | (internal @sc{cvs} files)
+ address@hidden
+ address@hidden
+ address@hidden
+ address@hidden
+ address@hidden
+ address@hidden
+ | |
+ | address@hidden
+ | | (internal @sc{cvs} files)
+ | address@hidden
+ |
+ address@hidden
+ |
+ address@hidden
+ | (internal @sc{cvs} files)
+ address@hidden
+ address@hidden
address@hidden example
+
address@hidden
+If @file{tc} is the current working directory, the
+following is true:
+
address@hidden @bullet
address@hidden
address@hidden update testing} is equivalent to
+
address@hidden
+cvs update testing/testpgm.t testing/test2.t
address@hidden example
+
address@hidden
address@hidden update testing man} updates all files in the
+subdirectories
+
address@hidden
address@hidden update .} or just @samp{cvs update} updates
+all files in the @code{tc} directory
address@hidden itemize
+
+If no arguments are given to @code{update} it will
+update all files in the current working directory and
+all its subdirectories. In other words, @file{.} is a
+default argument to @code{update}. This is also true
+for most of the @sc{cvs} subcommands, not only the
address@hidden command.
+
+The recursive behavior of the @sc{cvs} subcommands can be
+turned off with the @samp{-l} option.
+Conversely, the @samp{-R} option can be used to force recursion if
address@hidden is specified in @file{~/.cvsrc} (@pxref{~/.cvsrc}).
+
address@hidden
+$ cvs update -l # @r{Don't update files in subdirectories}
address@hidden example
+
address@hidden
---------------------------------------------------------------------
address@hidden Adding and removing
address@hidden Adding, removing, and renaming files and directories
+
+In the course of a project, one will often add new
+files. Likewise with removing or renaming, or with
+directories. The general concept to keep in mind in
+all these cases is that instead of making an
+irreversible change you want @sc{cvs} to record the
+fact that a change has taken place, just as with
+modifying an existing file. The exact mechanisms to do
+this in @sc{cvs} vary depending on the situation.
+
address@hidden
+* Adding files:: Adding files
+* Removing files:: Removing files
+* Removing directories:: Removing directories
+* Moving files:: Moving and renaming files
+* Moving directories:: Moving and renaming directories
address@hidden menu
+
address@hidden Adding files
address@hidden Adding files to a directory
address@hidden Adding files
+
+To add a new file to a directory, follow these steps.
+
address@hidden @bullet
address@hidden
+You must have a working copy of the directory.
address@hidden the source}.
+
address@hidden
+Create the new file inside your working copy of the directory.
+
address@hidden
+Use @samp{cvs add @var{filename}} to tell @sc{cvs} that you
+want to version control the file. If the file contains
+binary data, specify @samp{-kb} (@pxref{Binary files}).
+
address@hidden
+Use @samp{cvs commit @var{filename}} to actually check
+in the file into the repository. Other developers
+cannot see the file until you perform this step.
address@hidden itemize
+
+You can also use the @code{add} command to add a new
+directory.
address@hidden FIXCVS and/or FIXME: Adding a directory doesn't
address@hidden require the commit step. This probably can be
address@hidden considered a CVS bug, but it is possible we should
address@hidden warn people since this behavior probably won't be
address@hidden changing right away.
+
+Unlike most other commands, the @code{add} command is
+not recursive. You have to expcicitly name files and
+directories that you wish to add to the repository.
+However, each directory will need to be added
+separately before you will be able to add new files
+to those directories.
+
address@hidden
+$ mkdir -p foo/bar
+$ cp ~/myfile foo/bar/myfile
+$ cvs add foo foo/bar
+$ cvs add foo/bar/myfile
address@hidden example
+
address@hidden add (subcommand)
address@hidden Command {cvs add} address@hidden kflag] address@hidden message]
files @dots{}
+
+Schedule @var{files} to be added to the repository.
+The files or directories specified with @code{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 @code{import} command instead. @xref{import}.
+
+The added files are not placed in the source repository
+until you use @code{commit} to make the change
+permanent. Doing an @code{add} on a file that was
+removed with the @code{remove} command will undo the
+effect of the @code{remove}, unless a @code{commit}
+command intervened. @xref{Removing files}, for an
+example.
+
+The @samp{-k} option specifies the default way that
+this file will be checked out; for more information see
address@hidden modes}.
+
address@hidden As noted in BUGS, -m is broken client/server (Nov
address@hidden 96). Also see testsuite log2-* tests.
+The @samp{-m} option specifies a description for the
+file. This description appears in the history log (if
+it is enabled, @pxref{history file}). It will also be
+saved in the version history inside the repository when
+the file is committed. The @code{log} command displays
+this description. The description can be changed using
address@hidden -t}. @xref{admin}. If you omit the
address@hidden @var{description}} flag, an empty string will
+be used. You will not be prompted for a description.
address@hidden deffn
+
+For example, the following commands add the file
address@hidden to the repository:
+
address@hidden This example used to specify
address@hidden -m "Optimizer and code generation passes."
address@hidden to the cvs add command, but that doesn't work
address@hidden client/server (see log2 in sanity.sh). Should fix CVS,
address@hidden but also seems strange to document things which
address@hidden don't work...
address@hidden
+$ cvs add backend.c
+$ cvs commit -m "Early version. Not yet compilable." backend.c
address@hidden example
+
+When you add a file it is added only on the branch
+which you are working on (@pxref{Branching and merging}). You can
+later merge the additions to another branch if you want
+(@pxref{Merging adds and removals}).
address@hidden Should we mention that earlier versions of CVS
address@hidden lacked this feature (1.3) or implemented it in a buggy
address@hidden way (well, 1.8 had many bugs in cvs update -j)?
address@hidden Should we mention the bug/limitation regarding a
address@hidden file being a regular file on one branch and a directory
address@hidden on another?
address@hidden FIXME: This needs an example, or several, here or
address@hidden elsewhere, for it to make much sense.
address@hidden Somewhere we need to discuss the aspects of death
address@hidden support which don't involve branching, I guess.
address@hidden Like the ability to re-create a release from a tag.
+
address@hidden
---------------------------------------------------------------------
address@hidden Removing files
address@hidden Removing files
address@hidden Removing files
address@hidden Deleting files
+
address@hidden FIXME: this node wants to be split into several
address@hidden smaller nodes. Could make these children of
address@hidden "Adding and removing", probably (death support could
address@hidden be its own section, for example, as could the
address@hidden various bits about undoing mistakes in adding and
address@hidden removing).
+Directories change. New files are added, and old files
+disappear. Still, you want to be able to retrieve an
+exact copy of old releases.
+
+Here is what you can do to remove a file,
+but remain able to retrieve old revisions:
+
address@hidden @bullet
address@hidden FIXME: should probably be saying something about
address@hidden having a working directory in the first place.
address@hidden
+Make sure that you have not made any uncommitted
+modifications to the file. @xref{Viewing differences},
+for one way to do that. You can also use the
address@hidden or @code{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.
+
address@hidden
+Remove the file from your working copy of the directory.
+You can for instance use @code{rm}.
+
address@hidden
+Use @samp{cvs remove @var{filename}} to tell @sc{cvs} that
+you really want to delete the file.
+
address@hidden
+Use @samp{cvs commit @var{filename}} to actually
+perform the removal of the file from the repository.
address@hidden itemize
+
address@hidden FIXME: Somehow this should be linked in with a more
address@hidden general discussion of death support. I don't know
address@hidden whether we want to use the term "death support" or
address@hidden not (we can perhaps get by without it), but we do
address@hidden need to discuss the "dead" state in "cvs log" and
address@hidden related subjects. The current discussion is
address@hidden scattered around, and not xref'd to each other.
address@hidden FIXME: I think this paragraph wants to be moved
address@hidden later down, at least after the first example.
+When you commit the removal of the file, @sc{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. @sc{cvs} will correctly create or not create
+the file, based on the @samp{-r} and @samp{-D} options
+specified to @code{checkout} or @code{update}.
+
address@hidden FIXME: This style seems to clash with how we
address@hidden document things in general.
address@hidden Remove (subcommand)
address@hidden Command {cvs remove} [options] files @dots{}
+
+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. For a full list of
+options, see @ref{Invoking CVS}.
address@hidden deffn
+
+Here is an example of removing several files:
+
address@hidden
+$ 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 .
address@hidden example
+
+As a convenience you can remove the file and @code{cvs
+remove} it in one step, by specifying the @samp{-f}
+option. For example, the above example could also be
+done like this:
+
address@hidden
+$ cd test
+$ cvs remove -f *.c
+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 .
address@hidden example
+
+If you execute @code{remove} for a file, and then
+change your mind before you commit, you can undo the
address@hidden with an @code{add} command.
address@hidden
address@hidden is this worth saying or not? Somehow it seems
address@hidden confusing to me.
+Of course,
+since you have removed your copy of file in the working
+directory, @sc{cvs} does not necessarily bring back the
+contents of the file from right before you executed
address@hidden; instead it gets the file from the
+repository again.
address@hidden ignore
+
address@hidden FIXME: what if you change your mind after you commit
address@hidden it? (answer is also "cvs add" but we don't say that...).
address@hidden We need some index entries for thinks like "undoing
address@hidden removal" too.
+
address@hidden
+$ 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
address@hidden example
+
+If you realize your mistake before you run the
address@hidden command you can use @code{update} to
+resurrect the file:
+
address@hidden
+$ rm oj.c
+$ cvs update oj.c
+cvs update: warning: oj.c was lost
+U oj.c
address@hidden example
+
+When you remove a file it is removed only on the branch
+which you are working on (@pxref{Branching and merging}). You can
+later merge the removals to another branch if you want
+(@pxref{Merging adds and removals}).
+
address@hidden Removing directories
address@hidden Removing directories
address@hidden Removing directories
address@hidden Directories, removing
+
+In concept, removing directories is somewhat similar to
+removing files---you want the directory to not exist in
+your current working directories, but you also want to
+be able to retrieve old releases in which the directory
+existed.
+
+The way that you remove a directory is to remove all
+the files in it. You don't remove the directory
+itself; there is no way to do that.
+Instead you specify the @samp{-P} option to
address@hidden update} or @code{cvs checkout},
+which will cause @sc{cvs} to remove empty
+directories from working directories.
+(Note that @code{cvs export} always removes empty directories.)
+Probably the
+best way to do this is to always specify @samp{-P}; if
+you want an empty directory then put a dummy file (for
+example @file{.keepme}) in it to prevent @samp{-P} from
+removing it.
+
address@hidden I'd try to give a rationale for this, but I'm not
address@hidden sure there is a particularly convincing one. What
address@hidden we would _like_ is for CVS to do a better job of version
address@hidden controlling whether directories exist, to eliminate the
address@hidden need for -P and so that a file can be a directory in
address@hidden one revision and a regular file in another.
+Note that @samp{-P} is implied by the @samp{-r} or @samp{-D}
+options of @code{checkout}. This way,
address@hidden will be able to correctly create the directory
+or not depending on whether the particular version you
+are checking out contains any files in that directory.
+
address@hidden
---------------------------------------------------------------------
address@hidden Moving files
address@hidden Moving and renaming files
address@hidden Moving files
address@hidden Renaming files
address@hidden Files, moving
+
+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. @xref{Moving directories}.).
+
+The examples below assume that the file @var{old} is renamed to
address@hidden
+
address@hidden
+* Outside:: The normal way to Rename
+* Inside:: A tricky, alternative way
+* Rename by copying:: Another tricky, alternative way
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Outside
address@hidden The Normal way to Rename
+
address@hidden More rename issues. Not sure whether these are
address@hidden worth documenting; I'm putting them here because
address@hidden it seems to be as good a place as any to try to
address@hidden set down the issues.
address@hidden * "cvs annotate" will annotate either the new
address@hidden file or the old file; it cannot annotate _each
address@hidden line_ based on whether it was last changed in the
address@hidden new or old file. Unlike "cvs log", where the
address@hidden consequences of having to select either the new
address@hidden or old name seem fairly benign, this may be a
address@hidden real advantage to having CVS know about renames
address@hidden other than as a deletion and an addition.
+
+The normal way to move a file is to copy @var{old} to
address@hidden, and then issue the normal @sc{cvs} commands
+to remove @var{old} from the repository, and add
address@hidden to it.
address@hidden The following sentence is not true: one must cd into
address@hidden the directory to run "cvs add".
address@hidden (Both @var{old} and @var{new} could
address@hidden contain relative paths, for example @file{foo/bar.c}).
+
address@hidden
+$ mv @var{old} @var{new}
+$ cvs remove @var{old}
+$ cvs add @var{new}
+$ cvs commit -m "Renamed @var{old} to @var{new}" @var{old} @var{new}
address@hidden example
+
+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,
address@hidden log @var{old}} will give the log up until the
+time of the rename.
+
+When @var{new} is committed its revision numbers will
+start again, usually at 1.1, so if that bothers you,
+use the @samp{-r @var{tag}} option to commit. For more
+information see @ref{Assigning revisions}.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Inside
address@hidden 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!
+
address@hidden
+$ cd $CVSROOT/@var{dir}
+$ mv @var{old},v @var{new},v
address@hidden example
+
address@hidden
+Advantages:
+
address@hidden @bullet
address@hidden
+The log of changes is maintained intact.
+
address@hidden
+The revision numbers are not affected.
address@hidden itemize
+
address@hidden
+Disadvantages:
+
address@hidden @bullet
address@hidden
+Old releases cannot easily be fetched from the
+repository. (The file will show up as @var{new} even
+in revisions from the time before it was renamed).
+
address@hidden
+There is no log information of when the file was renamed.
+
address@hidden
+Nasty things might happen if someone accesses the history file
+while you are moving it. Make sure no one else runs any of the @sc{cvs}
+commands while you move it.
address@hidden itemize
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Rename by copying
address@hidden Copying the history file
+
+This way also involves direct modifications to the
+repository. It is safe, but not without drawbacks.
+
address@hidden
+# @r{Copy the @sc{rcs} file inside the repository}
+$ cd $CVSROOT/@var{dir}
+$ cp @var{old},v @var{new},v
+# @r{Remove the old file}
+$ cd ~/@var{dir}
+$ rm @var{old}
+$ cvs remove @var{old}
+$ cvs commit @var{old}
+# @r{Remove all tags from @var{new}}
+$ cvs update @var{new}
+$ cvs log @var{new} # @r{Remember the non-branch tag names}
+$ cvs tag -d @var{tag1} @var{new}
+$ cvs tag -d @var{tag2} @var{new}
address@hidden
address@hidden example
+
+By removing the tags you will be able to check out old
+revisions.
+
address@hidden
+Advantages:
+
address@hidden @bullet
address@hidden
address@hidden FIXME: Is this true about -D now that we have death
address@hidden support? See 5B.3 in the FAQ.
+Checking out old revisions works correctly, as long as
+you use @samp{-r @var{tag}} and not @samp{-D @var{date}}
+to retrieve the revisions.
+
address@hidden
+The log of changes is maintained intact.
+
address@hidden
+The revision numbers are not affected.
address@hidden itemize
+
address@hidden
+Disadvantages:
+
address@hidden @bullet
address@hidden
+You cannot easily see the history of the file across the rename.
+
address@hidden
address@hidden Is this true? I don't see how the revision numbers
address@hidden _could_ start over, when new,v is just old,v with
address@hidden the tags deleted.
address@hidden If there is some need to reinstate this text,
address@hidden it is "usually 1.1", not "1.0" and it needs an
address@hidden xref to Assigning revisions
address@hidden
+Unless you use the @samp{-r @var{tag}} (@pxref{commit
+options}) flag when @var{new} is committed its revision
+numbers will start at 1.0 again.
address@hidden ignore
address@hidden itemize
+
address@hidden
---------------------------------------------------------------------
address@hidden Moving directories
address@hidden Moving and renaming directories
address@hidden Moving directories
address@hidden Renaming directories
address@hidden Directories, moving
+
+The normal way to rename or move a directory is to
+rename or move each file within it as described in
address@hidden Then check out with the @samp{-P}
+option, as described in @ref{Removing directories}.
+
+If you really want to hack the repository to rename or
+delete a directory in the repository, you can do it
+like this:
+
address@hidden
address@hidden
+Inform everyone who has a checked out copy of the directory that the
+directory will be renamed. They should commit all their changes in all their
+copies of the project containing the directory to be removed, and remove
+all their working copies of said project, before you take the steps below.
+
address@hidden
+Rename the directory inside the repository.
+
address@hidden
+$ cd $CVSROOT/@var{parent-dir}
+$ mv @var{old-dir} @var{new-dir}
address@hidden example
+
address@hidden
+Fix the @sc{cvs} administrative files, if necessary (for
+instance if you renamed an entire module).
+
address@hidden
+Tell everyone that they can check out again and continue
+working.
+
address@hidden enumerate
+
+If someone had a working copy the @sc{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.
+
address@hidden
---------------------------------------------------------------------
address@hidden History browsing
address@hidden History browsing
address@hidden History browsing
address@hidden Traceability
address@hidden Isolation
+
address@hidden
address@hidden This is too long for an introduction (goal is
address@hidden one 20x80 character screen), and also mixes up a
address@hidden variety of issues (parallel development, history,
address@hidden maybe even touches on process control).
+
address@hidden -- @quote{To lose ones history is to lose ones soul.}
address@hidden -- ///
address@hidden -- ///Those who cannot remember the past are condemned to repeat
it.
address@hidden -- /// -- George Santayana
address@hidden -- ///
+
address@hidden tries to make it easy for a group of people to work
+together. This is done in two ways:
+
address@hidden @bullet
address@hidden
+Isolation---You have your own working copy of the
+source. You are not affected by modifications made by
+others until you decide to incorporate those changes
+(via the @code{update} address@hidden).
+
address@hidden
+Traceability---When something has changed, you can
+always see @emph{exactly} what changed.
address@hidden itemize
+
+There are several features of @sc{cvs} that together lead
+to traceability:
+
address@hidden @bullet
address@hidden
+Each revision of a file has an accompanying log
+message.
+
address@hidden
+All commits are optionally logged to a central history
+database.
+
address@hidden
+Logging information can be sent to a user-defined
+program (@pxref{loginfo}).
address@hidden itemize
+
address@hidden -- More text here.
+
+This chapter should talk about the history file, the
address@hidden command, the usefulness of ChangeLogs
+even when you run @sc{cvs}, and things like that.
+
address@hidden ignore
+
address@hidden kind of lame, in a lot of ways the above text inside
address@hidden the @ignore motivates this chapter better
+Once you have used @sc{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.
+
address@hidden FIXME: should also be talking about how you look at
address@hidden old revisions (e.g. "cvs update -p -r 1.2 foo.c").
address@hidden
+* log messages:: Log messages
+* history database:: The history database
+* user-defined logging:: User-defined logging
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden log messages
address@hidden Log messages
+
address@hidden FIXME: @xref to place where we talk about how to
address@hidden specify message to commit.
+Whenever you commit a file you specify a log message.
+
address@hidden FIXME: bring the information here, and get rid of or
address@hidden greatly shrink the "log" node.
+To look through the log messages which have been
+specified for every revision which has been committed,
+use the @code{cvs log} command (@pxref{log}).
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden history database
address@hidden The history database
+
address@hidden FIXME: bring the information from the history file
address@hidden and history nodes here. Rewrite it to be motivated
address@hidden better (start out by clearly explaining what gets
address@hidden logged in history, for example).
+You can use the history file (@pxref{history file}) to
+log various @sc{cvs} actions. To retrieve the
+information from the history file, use the @code{cvs
+history} command (@pxref{history}).
+
+Note: you can control what is logged to this file by using the
address@hidden keyword in the @file{CVSROOT/config} file
+(@pxref{config}).
+
address@hidden
address@hidden The history database has many problems:
address@hidden * It is very unclear what field means what. This
address@hidden could be improved greatly by better documentation,
address@hidden but there are still non-orthogonalities (for
address@hidden example, tag does not record the "repository"
address@hidden field but most records do).
address@hidden * Confusion about files, directories, and modules.
address@hidden Some commands record one, some record others.
address@hidden * File removal is not logged. There is an 'R'
address@hidden record type documented, but CVS never uses it.
address@hidden * Tags are only logged for the "cvs rtag" command,
address@hidden not "cvs tag". The fix for this is not completely
address@hidden clear (see above about modules vs. files).
address@hidden * Are there other cases of operations that are not
address@hidden logged? One would hope for all changes to the
address@hidden repository to be logged somehow (particularly
address@hidden operations like tagging, "cvs admin -k", and other
address@hidden operations which do not record a history that one
address@hidden can get with "cvs log"). Operations on the working
address@hidden directory, like export, get, and release, are a
address@hidden second category also covered by the current "cvs
address@hidden history".
address@hidden * The history file does not record the options given
address@hidden to a command. The most serious manifestation of
address@hidden this is perhaps that it doesn't record whether a command
address@hidden was recursive. It is not clear to me whether one
address@hidden wants to log at a level very close to the command
address@hidden line, as a sort of way of logging each command
address@hidden (more or less), or whether one wants
address@hidden to log more at the level of what was changed (or
address@hidden something in between), but either way the current
address@hidden information has pretty big gaps.
address@hidden * Further details about a tag--like whether it is a
address@hidden branch tag or, if a non-branch tag, which branch it
address@hidden is on. One can find out this information about the
address@hidden tag as it exists _now_, but if the tag has been
address@hidden moved, one doesn't know what it was like at the time
address@hidden the history record was written.
address@hidden * Whether operating on a particular tag, date, or
address@hidden options was implicit (sticky) or explicit.
address@hidden
address@hidden Another item, only somewhat related to the above, is a
address@hidden way to control what is logged in the history file.
address@hidden This is probably the only good way to handle
address@hidden different people having different ideas about
address@hidden information/space tradeoffs.
address@hidden
address@hidden It isn't really clear that it makes sense to try to
address@hidden patch up the history file format as it exists now to
address@hidden include all that stuff. It might be better to
address@hidden design a whole new CVSROOT/nhistory file and "cvs
address@hidden nhistory" command, or some such, or in some other
address@hidden way trying to come up with a clean break from the
address@hidden past, which can address the above concerns. Another
address@hidden open question is how/whether this relates to
address@hidden taginfo/loginfo/etc.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden user-defined logging
address@hidden User-defined logging
+
address@hidden FIXME: probably should centralize this information
address@hidden here, at least to some extent. Maybe by moving the
address@hidden loginfo, etc., nodes here and replacing
address@hidden the "user-defined logging" node with one node for
address@hidden each method.
+You can customize @sc{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 @file{loginfo} file (@pxref{loginfo}), and
+to log tagging operations, use the @file{taginfo} file
+(@pxref{taginfo}).
+
address@hidden FIXME: What is difference between doing it in the
address@hidden modules file and using loginfo/taginfo? Why should
address@hidden user use one or the other?
+To log commits, checkouts, exports, and tags,
+respectively, you can also use the @samp{-i},
address@hidden, @samp{-e}, and @samp{-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 @code{cvs watch add} command (@pxref{Getting
+Notified}); this command is useful even if you are not
+using @code{cvs watch on}.
+
address@hidden
---------------------------------------------------------------------
address@hidden Binary files
address@hidden Handling binary files
address@hidden Binary files
+
+The most common use for @sc{cvs} is to store text
+files. With text files, @sc{cvs} can merge revisions,
+display the differences between revisions in a
+human-visible fashion, and other such operations.
+However, if you are willing to give up a few of these
+abilities, @sc{cvs} can store binary files. For
+example, one might store a web site in @sc{cvs}
+including both text files and binary images.
+
address@hidden
+* Binary why:: More details on issues with binary files
+* Binary howto:: How to store them
address@hidden menu
+
address@hidden Binary why
address@hidden The issues with binary files
+
+While the need to manage binary files may seem obvious
+if the files that you customarily work with are binary,
+putting them into version control does present some
+additional issues.
+
+One basic function of version control is to show the
+differences between two revisions. For example, if
+someone else checked in a new version of a file, you
+may wish to look at what they changed and determine
+whether their changes are good. For text files,
address@hidden provides this functionality via the @code{cvs
+diff} command. For binary files, it may be possible to
+extract the two revisions and then compare them with a
+tool external to @sc{cvs} (for example, word processing
+software often has such a feature). If there is no
+such tool, one must track changes via other mechanisms,
+such as urging people to write good log messages, and
+hoping that the changes they actually made were the
+changes that they intended to make.
+
+Another ability of a version control system is the
+ability to merge two revisions. For @sc{cvs} this
+happens in two contexts. The first is when users make
+changes in separate working directories
+(@pxref{Multiple developers}). The second is when one
+merges explicitly with the @samp{update -j} command
+(@pxref{Branching and merging}).
+
+In the case of text
+files, @sc{cvs} can merge changes made independently,
+and signal a conflict if the changes conflict. With
+binary files, the best that @sc{cvs} can do is present
+the two different copies of the file, and leave it to
+the user to resolve the conflict. The user may choose
+one copy or the other, or may run an external merge
+tool which knows about that particular file format, if
+one exists.
+Note that having the user merge relies primarily on the
+user to not accidentally omit some changes, and thus is
+potentially error prone.
+
+If this process is thought to be undesirable, the best
+choice may be to avoid merging. To avoid the merges
+that result from separate working directories, see the
+discussion of reserved checkouts (file locking) in
address@hidden developers}. To avoid the merges
+resulting from branches, restrict use of branches.
+
address@hidden Binary howto
address@hidden How to store binary files
+
+There are two issues with using @sc{cvs} to store
+binary files. The first is that @sc{cvs} by default
+converts 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 (@pxref{Keyword
+substitution}), so keyword expansion must be turned
+off.
+
address@hidden FIXME: the third is that one can't do merges with
address@hidden binary files. xref to Multiple Developers and the
address@hidden reserved checkout issues.
+
+The @samp{-kb} option available with some @sc{cvs}
+commands insures that neither line ending conversion
+nor keyword expansion will be done.
+
+Here is an example of how you can create a new file
+using the @samp{-kb} flag:
+
address@hidden
+$ echo 'address@hidden' > kotest
+$ cvs add -kb -m"A test file" kotest
+$ cvs ci -m"First checkin; contains a keyword" kotest
address@hidden example
+
+If a file accidentally gets added without @samp{-kb},
+one can use the @code{cvs admin} command to recover.
+For example:
+
address@hidden
+$ echo 'address@hidden' > 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
+# @r{For non-unix systems:}
+# @r{Copy in a good copy of the file from outside CVS}
+$ cvs commit -m "make it binary" kotest
address@hidden example
+
address@hidden Trying to describe this for both unix and non-unix
address@hidden in the same description is very confusing. Might
address@hidden want to split the two, or just ditch the unix "shortcut"
address@hidden (unixheads don't do much with binary files, anyway).
address@hidden This used to say "(Try the above example, and do a
address@hidden @code{cat kotest} after every command)". But that
address@hidden only really makes sense for the unix case.
+When you check in the file @file{kotest} the file is
+not preserved as a binary file, because you did not
+check it in as a binary file. The @code{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. If you need to
+cope with line endings (that is, you are using
address@hidden on a non-unix system), then you need to
+check in a new copy of the file, as shown by the
address@hidden commit} command above.
+On unix, the @code{cvs update -A} command suffices.
address@hidden FIXME: should also describe what the *other users*
address@hidden need to do, if they have checked out copies which
address@hidden have been corrupted by lack of -kb. I think maybe
address@hidden "cvs update -kb" or "cvs
address@hidden update -A" would suffice, although the user who
address@hidden reported this suggested removing the file, manually
address@hidden removing it from CVS/Entries, and then "cvs update"
+(Note that you can use @code{cvs log} to determine the default keyword
+substitution method for a file and @code{cvs status} to determine
+the keyword substitution method for a working copy.)
+
+However, in using @code{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,
address@hidden 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 @code{cvs add}
+and @code{cvs import} treat a file as binary based on
+its name; for example you could say that files who
+names end in @samp{.exe} are binary. @xref{Wrappers}.
+There is currently no way to have @sc{cvs} detect
+whether a file is binary based on its contents. The
+main difficulty with designing such a feature is that
+it is not clear how to distinguish between binary and
+non-binary files, and the rules to apply would vary
+considerably with the operating system.
address@hidden For example, it would be good on MS-DOS-family OSes
address@hidden for anything containing ^Z to be binary. Having
address@hidden characters with the 8th bit set imply binary is almost
address@hidden surely a bad idea in the context of ISO-8859-* and
address@hidden other such character sets. On VMS or the Mac, we
address@hidden could use the OS's file typing. This is a
address@hidden commonly-desired feature, and something of this sort
address@hidden may make sense. But there are a lot of pitfalls here.
address@hidden
address@hidden Another, probably better, way to tell is to read the
address@hidden file in text mode, write it to a temp file in text
address@hidden mode, and then do a binary mode compare of the two
address@hidden files. If they differ, it is a binary file. This
address@hidden might have problems on VMS (or some other system
address@hidden with several different text modes), but in general
address@hidden should be relatively portable. The only other
address@hidden downside I can think of is that it would be fairly
address@hidden slow, but that is perhaps a small price to pay for
address@hidden not having your files corrupted. Another issue is
address@hidden what happens if you import a text file with bare
address@hidden linefeeds on Windows. Such files will show up on
address@hidden Windows sometimes (I think some native windows
address@hidden programs even write them, on occasion). Perhaps it
address@hidden is reasonable to treat such files as binary; after
address@hidden all it is something of a presumption to assume that
address@hidden the user would want the linefeeds converted to CRLF.
+
address@hidden
---------------------------------------------------------------------
address@hidden Multiple developers
address@hidden Multiple developers
address@hidden Multiple developers
address@hidden Team of developers
address@hidden File locking
address@hidden Locking files
address@hidden Working copy
address@hidden Reserved checkouts
address@hidden Unreserved checkouts
address@hidden RCS-style locking
+
+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 @dfn{file locking} or @dfn{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 @sc{rcs} and @sc{sccs}. Currently
+the usual way to get reserved checkouts with @sc{cvs}
+is the @code{cvs admin -l} command (@pxref{admin
+options}). This is not as nicely integrated into
address@hidden as the watch features, described below, but it
+seems that most people with a need for reserved
+checkouts find it adequate.
address@hidden Or "find it better than worrying about implementing
address@hidden nicely integrated reserved checkouts" or ...?
+
+As of @sc{cvs} version 1.12.10, another technique for getting most of the
+effect of reserved checkouts is to enable advisory locks. To enable advisory
+locks, have all developers put "edit -c", "commit -c" in their
+.cvsrc file, and turn on watches in the repository. This
+prevents them from doing a @code{cvs edit} if anyone is
+already editting the file. It also may
+be possible to use plain watches together with suitable
+procedures (not enforced by software), to avoid having
+two people edit at the same time.
+
address@hidden Our unreserved checkout model might not
address@hidden be quite the same as others. For example, I
address@hidden think that some systems will tend to create a branch
address@hidden in the case where CVS prints "up-to-date check failed".
address@hidden It isn't clear to me whether we should try to
address@hidden explore these subtleties; it could easily just
address@hidden confuse people.
+The default model with @sc{cvs} is known as
address@hidden checkouts}. In this model, developers
+can edit their own @dfn{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 @sc{cvs} commands to bring their working copy
+up to date with the repository revision. This process
+is almost automatic.
+
address@hidden FIXME? should probably use the word "watch" here, to
address@hidden tie this into the text below and above.
address@hidden also supports mechanisms which facilitate
+various kinds of communication, 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.
+
address@hidden
+Here is a draft reserved checkout design or discussion
+of the issues. This seems like as good a place as any
+for this.
+
+Might want a cvs lock/cvs unlock--in which the names
+differ from edit/unedit because the network must be up
+for these to work. unedit gives an error if there is a
+reserved checkout in place (so that people don't
+accidentally leave locks around); unlock gives an error
+if one is not in place (this is more arguable; perhaps
+it should act like unedit in that case).
+
+On the other hand, might want it so that emacs,
+scripts, etc., can get ready to edit a file without
+having to know which model is in use. In that case we
+would have a "cvs watch lock" (or .cvsrc?) (that is,
+three settings, "on", "off", and "lock"). Having cvs
+watch lock set would cause a get to record in the CVS
+directory which model is in use, and cause "cvs edit"
+to change behaviors. We'd want a way to query which
+setting is in effect (this would be handy even if it is
+only "on" or "off" as presently). If lock is in
+effect, then commit would require a lock before
+allowing a checkin; chmod wouldn't suffice (might be
+debatable--see chmod comment below, in watches--but it
+is the way people expect RCS to work and I can't think
+of any significant downside. On the other hand, maybe
+it isn't worth bothering, because people who are used
+to RCS wouldn't think to use chmod anyway).
+
+Implementation: use file attributes or use RCS
+locking. The former avoids more dependence on RCS
+behaviors we will need to re-implement as we librarify
+RCS, and makes it easier to import/export RCS files (in
+that context, want to ignore the locker field). But
+note that RCS locks are per-branch, which is the
+correct behavior (this is also an issue for the "watch
+on" features; they should be per-branch too).
+
+Here are a few more random notes about implementation
+details, assuming "cvs watch lock" and
+
+CVS/Watched file? Or try to fit this into CVS/Entries somehow?
+Cases: (1) file is checked out (unreserved or with watch on) by old
+version of @sc{cvs}, now we do something with new one, (2) file is checked
+out by new version, now we do something with old one.
+
+Remote protocol would have a "Watched" analogous to "Mode". Of course
+it would apply to all Updated-like requests. How do we keep this
+setting up to date? I guess that there wants to be a Watched request,
+and the server would send a new one if it isn't up to date? (Ugh--hard
+to implement and slows down "cvs -q update"--is there an easier way?)
+
+"cvs edit"--checks CVS/Watched, and if watch lock, then sends
+"edit-lock" request. Which comes back with a Checked-in with
+appropriate Watched (off, on, lock, locked, or some such?), or error
+message if already locked.
+
+"cvs commit"--only will commit if off/on/locked. lock is not OK.
+
+Doc:
+note that "cvs edit" must be connected to network if watch lock is in
+effect.
+
+Talk about what to do if someone has locked a file and you want to
+edit that file. (breaking locks, or lack thereof).
+
+
+One other idea (which could work along with the
+existing "cvs admin -l" reserved checkouts, as well as
+the above):
+
+"cvs editors" could show who has the file locked, if
+someone does.
+
address@hidden ignore
+
address@hidden
+* File status:: A file can be in several states
+* Updating a file:: Bringing a file up-to-date
+* Conflicts example:: An informative example
+* Informing others:: To cooperate you must inform
+* Concurrency:: Simultaneous repository access
+* Watches:: Mechanisms to track who is editing files
+* Choosing a model:: Reserved or unreserved checkouts?
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden File status
address@hidden File status
address@hidden File status
address@hidden Status of a file
+
address@hidden Shouldn't this start with an example or something,
address@hidden introducing the unreserved checkout model? Before we
address@hidden dive into listing states?
+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} command, are:
+
address@hidden The order of items is chosen to group logically
address@hidden similar outputs together.
address@hidden People who want alphabetical can use the index...
address@hidden @asis
address@hidden Up-to-date
address@hidden Up-to-date
+The file is identical with the latest revision in the
+repository for the branch in use.
address@hidden FIXME: should we clarify "in use"? The answer is
address@hidden sticky tags, and trying to distinguish branch sticky
address@hidden tags from non-branch sticky tags seems rather awkward
address@hidden here.
address@hidden FIXME: What happens with non-branch sticky tags? Is
address@hidden a stuck file "Up-to-date" or "Needs checkout" or what?
+
address@hidden Locally Modified
address@hidden Locally Modified
+You have edited the file, and not yet committed your changes.
+
address@hidden Locally Added
address@hidden Locally Added
+You have added the file with @code{add}, and not yet
+committed your changes.
address@hidden There are many cases involving the file being
address@hidden added/removed/modified in the working directory, and
address@hidden added/removed/modified in the repository, which we
address@hidden don't try to describe here. I'm not sure that "cvs
address@hidden status" produces a non-confusing output in most of
address@hidden those cases.
+
address@hidden Locally Removed
address@hidden Locally Removed
+You have removed the file with @code{remove}, and not yet
+committed your changes.
+
address@hidden Needs Checkout
address@hidden Needs Checkout
+Someone else has committed a newer revision to the
+repository. The name is slightly misleading; you will
+ordinarily use @code{update} rather than
address@hidden to get that newer revision.
+
address@hidden Needs Patch
address@hidden Needs Patch
address@hidden See also newb-123j0 in sanity.sh (although that case
address@hidden should probably be changed rather than documented).
+Like Needs Checkout, but the @sc{cvs} server will send
+a patch rather than the entire file. Sending a patch or
+sending an entire file accomplishes the same thing.
+
address@hidden Needs Merge
address@hidden Needs Merge
+Someone else has committed a newer revision to the repository, and you
+have also made modifications to the file.
+
address@hidden Unresolved Conflict
address@hidden Unresolved Conflict
address@hidden FIXCVS - This file status needs to be changed to some more
informative
address@hidden text that distinguishes it more clearly from each of the Locally
Added,
address@hidden File had conflicts on merge, and Unknown status types, but an
exact and
address@hidden succinct wording escapes me at the moment.
+A file with the same name as this new file has been added to the repository
+from a second workspace. This file will need to be moved out of the way
+to allow an @code{update} to complete.
+
address@hidden File had conflicts on merge
address@hidden File had conflicts on merge
address@hidden is it worth saying that this message was "Unresolved
address@hidden Conflict" in CVS 1.9 and earlier? I'm inclined to
address@hidden think that is unnecessarily confusing to new users.
+This is like Locally Modified, except that a previous
address@hidden command gave a conflict. If you have not
+already done so, you need to
+resolve the conflict as described in @ref{Conflicts example}.
+
address@hidden Unknown
address@hidden Unknown
address@hidden doesn't know anything about this file. For
+example, you have created a new file and have not run
address@hidden
address@hidden
address@hidden "Entry Invalid" and "Classify Error" are also in the
address@hidden status.c. The latter definitely indicates a CVS bug
address@hidden (should it be worded more like "internal error" so
address@hidden people submit bug reports if they see it?). The former
address@hidden I'm not as sure; I haven't tracked down whether/when it
address@hidden appears in "cvs status" output.
+
address@hidden table
+
+To help clarify the file status, @code{status} also
+reports the @code{Working revision} which is the
+revision that the file in the working directory derives
+from, and the @code{Repository revision} which is the
+latest revision in the repository for the branch in
+use.
+The @samp{Commit Identifier} reflects the unique commitid
+of the @code{commit}.
address@hidden FIXME: should we clarify "in use"? The answer is
address@hidden sticky tags, and trying to distinguish branch sticky
address@hidden tags from non-branch sticky tags seems rather awkward
address@hidden here.
address@hidden FIXME: What happens with non-branch sticky tags?
address@hidden What is the Repository Revision there? See the
address@hidden comment at vn_rcs in cvs.h, which is kind of
address@hidden confused--we really need to document better what this
address@hidden field contains.
address@hidden Q: Should we document "New file!" and other such
address@hidden outputs or are they self-explanatory?
address@hidden FIXME: what about the date to the right of "Working
address@hidden revision"? It doesn't appear with client/server and
address@hidden seems unnecessary (redundant with "ls -l") so
address@hidden perhaps it should be removed for non-client/server too?
address@hidden FIXME: Need some examples.
address@hidden FIXME: Working revision can also be something like
address@hidden "-1.3" for a locally removed file. Not at all
address@hidden self-explanatory (and it is possible that CVS should
address@hidden be changed rather than documenting this).
+
address@hidden Would be nice to have an @example showing output
address@hidden from cvs status, with comments showing the xref
address@hidden where each part of the output is described. This
address@hidden might fit in nicely if it is desirable to split this
address@hidden node in two; one to introduce "cvs status" and one
address@hidden to list each of the states.
+The options to @code{status} are listed in
address@hidden CVS}. For information on its @code{Sticky tag}
+and @code{Sticky date} output, see @ref{Sticky tags}.
+For information on its @code{Sticky options} output,
+see the @samp{-k} option in @ref{update options}.
+
+You can think of the @code{status} and @code{update}
+commands as somewhat complementary. You use
address@hidden to bring your files up to date, and you
+can use @code{status} to give you some idea of what an
address@hidden would do (of course, the state of the
+repository might change before you actually run
address@hidden). In fact, if you want a command to
+display file status in a more brief format than is
+displayed by the @code{status} command, you can invoke
+
address@hidden update, to display file status
address@hidden
+$ cvs -n -q update
address@hidden example
+
+The @samp{-n} option means to not actually do the
+update, but merely to display statuses; the @samp{-q}
+option avoids printing the name of each directory. For
+more information on the @code{update} command, and
+these options, see @ref{Invoking CVS}.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Updating a file
address@hidden Bringing a file up to date
address@hidden Bringing a file up to date
address@hidden Updating a file
address@hidden Merging a file
address@hidden Update, introduction
+
+When you want to update or merge a file, use the @code{cvs update -d}
+command. For files that are not up to date this is roughly equivalent
+to a @code{checkout} command: the newest revision of the file is
+extracted from the repository and put in your working directory. The
address@hidden option, not necessary with @code{checkout}, tells @sc{cvs}
+that you wish it to create directories added by other developers.
+
+Your modifications to a file are never lost when you
+use @code{update}. If no newer revision exists,
+running @code{update} has no effect. If you have
+edited the file, and a newer revision is available,
address@hidden 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 @code{update} on the file
+now, @sc{cvs} will incorporate all changes between revision 1.4 and 1.6 into
+your file.
+
address@hidden Overlap
+If any of the changes between 1.4 and 1.6 were made too
+close to any of the changes you have made, an
address@hidden occurs. In such cases a warning is
+printed, and the resulting file includes both
+versions of the lines that overlap, delimited by
+special markers.
address@hidden, for a complete description of the
address@hidden command.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Conflicts example
address@hidden Conflicts example
address@hidden Merge, an example
address@hidden Example of merge
address@hidden driver.c (merge example)
+
+Suppose revision 1.4 of @file{driver.c} contains this:
+
address@hidden
+#include <stdio.h>
+
+void main()
address@hidden
+ parse();
+ if (nerr == 0)
+ gencode();
+ else
+ fprintf(stderr, "No code generated.\n");
+ exit(nerr == 0 ? 0 : 1);
address@hidden
address@hidden example
+
address@hidden
+Revision 1.6 of @file{driver.c} contains this:
+
address@hidden
+#include <stdio.h>
+
+int main(int argc,
+ char **argv)
address@hidden
+ 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);
address@hidden
address@hidden example
+
address@hidden
+Your working copy of @file{driver.c}, based on revision
+1.4, contains this before you run @samp{cvs update}:
address@hidden -- Really include "cvs"?
+
address@hidden
+#include <stdlib.h>
+#include <stdio.h>
+
+void main()
address@hidden
+ init_scanner();
+ parse();
+ if (nerr == 0)
+ gencode();
+ else
+ fprintf(stderr, "No code generated.\n");
+ exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
address@hidden
address@hidden example
+
address@hidden
+You run @samp{cvs update}:
address@hidden -- Really include "cvs"?
+
address@hidden
+$ 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
address@hidden example
+
address@hidden
address@hidden Conflicts (merge example)
address@hidden tells you that there were some conflicts.
+Your original working file is saved unmodified in
address@hidden The new version of
address@hidden contains this:
+
address@hidden
+#include <stdlib.h>
+#include <stdio.h>
+
+int main(int argc,
+ char **argv)
address@hidden
+ 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");
address@hidden<<<<<<< driver.c
+ exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
address@hidden
+ exit(!!nerr);
address@hidden>>>>>>> 1.6
address@hidden
address@hidden example
+
address@hidden
address@hidden Markers, conflict
address@hidden Conflict markers
address@hidden <<<<<<<
address@hidden >>>>>>>
address@hidden =======
+
+Note how all non-overlapping modifications are incorporated in your working
+copy, and that the overlapping section is clearly marked with
address@hidden<<<<<<<}, @samp{=======} and @samp{>>>>>>>}.
+
address@hidden Resolving a conflict
address@hidden Conflict resolution
+You resolve the conflict by editing the file, removing the markers and
+the erroneous line. Suppose you end up with this file:
address@hidden -- Add xref to the pcl-cvs manual when it talks
address@hidden -- about this.
address@hidden
+#include <stdlib.h>
+#include <stdio.h>
+
+int main(int argc,
+ char **argv)
address@hidden
+ 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);
address@hidden
address@hidden example
+
address@hidden
+You can now go ahead and commit this as revision 1.7.
+
address@hidden
+$ 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
address@hidden example
+
+For your protection, @sc{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. In previous
+versions of @sc{cvs}, you also needed to
+insure that the file contains no conflict markers.
+Because
+your file may legitimately contain conflict markers (that
+is, occurrences of @samp{>>>>>>> } at the start of a
+line that don't mark a conflict), the current
+version of @sc{cvs} will print a warning and proceed to
+check in the file.
address@hidden The old behavior was really icky; the only way out
address@hidden was to start hacking on
address@hidden the @code{CVS/Entries} file or other such workarounds.
address@hidden
address@hidden If the timestamp thing isn't considered nice enough,
address@hidden maybe there should be a "cvs resolved" command
address@hidden which clears the conflict indication. For a nice user
address@hidden interface, this should be invoked by an interactive
address@hidden merge tool like emerge rather than by the user
address@hidden directly--such a tool can verify that the user has
address@hidden really dealt with each conflict.
+
address@hidden emerge
+If you use release 1.04 or later of pcl-cvs (a @sc{gnu}
+Emacs front-end for @sc{cvs}) you can use an Emacs
+package called emerge to help you resolve conflicts.
+See the documentation for pcl-cvs.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Informing others
address@hidden Informing others about commits
address@hidden Informing others
address@hidden Spreading information
address@hidden Mail, automatic mail on commit
+
+It is often useful to inform others when you commit a
+new revision of a file. The @samp{-i} option of the
address@hidden file, or the @file{loginfo} file, can be
+used to automate this process. @xref{modules}.
address@hidden You can use these features of @sc{cvs}
+to, for instance, instruct @sc{cvs} to mail a
+message to all developers, or post a message to a local
+newsgroup.
address@hidden -- More text would be nice here.
+
address@hidden Concurrency
address@hidden Several developers simultaneously attempting to run CVS
+
address@hidden Locks, cvs, introduction
address@hidden For a discussion of *why* CVS creates locks, see
address@hidden the comment at the start of src/lock.c
+If several developers try to run @sc{cvs} at the same
+time, one may get the following message:
+
address@hidden
+[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
address@hidden example
+
address@hidden #cvs.rfl, removing
address@hidden #cvs.wfl, removing
address@hidden #cvs.lock, removing
address@hidden 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 in the repository directory mentioned in
+the message and remove files which they own whose names
+start with @file{#cvs.rfl},
address@hidden, or @file{#cvs.lock}.
+
+Note that these locks are to protect @sc{cvs}'s
+internal data structures and have no relationship to
+the word @dfn{lock} in the sense used by
address@hidden refers to reserved checkouts
+(@pxref{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.
+
address@hidden Atomic transactions, lack of
address@hidden Transactions, atomic, lack of
address@hidden the following talks about what one might call commit/update
address@hidden atomicity.
address@hidden Probably also should say something about
address@hidden commit/commit atomicity, that is, "An update will
address@hidden not get partial versions of more than one commit".
address@hidden CVS currently has this property and I guess we can
address@hidden make it a documented feature.
address@hidden For example one person commits
address@hidden a/one.c and b/four.c and another commits a/two.c and
address@hidden b/three.c. Then an update cannot get the new a/one.c
address@hidden and a/two.c and the old b/four.c and b/three.c.
+One might hope for the following property:
+
address@hidden
+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.
address@hidden quotation
+
address@hidden
+but @sc{cvs} does @emph{not} have this property. For
+example, given the files
+
address@hidden
+a/one.c
+a/two.c
+b/three.c
+b/four.c
address@hidden example
+
address@hidden
+if someone runs
+
address@hidden
+cvs ci a/two.c b/three.c
address@hidden example
+
address@hidden
+and someone else runs @code{cvs update} at the same
+time, the person running @code{update} might get only
+the change to @file{b/three.c} and not the change to
address@hidden/two.c}.
+
address@hidden Watches
address@hidden Mechanisms to track who is editing files
address@hidden Watches
+
+For many groups, use of @sc{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.
+
address@hidden Some people might ask why CVS does not enforce the
address@hidden rule on chmod, by requiring a cvs edit before a cvs
address@hidden commit. The main reason is that it could always be
address@hidden circumvented--one could edit the file, and
address@hidden then when ready to check it in, do the cvs edit and put
address@hidden in the new contents and do the cvs commit. One
address@hidden implementation note: if we _do_ want to have cvs commit
address@hidden require a cvs edit, we should store the state on
address@hidden whether the cvs edit has occurred in the working
address@hidden directory, rather than having the server try to keep
address@hidden track of what working directories exist.
address@hidden FIXME: should the above discussion be part of the
address@hidden manual proper, somewhere, not just in a comment?
+For maximum benefit developers should use @code{cvs
+edit} (not @code{chmod}) to make files read-write to
+edit them, and @code{cvs release} (not @code{rm}) to
+discard a working directory which is no longer in use,
+but @sc{cvs} is not able to enforce this behavior.
+
+If a development team wants stronger enforcement of
+watches and all team members are using a @sc{cvs} client version 1.12.10 or
+greater to access a @sc{cvs} server version 1.12.10 or greater, they can
+enable advisory locks. To enable advisory locks, have all developers
+put "edit -c" and "commit -c" into all .cvsrc files,
+and make files default to read only by turning on watches
+or putting "cvs -r" into all .cvsrc files.
+This prevents multiple people from editting a file at
+the same time (unless explicitly overriden with @samp{-f}).
+
address@hidden I'm a little dissatisfied with this presentation,
address@hidden because "watch on"/"edit"/"editors" are one set of
address@hidden functionality, and "watch add"/"watchers" is another
address@hidden which is somewhat orthogonal even though they interact in
address@hidden various ways. But I think it might be
address@hidden confusing to describe them separately (e.g. "watch
address@hidden add" with loginfo). I don't know.
+
address@hidden
+* Setting a watch:: Telling CVS to watch certain files
+* Getting Notified:: Telling CVS to notify you
+* Editing files:: How to edit a file which is being watched
+* Watch information:: Information about who is watching and editing
+* Watches Compatibility:: Watches interact poorly with CVS 1.6 or earlier
address@hidden menu
+
address@hidden Setting a watch
address@hidden Telling CVS to watch certain files
+
+To enable the watch features, you first specify that
+certain files are to be watched.
+
address@hidden watch on (subcommand)
address@hidden Command {cvs watch on} address@hidden address@hidden@dots{}
+
address@hidden Read-only files, and watches
+Specify that developers should run @code{cvs edit}
+before editing @var{files}. @sc{cvs} will create working
+copies of @var{files} read-only, to remind developers
+to run the @code{cvs edit} command before working on
+them.
+
+If @var{files} includes the name of a directory, @sc{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} option is given.
+The @code{-R} option can be used to force recursion if the @code{-l}
+option is set in @file{~/.cvsrc} (@pxref{~/.cvsrc}).
+
+If @var{files} is omitted, it defaults to the current directory.
+
address@hidden watch off (subcommand)
address@hidden deffn
+
address@hidden Command {cvs watch off} address@hidden address@hidden@dots{}
+
+Do not create @var{files} read-only on checkout; thus,
+developers will not be reminded to use @code{cvs edit}
+and @code{cvs unedit}.
address@hidden
address@hidden will check out @var{files}
+read-write as usual, unless other permissions override
+due to the @code{PreservePermissions} option being
+enabled in the @file{config} administrative file
+(@pxref{Special Files}, @pxref{config})
address@hidden ignore
+
+The @var{files} and options are processed as for @code{cvs
+watch on}.
+
address@hidden deffn
+
address@hidden Getting Notified
address@hidden Telling CVS to notify you
+
+You can tell @sc{cvs} that you want to receive
+notifications about various actions taken on a file.
+You can do this without using @code{cvs watch on} for
+the file, but generally you will want to use @code{cvs
+watch on}, to remind developers to use the @code{cvs edit}
+command.
+
address@hidden watch add (subcommand)
address@hidden Command {cvs watch add} address@hidden address@hidden
@address@hidden address@hidden@dots{}
+
+Add the current user to the list of people to receive notification of
+work done on @var{files}.
+
+The @code{-a} option specifies what kinds of events @sc{cvs} should notify
+the user about. @var{action} is one of the following:
+
address@hidden @code
+
address@hidden edit
+Another user has applied the @code{cvs edit} command (described
+below) to a watched file.
+
address@hidden commit
+Another user has committed changes to one of the named @var{files}.
+
address@hidden unedit
+Another user has abandoned editing a file (other than by committing changes).
+They can do this in several ways, by:
+
address@hidden @bullet
+
address@hidden
+applying the @code{cvs unedit} command (described below) to the file
+
address@hidden
+applying the @code{cvs release} command (@pxref{release}) to the file's parent
directory
+(or recursively to a directory more than one level up)
+
address@hidden
+deleting the file and allowing @code{cvs update} to recreate it
+
address@hidden itemize
+
address@hidden all
+All of the above.
+
address@hidden none
+None of the above. (This is useful with @code{cvs edit},
+described below.)
+
address@hidden table
+
+The @code{-a} option may appear more than once, or not at all. If
+omitted, the action defaults to @code{all}.
+
+The @var{files} and options are processed as for
address@hidden watch on}.
+
address@hidden deffn
+
+
address@hidden watch remove (subcommand)
address@hidden Command {cvs watch remove} address@hidden address@hidden
@address@hidden address@hidden@dots{}
+
+Remove a notification request established using @code{cvs watch add};
+the arguments are the same. If the @code{-a} option is present, only
+watches for the specified actions are removed.
+
address@hidden deffn
+
address@hidden notify (admin file)
+When the conditions exist for notification, @sc{cvs}
+calls the @file{notify} administrative file. Edit
address@hidden as one edits the other administrative
+files (@pxref{Intro administrative files}). This
+file follows the usual conventions for administrative
+files (@pxref{syntax}), where each line is a regular
+expression followed by a command to execute. The
+command should contain a single occurrence of @samp{%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 @code{notify} file is the
+single line:
+
address@hidden
+ALL mail %s -s "CVS notification"
address@hidden example
+
address@hidden
+This causes users to be notified by electronic mail.
address@hidden FIXME: should it be this hard to set up this
address@hidden behavior (and the result when one fails to do so,
address@hidden silent failure to notify, so non-obvious)? Should
address@hidden CVS give a warning if no line in notify matches (and
address@hidden document the use of "DEFAULT :" for the case where
address@hidden skipping the notification is indeed desired)?
+
address@hidden users (admin file)
+Note that if you set this up in the straightforward
+way, users receive notifications on the server machine.
+One could of course write a @file{notify} script which
+directed notifications elsewhere, but to make this
+easy, @sc{cvs} allows you to associate a notification
+address for each user. To do so create a file
address@hidden in @file{CVSROOT} with a line for each
+user in the format @var{user}:@var{value}. Then
+instead of passing the name of the user to be notified
+to @file{notify}, @sc{cvs} will pass the @var{value}
+(normally an email address on some other machine).
+
address@hidden does not notify you for your own changes.
+Currently this check is done based on whether the user
+name of the person taking the action which triggers
+notification matches the user name of the person
+getting notification. In fact, in general, the watches
+features only track one edit by each user. It probably
+would be more useful if watches tracked each working
+directory separately, so this behavior might be worth
+changing.
address@hidden "behavior might be worth changing" is an effort to
address@hidden point to future directions while also not promising
address@hidden that "they" (as in "why don't they fix CVS to....")
address@hidden will do this.
address@hidden one implementation issue is identifying whether a
address@hidden working directory is same or different. Comparing
address@hidden pathnames/hostnames is hopeless, but having the server
address@hidden supply a serial number which the client stores in the
address@hidden CVS directory as a magic cookie should work.
+
address@hidden Editing files
address@hidden How to edit a file which is being watched
+
address@hidden Checkout, as term for getting ready to edit
+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} command. Some systems
+call this a @dfn{checkout}, but @sc{cvs} uses that term
+for obtaining a copy of the sources (@pxref{Getting the
+source}), an operation which those systems call a
address@hidden or a @dfn{fetch}.
address@hidden Issue to think about: should we transition CVS
address@hidden towards the "get" terminology? "cvs get" is already a
address@hidden synonym for "cvs checkout" and that section of the
address@hidden manual refers to "Getting the source". If this is
address@hidden done, needs to be done gingerly (for example, we should
address@hidden still accept "checkout" in .cvsrc files indefinitely
address@hidden even if the CVS's messages are changed from "cvs checkout: "
address@hidden to "cvs get: ").
address@hidden There is a concern about whether "get" is not as
address@hidden good for novices because it is a more general term
address@hidden than "checkout" (and thus arguably harder to assign
address@hidden a technical meaning for).
+
address@hidden edit (subcommand)
address@hidden Command {cvs edit} address@hidden address@hidden @address@hidden
address@hidden@dots{}
+
+Prepare to edit the working files @var{files}. @sc{cvs} makes the
address@hidden read-write, and notifies users who have requested
address@hidden notification for any of @var{files}.
+
+The @code{cvs edit} command accepts the same options as the
address@hidden watch add} command, and establishes a temporary watch for the
+user on @var{files}; @sc{cvs} will remove the watch when @var{files} are
address@hidden or @code{commit}ted. If the user does not wish to
+receive notifications, she should specify @code{-a none}.
+
+The @var{files} and the options are processed as for the @code{cvs
+watch} commands.
+
+There are two additional options that @code{cvs edit} understands as of
address@hidden client and server versions 1.12.10 but @code{cvs watch} does not.
+The first is @code{-c}, which causes @code{cvs edit} to fail if anyone else
+is editting the file. This is probably only useful when @samp{edit -c} and
address@hidden -c} are specified in all developers' @file{.cvsrc} files. This
+behavior may be overriden this via the @code{-f} option, which overrides
address@hidden and allows multiple edits to succeed.
+
address@hidden
address@hidden: If the @code{PreservePermissions}
+option is enabled in the repository (@pxref{config}),
address@hidden will not change the permissions on any of the
address@hidden The reason for this change is to ensure
+that using @samp{cvs edit} does not interfere with the
+ability to store file permissions in the @sc{cvs}
+repository.}
address@hidden ignore
+
address@hidden deffn
+
+Normally when you are done with a set of changes, you
+use the @code{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 @code{cvs unedit} command.
+
address@hidden unedit (subcommand)
address@hidden Abandoning work
address@hidden Reverting to repository version
address@hidden Command {cvs unedit} address@hidden address@hidden@dots{}
+
+Abandon work on the working files @var{files}, and revert them to the
+repository versions on which they are based. @sc{cvs} makes those
address@hidden read-only for which users have requested notification using
address@hidden watch on}. @sc{cvs} notifies users who have requested
@code{unedit}
+notification for any of @var{files}.
+
+The @var{files} and options are processed as for the
address@hidden watch} commands.
+
+If watches are not in use, the @code{unedit} command
+probably does not work, and the way to revert to the
+repository version is with the command @code{cvs update -C file}
+(@pxref{update}).
+The meaning is
+not precisely the same; the latter may also
+bring in some changes which have been made in the
+repository since the last time you updated.
address@hidden It would be a useful enhancement to CVS to make
address@hidden unedit work in the non-watch case as well.
address@hidden deffn
+
+When using client/server @sc{cvs}, you can use the
address@hidden edit} and @code{cvs unedit} commands even if
address@hidden is unable to successfully communicate with the
+server; the notifications will be sent upon the next
+successful @sc{cvs} command.
+
address@hidden Watch information
address@hidden Information about who is watching and editing
+
address@hidden watchers (subcommand)
address@hidden Command {cvs watchers} address@hidden address@hidden@dots{}
+
+List the users currently watching changes to @var{files}. The report
+includes the files being watched, and the mail address of each watcher.
+
+The @var{files} and options are processed as for the
address@hidden watch} commands.
+
address@hidden deffn
+
+
address@hidden editors (subcommand)
address@hidden Command {cvs editors} address@hidden address@hidden@dots{}
+
+List the users currently working on @var{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 @var{files} and options are processed as for the
address@hidden watch} commands.
+
address@hidden deffn
+
address@hidden Watches Compatibility
address@hidden Using watches with old versions of CVS
+
address@hidden CVS 1.6, and watches
+If you use the watch features on a repository, it
+creates @file{CVS} directories in the repository and
+stores the information about watches in that directory.
+If you attempt to use @sc{cvs} 1.6 or earlier with the
+repository, you get an error message such as the
+following (all on one line):
+
address@hidden
+cvs update: cannot open CVS/Entries for reading:
+No such file or directory
address@hidden example
+
address@hidden
+and your operation will likely be aborted. To use the
+watch features, you must upgrade all copies of @sc{cvs}
+which use that repository in local or server mode. If
+you cannot upgrade, use the @code{watch off} and
address@hidden remove} commands to remove all watches, and
+that will restore the repository to a state which
address@hidden 1.6 can cope with.
+
address@hidden Choosing a model
address@hidden Choosing between reserved or unreserved checkouts
address@hidden Choosing, 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 a brief description of some of the
+issues. There are many ways to organize a team of
+developers. @sc{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.
+
address@hidden "many groups"? specifics? cites to papers on this?
address@hidden some way to weasel-word it a bit more so we don't
address@hidden need facts :-)?
+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 @emph{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 @ref{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 watches can be
+considered the best of both the reserved checkout and unreserved
+checkout worlds.
+
+As of @sc{cvs} client and server versions 1.12.10, you may also enable
+advisory locks by putting @samp{edit -c} and @samp{commit -c} in all
+developers' @file{.cvsrc} files. After this is done, @code{cvs edit}
+will fail if there are any other editors, and @code{cvs commit} will
+fail if the committer has not registered to edit the file via @code{cvs edit}.
+This is most effective in conjunction with files checked out read-only by
+default, which may be enabled by turning on watches in the repository or by
+putting @samp{cvs -r} in all @file{.cvsrc} files.
+
+
address@hidden
---------------------------------------------------------------------
address@hidden Revision management
address@hidden Revision management
address@hidden Revision management
+
address@hidden -- This chapter could be expanded a lot.
address@hidden -- Experiences are very welcome!
+
+If you have read this far, you probably have a pretty
+good grasp on what @sc{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 @sc{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.
+
address@hidden
+* When to commit:: Some discussion on the subject
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden When to commit
address@hidden When to commit?
address@hidden When to commit
address@hidden Committing, when to
address@hidden Policy
+
+Your group should decide which policy to use regarding
+commits. Several policies are possible, and as your
+experience with @sc{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
+(@pxref{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.
+
address@hidden
---------------------------------------------------------------------
address@hidden Keyword substitution
address@hidden Keyword substitution
address@hidden Keyword substitution
address@hidden Keyword expansion
address@hidden Identifying files
+
address@hidden Be careful when editing this chapter.
address@hidden Remember that this file is kept under
address@hidden version control, so we must not accidentally
address@hidden include a valid keyword in the running text.
+
+As long as you edit source files inside a working
+directory you can always find out the state of
+your files via @samp{cvs status} and @samp{cvs log}.
+But as soon as you export the files from your
+development environment it becomes harder to identify
+which revisions they are.
+
address@hidden can use a mechanism known as @dfn{keyword
+substitution} (or @dfn{keyword expansion}) to help
+identifying the files. Embedded strings of the form
address@hidden@var{keyword}$} and
address@hidden@var{keyword}:@dots{}$} in a file are replaced
+with strings of the form
address@hidden@var{keyword}:@var{value}$} whenever you obtain
+a new revision of the file.
+
address@hidden
+* Keyword list:: Keywords
+* Using keywords:: Using keywords
+* Avoiding substitution:: Avoiding substitution
+* Substitution modes:: Substitution modes
+* Configuring keyword expansion:: Configuring keyword expansion
+* Log keyword:: Problems with the address@hidden keyword.
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Keyword list
address@hidden Keyword List
address@hidden Keyword List
+
address@hidden FIXME: need some kind of example here I think,
address@hidden perhaps in a
address@hidden "Keyword intro" node. The intro in the "Keyword
address@hidden substitution" node itself seems OK, but to launch
address@hidden into a list of the keywords somehow seems too abrupt.
+
+This is a list of the keywords:
+
address@hidden @code
address@hidden Author keyword
address@hidden address@hidden
+The login name of the user who checked in the revision.
+
address@hidden CVSHeader keyword
address@hidden address@hidden
+A standard header (similar to address@hidden, but with
+the CVS root stripped off). It contains the relative
+pathname of the @sc{rcs} file to the CVS root, the
+revision number, the date (UTC), the author, the state,
+and the locker (if locked). Files will normally never
+be locked when you use @sc{cvs}.
+
+Note that this keyword has only been recently
+introduced to @sc{cvs} and may cause problems with
+existing installations if address@hidden is already
+in the files for a different purpose. This keyword may
+be excluded using the @code{KeywordExpand=eCVSHeader}
+in the @file{CVSROOT/config} file.
+See @ref{Configuring keyword expansion} for more details.
+
address@hidden Date keyword
address@hidden address@hidden
+The date and time (UTC) the revision was checked in.
+
address@hidden Header keyword
address@hidden address@hidden
+A standard header containing the full pathname of the
address@hidden 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 @sc{cvs}.
+
address@hidden Id keyword
address@hidden address@hidden
+Same as @address@hidden, except that the @sc{rcs}
+filename is without a path.
+
address@hidden Name keyword
address@hidden address@hidden
+Tag name used to check out this file. The keyword is
+expanded only if one checks out with an explicit tag
+name. For example, when running the command @code{cvs
+co -r first}, the keyword expands to @samp{Name: first}.
+
address@hidden Locker keyword
address@hidden address@hidden
+The login name of the user who locked the revision
+(empty if not locked, which is the normal case unless
address@hidden admin -l} is in use).
+
address@hidden Log keyword
address@hidden MaxCommentLeaderLength
address@hidden UseArchiveCommentLeader
address@hidden Log keyword, configuring substitution behavior
address@hidden address@hidden
+The log message supplied during commit, preceded by a
+header containing the @sc{rcs} filename, the revision
+number, the author, and the date (UTC). Existing log
+messages are @emph{not} replaced. Instead, the new log
+message is inserted after @address@hidden:@dots{}$}.
+By default, each new line is prefixed with the same string which
+precedes the @address@hidden keyword, unless it exceeds the
address@hidden set in @file{CVSROOT/config}.
+
+For example, if the file contains:
+
address@hidden
+ /* Here is what people have been up to:
+ *
+ * address@hidden: frob.c,v $
+ * Revision 1.1 1997/01/03 14:23:51 joe
+ * Add the superfrobnicate option
+ *
+ */
address@hidden example
+
address@hidden
+then additional lines which are added when expanding
+the @address@hidden keyword will be preceded by @samp{ * }.
+Unlike previous versions of @sc{cvs} and @sc{rcs}, the
address@hidden leader} from the @sc{rcs} file is not used.
+The @address@hidden keyword is useful for
+accumulating a complete change log in a source file,
+but for several reasons it can be problematic.
+
+If the prefix of the @address@hidden keyword turns out to be
+longer than @code{MaxCommentLeaderLength}, CVS will skip expansion of this
+keyword unless @code{UseArchiveCommentLeader} is also set in
address@hidden/config} and a @samp{comment leader} is set in the RCS archive
+file, in which case the comment leader will be used instead. For more on
+setting the comment leader in the RCS archive file, @xref{admin}. For more
+on configuring the default @address@hidden substitution
+behavior, @xref{config}.
+
address@hidden keyword}.
+
address@hidden RCSfile keyword
address@hidden address@hidden
+The name of the RCS file without a path.
+
address@hidden Revision keyword
address@hidden address@hidden
+The revision number assigned to the revision.
+
address@hidden Source keyword
address@hidden address@hidden
+The full pathname of the RCS file.
+
address@hidden State keyword
address@hidden address@hidden
+The state assigned to the revision. States can be
+assigned with @code{cvs admin -s}---see @ref{admin options}.
+
address@hidden Local keyword
address@hidden Local keyword
+The @code{LocalKeyword} option in the @file{CVSROOT/config} file
+may be used to specify a local keyword which is to be
+used as an alias for one of the keywords: address@hidden,
address@hidden, or address@hidden For
+example, if the @file{CVSROOT/config} file contains
+a line with @code{LocalKeyword=MYBSD=CVSHeader}, then a
+file with the local keyword address@hidden will be
+expanded as if it were a address@hidden keyword. If
+the src/frob.c file contained this keyword, it might
+look something like this:
+
address@hidden
+ /*
+ * address@hidden: src/frob.c,v 1.1 2003/05/04 09:27:45 john Exp $
+ */
address@hidden example
+
+Many repositories make use of a such a ``local
+keyword'' feature. An old patch to @sc{cvs} provided
+the @code{LocalKeyword} feature using a @code{tag=}
+option and called this the ``custom tag'' or ``local
+tag'' feature. It was used in conjunction with the
+what they called the @code{tagexpand=} option. In
address@hidden this other option is known as the
address@hidden option.
+See @ref{Configuring keyword expansion} for more
+details.
+
+Examples from popular projects include:
address@hidden, address@hidden,
address@hidden, address@hidden,
address@hidden
+
+The advantage of this is that you can include your
+local version information in a file using this local
+keyword without disrupting the upstream version
+information (which may be a different local keyword or
+a standard keyword). Allowing bug reports and the like
+to more properly identify the source of the original
+bug to the third-party and reducing the number of
+conflicts that arise during an import of a new version.
+
+All keyword expansion except the local keyword may be
+disabled using the @code{KeywordExpand} option in
+the @file{CVSROOT/config} file---see
address@hidden keyword expansion} for more details.
+
address@hidden table
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Using keywords
address@hidden Using keywords
+
+To include a keyword string you simply include the
+relevant text string, such as @address@hidden, inside the
+file, and commit the file. @sc{cvs} will automatically (Or,
+more accurately, as part of the update run that
+automatically happens after a commit.)
+expand the string as part of the commit operation.
+
+It is common to embed the @address@hidden string in
+the source files so that it gets passed through to
+generated files. For example, if you are managing
+computer program source code, you might include a
+variable which is initialized to contain that string.
+Or some C compilers may provide a @code{#pragma ident}
+directive. Or a document management system might
+provide a way to pass a string through to generated
+files.
+
address@hidden Would be nice to give an example, but doing this in
address@hidden portable C is not possible and the problem with
address@hidden picking any one language (VMS HELP files, Ada,
address@hidden troff, whatever) is that people use CVS for all
address@hidden kinds of files.
+
address@hidden Ident (shell command)
+The @code{ident} command (which is part of the @sc{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.
+
address@hidden
+$ ident samp.c
+samp.c:
+ address@hidden: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
+$ gcc samp.c
+$ ident a.out
+a.out:
+ address@hidden: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
address@hidden example
+
address@hidden What (shell command)
address@hidden is another popular revision control system.
+It has a command, @code{what}, which is very similar to
address@hidden and used for the same purpose. Many sites
+without @sc{rcs} have @sc{sccs}. Since @code{what}
+looks for the character sequence @code{@@(#)} it is
+easy to include keywords that are detected by either
+command. Simply prefix the keyword with the
+magic @sc{sccs} phrase, like this:
+
address@hidden
+static char *id="@@(#) address@hidden: ab.c,v 1.5 1993/10/19 14:57:32 ceder
Exp $";
address@hidden example
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Avoiding substitution
address@hidden Avoiding substitution
+
+Keyword substitution has its disadvantages. Sometimes
+you might want the literal text string
address@hidden@splitrcskeyword{Author}$} to appear inside a file without
address@hidden interpreting it as a keyword and expanding it
+into something like @address@hidden: ceder $}.
+
+There is unfortunately no way to selectively turn off
+keyword substitution. You can use @samp{-ko}
+(@pxref{Substitution modes}) to turn off keyword
+substitution entirely.
+
+In many cases you can avoid using keywords in
+the source, even though they appear in the final
+product. For example, the source for this manual
+contains @samp{$@@address@hidden@}Author$} whenever the text
address@hidden@splitrcskeyword{Author}$} should appear. In @code{nroff}
+and @code{troff} you can embed the null-character
address@hidden&} inside the keyword for a similar effect.
+
+It is also possible to specify an explicit list of
+keywords to include or exclude using the
address@hidden option in the
address@hidden/config} file--see @ref{Configuring keyword expansion}
+for more details. This feature is intended primarily
+for use with the @code{LocalKeyword} option--see
address@hidden list}.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Substitution modes
address@hidden Substitution modes
address@hidden Keyword substitution, changing modes
address@hidden -k (keyword substitution)
address@hidden Kflag
+
address@hidden FIXME: This could be made more coherent, by expanding it
address@hidden with more examples or something.
+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}
+option to @code{cvs add} and @code{cvs admin}; the
+latter is set by the @samp{-k} or @samp{-A} options to @code{cvs
+checkout} or @code{cvs update}.
address@hidden diff} and @code{cvs rdiff} also
+have @samp{-k} options.
+For some examples,
+see @ref{Binary files}, and @ref{Merging and keywords}.
address@hidden The fact that -A is overloaded to mean both reset
address@hidden sticky options and reset sticky tags/dates is
address@hidden somewhat questionable. Perhaps there should be
address@hidden separate options to reset sticky options (e.g. -k
address@hidden A") and tags/dates (someone suggested -r HEAD could
address@hidden do this instead of setting a sticky tag of "HEAD"
address@hidden as in the status quo but I haven't thought much
address@hidden about that idea. Of course -r .reset or something
address@hidden could be coined if this needs to be a new option).
address@hidden On the other hand, having -A mean "get things back
address@hidden into the state after a fresh checkout" has a certain
address@hidden appeal, and maybe there is no sufficient reason for
address@hidden creeping featurism in this area.
+
+The modes available are:
+
address@hidden @samp
address@hidden -kkv
+Generate keyword strings using the default form, e.g.
address@hidden@splitrcskeyword{Revision}: 5.7 $} for the @code{Revision}
+keyword.
+
address@hidden -kkvl
+Like @samp{-kkv}, except that a locker's name is always
+inserted if the given revision is currently locked.
+The locker's name is only relevant if @code{cvs admin
+-l} is in use.
+
address@hidden -kk
+Generate only keyword names in keyword strings; omit
+their values. For example, for the @code{Revision}
+keyword, generate the string @address@hidden
+instead of @address@hidden: 5.7 $}. This option
+is useful to ignore differences due to keyword
+substitution when comparing different revisions of a
+file (@pxref{Merging and keywords}).
+
address@hidden -ko
+Generate the old keyword string, present in the working
+file just before it was checked in. For example, for
+the @code{Revision} keyword, generate the string
address@hidden@splitrcskeyword{Revision}: 1.1 $} instead of
address@hidden@splitrcskeyword{Revision}: 5.7 $} if that is how the
+string appeared when the file was checked in.
+
address@hidden -kb
+Like @samp{-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 very similar to
address@hidden For more information on binary files, see
address@hidden files}. In @sc{cvs} version 1.12.2 and later
address@hidden, as set by @code{cvs add}, @code{cvs admin}, or
address@hidden import} may not be overridden by a @samp{-k} option
+specified on the command line.
+
address@hidden -kv
+Generate only keyword values for keyword strings. For
+example, for the @code{Revision} keyword, generate the string
address@hidden instead of @address@hidden: 5.7 $}.
+This can help generate files in programming languages
+where it is hard to strip keyword delimiters like
address@hidden@splitrcskeyword{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} with @code{cvs
address@hidden But be aware that doesn't
+handle an export containing binary files correctly.
+
address@hidden table
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Configuring keyword expansion
address@hidden Configuring Keyword Expansion
address@hidden Configuring keyword expansion
+
+In a repository that includes third-party software on
+vendor branches, it is sometimes helpful to configure
+CVS to use a local keyword instead of the standard
address@hidden or address@hidden keywords. Examples from
+real projects include address@hidden, address@hidden,
address@hidden, address@hidden,
address@hidden, and even address@hidden
+The advantage of this is that
+you can include your local version information in a
+file using this local keyword (sometimes called a
+``custom tag'' or a ``local tag'') without disrupting
+the upstream version information (which may be a
+different local keyword or a standard keyword). In
+these cases, it is typically desirable to disable the
+expansion of all keywords except the configured local
+keyword.
+
+The @code{KeywordExpand} option in the
address@hidden/config} file is intended to allow for the
+either the explicit exclusion of a keyword or list of
+keywords, or for the explicit inclusion of a keyword or
+a list of keywords. This list may include the
address@hidden that has been configured.
+
+The @code{KeywordExpand} option is followed by
address@hidden and the next character may either be @code{i}
+to start an inclusion list or @code{e} to start an
+exclusion list. If the following lines were added to
+the @file{CVSROOT/config} file:
+
address@hidden
+ # Add a "MyBSD" keyword and restrict keyword
+ # expansion
+ LocalKeyword=MyBSD=CVSHeader
+ KeywordExpand=iMyBSD
address@hidden example
+
+then only the address@hidden keyword would be expanded.
+A list may be used. The this example:
+
address@hidden
+ # Add a "MyBSD" keyword and restrict keyword
+ # expansion to the MyBSD, Name and Date keywords.
+ LocalKeyword=MyBSD=CVSHeader
+ KeywordExpand=iMyBSD,Name,Date
address@hidden example
+
+would allow address@hidden, address@hidden, and
address@hidden to be expanded.
+
+It is also possible to configure an exclusion list
+using the following:
+
address@hidden
+ # Do not expand the non-RCS keyword CVSHeader
+ KeywordExpand=eCVSHeader
address@hidden example
+
+This allows @sc{cvs} to ignore the recently introduced
address@hidden keyword and retain all of the
+others. The exclusion entry could also contain the
+standard RCS keyword list, but this could be confusing
+to users that expect RCS keywords to be expanded, so
+care should be taken to properly set user expectations
+for a repository that is configured in that manner.
+
+If there is a desire to not have any RCS keywords
+expanded and not use the @code{-ko} flags everywhere,
+an administrator may disable all keyword expansion
+using the @file{CVSROOT/config} line:
+
address@hidden
+ # Do not expand any RCS keywords
+ KeywordExpand=i
address@hidden example
+
+this could be confusing to users that expect RCS
+keywords like address@hidden to be expanded properly,
+so care should be taken to properly set user
+expectations for a repository so configured.
+
+It should be noted that a patch to provide both the
address@hidden and @code{LocalKeyword} features
+has been around a long time. However, that patch
+implemented these features using @code{tag=} and
address@hidden keywords and those keywords are NOT
+recognized.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Log keyword
address@hidden Problems with the address@hidden keyword.
+
+The @address@hidden 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 @address@hidden
+keyword---just do a @code{cvs log}. Once you export
+the file the history information might be useless
+anyhow.
+
+A more serious concern is that @sc{cvs} is not good at
+handling @address@hidden entries when a branch is
+merged onto the main trunk. Conflicts often result
+from the merging operation.
address@hidden Might want to check whether the CVS implementation
address@hidden of RCS_merge has this problem the same way rcsmerge
address@hidden does. I would assume so....
+
+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
address@hidden 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 @address@hidden
+keyword should be inserted @emph{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.
+
address@hidden
---------------------------------------------------------------------
address@hidden Tracking sources
address@hidden Tracking third-party sources
address@hidden Third-party sources
address@hidden Tracking sources
+
address@hidden FIXME: Need discussion of added and removed files.
address@hidden FIXME: This doesn't really adequately introduce the
address@hidden concepts of "vendor" and "you". They don't *have*
address@hidden to be separate organizations or separate people.
address@hidden We want a description which is somewhat more based on
address@hidden the technical issues of which sources go where, but
address@hidden also with enough examples of how this relates to
address@hidden relationships like customer-supplier, developer-QA,
address@hidden maintainer-contributor, or whatever, to make it
address@hidden seem concrete.
+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. @sc{cvs} can help you with
+this task.
+
address@hidden Vendor
address@hidden Vendor branch
address@hidden Branch, vendor-
+In the terminology used in @sc{cvs}, the supplier of the
+program is called a @dfn{vendor}. The unmodified
+distribution from the vendor is checked in on its own
+branch, the @dfn{vendor branch}. @sc{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 @code{import} command to create and update
+the vendor branch. When you import a new file,
+(usually) 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.
+
address@hidden
+* First import:: Importing for the first time
+* Update imports:: Updating with the import command
+* Reverting local changes:: Reverting to the latest vendor release
+* Binary files in imports:: Binary files require special handling
+* Keywords in imports:: Keyword substitution might be undesirable
+* Multiple vendor branches:: What if you get sources from several places?
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden First import
address@hidden Importing for the first time
address@hidden Importing modules
+
address@hidden Should mention naming conventions for vendor tags,
address@hidden release tags, and perhaps directory names.
+Use the @code{import} command to check in the sources
+for the first time. When you use the @code{import}
+command to track third-party sources, the @dfn{vendor
+tag} and @dfn{release tags} are useful. The
address@hidden tag} is a symbolic name for the branch
+(which is always 1.1.1, unless you use the @samp{-b
address@hidden flag---see @ref{Multiple vendor branches}.). The
address@hidden tags} are symbolic names for a particular
+release, such as @samp{FSF_0_04}.
+
address@hidden I'm not completely sure this belongs here. But
address@hidden we need to say it _somewhere_ reasonably obvious; it
address@hidden is a common misconception among people first learning CVS
+Note that @code{import} does @emph{not} change the
+directory in which you invoke it. In particular, it
+does not set up that directory as a @sc{cvs} working
+directory; if you want to work with the sources import
+them first and then check them out into a different
+directory (@pxref{Getting the source}).
+
address@hidden wdiff (import example)
+Suppose you have the sources to a program called
address@hidden in a directory @file{wdiff-0.04},
+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:
+
address@hidden
+$ cd wdiff-0.04
+$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
address@hidden example
+
+The vendor tag is named @samp{FSF_DIST} in the above
+example, and the only release tag assigned is
address@hidden
address@hidden FIXME: Need to say where fsf/wdiff comes from.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Update imports
address@hidden Updating with the import command
+
+When a new release of the source arrives, you import it into the
+repository with the same @code{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:
+
address@hidden
+$ 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
address@hidden example
+
address@hidden: If you use a release tag that already exists in one of the
+repository archives, files removed by an import may not be detected.}
+
+For files that have not been modified locally, the newly created
+revision becomes the head revision. If you have made local
+changes, @code{import} will warn you that you must merge the changes
+into the main trunk, and tell you to use @samp{checkout -j} to do so:
+
address@hidden FIXME: why "wdiff" here and "fsf/wdiff" in the
address@hidden "import"? I think the assumption is that one has
address@hidden "wdiff fsf/wdiff" or some such in modules, but it
address@hidden would be better to not use modules in this example.
address@hidden
+$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
address@hidden example
+
address@hidden
+The above command will check out the latest revision of
address@hidden, merging the changes made on the vendor branch @samp{FSF_DIST}
+since yesterday into the working copy. If any conflicts arise during
+the merge they should be resolved in the normal way (@pxref{Conflicts
+example}). Then, the modified files may be committed.
+
+However, it is much better to use the two release tags rather than using
+a date on the branch as suggested above:
+
address@hidden
+$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
address@hidden example
+
address@hidden
+The reason this is better is that
+using a date, as suggested above, assumes that you do
+not import more than one release of a product per day.
+More importantly, using the release tags allows @sc{cvs} to detect files
+that were removed between the two vendor releases and mark them for
+removal. Since @code{import} has no way to detect removed files, you
+should do a merge like this even if @code{import} doesn't tell you to.
+
address@hidden Reverting local changes
address@hidden Reverting to the latest vendor release
+
+You can also revert local changes completely and return
+to the latest vendor release by changing the `head'
+revision back to the vendor branch on all files. For
+example, if you have a checked-out copy of the sources
+in @file{~/work.d/wdiff}, and you want to revert to the
+vendor's version for all the files in that directory,
+you would type:
+
address@hidden
+$ cd ~/work.d/wdiff
+$ cvs admin -bFSF_DIST .
address@hidden example
+
address@hidden
+You must specify the @samp{-bFSF_DIST} without any space
+after the @samp{-b}. @xref{admin options}.
+
address@hidden Binary files in imports
address@hidden How to handle binary files with cvs import
+
+Use the @samp{-k} wrapper option to tell import which
+files are binary. @xref{Wrappers}.
+
address@hidden Keywords in imports
address@hidden How to handle keyword substitution with cvs import
+
+The sources which you are importing may contain
+keywords (@pxref{Keyword substitution}). For example,
+the vendor may use @sc{cvs} or some other system
+which uses similar keyword expansion syntax. If you
+just import the files in the default fashion, then
+the keyword expansions supplied by the vendor will
+be replaced by keyword expansions supplied by your
+own copy of @sc{cvs}. It may be more convenient to
+maintain the expansions supplied by the vendor, so
+that this information can supply information about
+the sources that you imported from the vendor.
+
+To maintain the keyword expansions supplied by the
+vendor, supply the @samp{-ko} option to @code{cvs
+import} the first time you import the file.
+This will turn off keyword expansion
+for that file entirely, so if you want to be more
+selective you'll have to think about what you want
+and use the @samp{-k} option to @code{cvs update} or
address@hidden admin} as appropriate.
address@hidden Supplying -ko to import if the file already existed
address@hidden has no effect. Not clear to me whether it should
address@hidden or not.
+
address@hidden Multiple vendor branches
address@hidden Multiple vendor branches
+
+All the examples so far assume that there is only one
+vendor from which you are getting sources. In some
+situations you might get sources from a variety of
+places. For example, suppose that you are dealing with
+a project where many different people and teams are
+modifying the software. There are a variety of ways to
+handle this, but in some cases you have a bunch of
+source trees lying around and what you want to do more
+than anything else is just to all put them in @sc{cvs} so
+that you at least have them in one place.
+
+For handling situations in which there may be more than
+one vendor, you may specify the @samp{-b} option to
address@hidden import}. It takes as an argument the vendor
+branch to import to. The default is @samp{-b 1.1.1}.
+
+For example, suppose that there are two teams, the red
+team and the blue team, that are sending you sources.
+You want to import the red team's efforts to branch
+1.1.1 and use the vendor tag RED. You want to import
+the blue team's efforts to branch 1.1.3 and use the
+vendor tag BLUE. So the commands you might use are:
+
address@hidden
+$ cvs import dir RED RED_1-0
+$ cvs import -b 1.1.3 dir BLUE BLUE_1-5
address@hidden example
+
+Note that if your vendor tag does not match your
address@hidden option, @sc{cvs} will not detect this case! For
+example,
+
address@hidden
+$ cvs import -b 1.1.3 dir RED RED_1-0
address@hidden example
+
address@hidden
+Be careful; this kind of mismatch is sure to sow
+confusion or worse. I can't think of a useful purpose
+for the ability to specify a mismatch here, but if you
+discover such a use, don't. @sc{cvs} is likely to make this
+an error in some future release.
+
address@hidden Probably should say more about the semantics of
address@hidden multiple branches. What about the default branch?
address@hidden What about joining (perhaps not as useful with
address@hidden multiple branches, or perhaps it is. Either way
address@hidden should be mentioned).
+
address@hidden I'm not sure about the best location for this. In
address@hidden one sense, it might belong right after we've introduced
address@hidden CVS's basic version control model, because people need
address@hidden to figure out builds right away. The current location
address@hidden is based on the theory that it kind of akin to the
address@hidden "Revision management" section.
address@hidden Builds
address@hidden How your build system interacts with CVS
address@hidden Builds
address@hidden make
+
+As mentioned in the introduction, @sc{cvs} does not
+contain software for building your software from source
+code. This section describes how various aspects of
+your build system might interact with @sc{cvs}.
+
address@hidden Is there a way to discuss this without reference to
address@hidden tools other than CVS? I'm not sure there is; I
address@hidden wouldn't think that people who learn CVS first would
address@hidden even have this concern.
+One common question, especially from people who are
+accustomed to @sc{rcs}, is how to make their build get
+an up to date copy of the sources. The answer to this
+with @sc{cvs} is two-fold. First of all, since
address@hidden itself can recurse through directories, there
+is no need to modify your @file{Makefile} (or whatever
+configuration file your build tool uses) to make sure
+each file is up to date. Instead, just use two
+commands, first @code{cvs -q update} and then
address@hidden or whatever the command is to invoke your
+build tool. Secondly, you do not necessarily
address@hidden to get a copy of a change someone else made
+until you have finished your own work. One suggested
+approach is to first update your sources, then
+implement, build and
+test the change you were thinking of, and then commit
+your sources (updating first if necessary). By
+periodically (in between changes, using the approach
+just described) updating your entire tree, you ensure
+that your sources are sufficiently up to date.
+
address@hidden Bill of materials
+One common need is to record which versions of which
+source files went into a particular build. This kind
+of functionality is sometimes called @dfn{bill of
+materials} or something similar. The best way to do
+this with @sc{cvs} is to use the @code{tag} command to
+record which versions went into a given build
+(@pxref{Tags}).
+
+Using @sc{cvs} in the most straightforward manner
+possible, each developer will have a copy of the entire
+source tree which is used in a particular build. If
+the source tree is small, or if developers are
+geographically dispersed, this is the preferred
+solution. In fact one approach for larger projects is
+to break a project down into smaller
address@hidden I say subsystem instead of module because they may or
address@hidden may not use the modules file.
+separately-compiled subsystems, and arrange a way of
+releasing them internally so that each developer need
+check out only those subsystems which they are
+actively working on.
+
+Another approach is to set up a structure which allows
+developers to have their own copies of some files, and
+for other files to access source files from a central
+location. Many people have come up with some such a
address@hidden two such people are address@hidden (for
address@hidden a previous employer)
address@hidden and address@hidden (spicm and related tools),
address@hidden but as far as I know
address@hidden no one has nicely packaged or released such a system (or
address@hidden instructions for constructing one).
+system using features such as the symbolic link feature
+found in many operating systems, or the @code{VPATH}
+feature found in many versions of @code{make}. One build
+tool which is designed to help with this kind of thing
+is Odin (see
address@hidden://ftp.cs.colorado.edu/pub/distribs/odin}).
address@hidden Should we be saying more about Odin? Or how you use
address@hidden it with CVS? Also, the Prime Time Freeware for Unix
address@hidden disk (see http://www.ptf.com/) has Odin (with a nice
address@hidden paragraph summarizing it on the web), so that might be a
address@hidden semi-"official" place to point people.
address@hidden
address@hidden Of course, many non-CVS systems have this kind of
address@hidden functionality, for example OSF's ODE
address@hidden (http://www.osf.org/ode/) or mk
address@hidden (http://www.grin.net/~pzi/mk-3.18.4.docs/mk_toc.html
address@hidden He has changed providers in the past; a search engine search
address@hidden for "Peter Ziobrzynski" probably won't get too many
address@hidden spurious hits :-). A more stable URL might be
address@hidden ftp://ftp.uu.net/pub/cmvc/mk). But I'm not sure
address@hidden there is any point in mentioning them here unless they
address@hidden can work with CVS.
+
address@hidden
---------------------------------------------------------------------
address@hidden Special Files
address@hidden Special Files
+
address@hidden Special files
address@hidden Device nodes
address@hidden Ownership, saving in CVS
address@hidden Permissions, saving in CVS
address@hidden Hard links
address@hidden Symbolic links
+
+In normal circumstances, @sc{cvs} works only with regular
+files. Every file in a project is assumed to be
+persistent; it must be possible to open, read and close
+them; and so on. @sc{cvs} also ignores file permissions and
+ownerships, leaving such issues to be resolved by the
+developer at installation time. In other words, it is
+not possible to "check in" a device into a repository;
+if the device file cannot be opened, @sc{cvs} will refuse to
+handle it. Files also lose their ownerships and
+permissions during repository transactions.
+
address@hidden
+If the configuration variable @code{PreservePermissions}
+(@pxref{config}) is set in the repository, @sc{cvs} will
+save the following file characteristics in the
+repository:
+
address@hidden @bullet
address@hidden user and group ownership
address@hidden permissions
address@hidden major and minor device numbers
address@hidden symbolic links
address@hidden hard link structure
address@hidden itemize
+
+Using the @code{PreservePermissions} option affects the
+behavior of @sc{cvs} in several ways. First, some of the
+new operations supported by @sc{cvs} are not accessible to
+all users. In particular, file ownership and special
+file characteristics may only be changed by the
+superuser. When the @code{PreservePermissions}
+configuration variable is set, therefore, users will
+have to be `root' in order to perform @sc{cvs} operations.
+
+When @code{PreservePermissions} is in use, some @sc{cvs}
+operations (such as @samp{cvs status}) will not
+recognize a file's hard link structure, and so will
+emit spurious warnings about mismatching hard links.
+The reason is that @sc{cvs}'s internal structure does not
+make it easy for these operations to collect all the
+necessary data about hard links, so they check for file
+conflicts with inaccurate data.
+
+A more subtle difference is that @sc{cvs} considers a file
+to have changed only if its contents have changed
+(specifically, if the modification time of the working
+file does not match that of the repository's file).
+Therefore, if only the permissions, ownership or hard
+linkage have changed, or if a device's major or minor
+numbers have changed, @sc{cvs} will not notice. In order to
+commit such a change to the repository, you must force
+the commit with @samp{cvs commit -f}. This also means
+that if a file's permissions have changed and the
+repository file is newer than the working copy,
+performing @samp{cvs update} will silently change the
+permissions on the working copy.
+
+Changing hard links in a @sc{cvs} repository is particularly
+delicate. Suppose that file @file{foo} is linked to
+file @file{old}, but is later relinked to file
address@hidden You can wind up in the unusual situation
+where, although @file{foo}, @file{old} and @file{new}
+have all had their underlying link patterns changed,
+only @file{foo} and @file{new} have been modified, so
address@hidden is not considered a candidate for checking
+in. It can be very easy to produce inconsistent
+results this way. Therefore, we recommend that when it
+is important to save hard links in a repository, the
+prudent course of action is to @code{touch} any file
+whose linkage or status has changed since the last
+checkin. Indeed, it may be wise to @code{touch *}
+before each commit in a directory with complex hard
+link structures.
+
+It is worth noting that only regular files may
+be merged, for reasons that hopefully are obvious. If
address@hidden update} or @samp{cvs checkout -j} attempts to
+merge a symbolic link with a regular file, or two
+device files for different kinds of devices, @sc{cvs} will
+report a conflict and refuse to perform the merge. At
+the same time, @samp{cvs diff} will not report any
+differences between these files, since no meaningful
+textual comparisons can be made on files which contain
+no text.
+
+The @code{PreservePermissions} features do not work
+with client/server @sc{cvs}. Another limitation is
+that hard links must be to other files within the same
+directory; hard links across directories are not
+supported.
address@hidden ignore
+
address@hidden
---------------------------------------------------------------------
address@hidden ----- START MAN 1 -----
address@hidden CVS commands
address@hidden Guide to CVS commands
+
+This appendix describes the overall structure of
address@hidden commands, and describes some commands in
+detail (others are described elsewhere; for a quick
+reference to @sc{cvs} commands, @pxref{Invoking CVS}).
address@hidden The idea is that we want to move the commands which
address@hidden are described here into the main body of the manual,
address@hidden in the process reorganizing the manual to be
address@hidden organized around what the user wants to do, not
address@hidden organized around CVS commands.
address@hidden
address@hidden Note that many users do expect a manual which is
address@hidden organized by command. At least some users do.
address@hidden One good addition to the "organized by command"
address@hidden section (if any) would be "see also" links.
address@hidden The awk manual might be a good example; it has a
address@hidden reference manual which is more verbose than Invoking
address@hidden CVS but probably somewhat less verbose than CVS
address@hidden Commands.
+
address@hidden
+* Structure:: Overall structure of CVS commands
+* Exit status:: Indicating CVS's success or failure
+* ~/.cvsrc:: Default options with the ~/.cvsrc file
+* Global options:: Options you give to the left of cvs_command
+* Common options:: Options you give to the right of cvs_command
+* Date input formats:: Acceptable formats for date specifications
+* admin:: Administration
+* annotate:: What revision modified each line of a file?
+* checkout:: Checkout sources for editing
+* commit:: Check files into the repository
+* diff:: Show differences between revisions
+* export:: Export sources from CVS, similar to checkout
+* history:: Show status of files and users
+* import:: Import sources into CVS, using vendor branches
+* log:: Show log messages for files
+* ls & rls:: List files in the repository
+* rdiff:: 'patch' format diffs between releases
+* release:: Indicate that a directory is no longer in use
+* server & pserver:: Act as a server for a client on stdin/stdout
+* update:: Bring work tree in sync with repository
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Structure
address@hidden Overall structure of CVS commands
address@hidden Structure
address@hidden CVS command structure
address@hidden Command structure
address@hidden Format of CVS commands
+
+The overall format of all @sc{cvs} commands is:
+
address@hidden
+cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
address@hidden example
+
address@hidden @code
address@hidden cvs
+The name of the @sc{cvs} program.
+
address@hidden cvs_options
+Some options that affect all sub-commands of @sc{cvs}. These are
+described below.
+
address@hidden 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 @samp{cvs_command}: @samp{cvs -H} elicits a
+list of available commands, and @samp{cvs -v} displays version
+information on @sc{cvs} itself.
+
address@hidden command_options
+Options that are specific for the command.
+
address@hidden command_args
+Arguments to the commands.
address@hidden table
+
+There is unfortunately some confusion between
address@hidden and @code{command_options}.
+When given as a @code{cvs_option}, some options only
+affect some of the commands. When given as a
address@hidden it may have a different meaning, and
+be accepted by more commands. In other words, do not
+take the above categorization too seriously. Look at
+the documentation instead.
+
address@hidden Exit status
address@hidden CVS's exit status
address@hidden Exit status, of CVS
+
address@hidden can indicate to the calling environment whether it
+succeeded or failed by setting its @dfn{exit status}.
+The exact way of testing the exit status will vary from
+one operating system to another. For example in a unix
+shell script the @samp{$?} variable will be 0 if the
+last command returned a successful exit status, or
+greater than 0 if the exit status indicated failure.
+
+If @sc{cvs} is successful, it returns a successful status;
+if there is an error, it prints an error message and
+returns a failure status. The one exception to this is
+the @code{cvs diff} command. It will return a
+successful status if it found no differences, or a
+failure status if there were differences or if there
+was an error. Because this behavior provides no good
+way to detect errors, in the future it is possible that
address@hidden diff} will be changed to behave like the
+other @sc{cvs} commands.
address@hidden It might seem like checking whether cvs -q diff
address@hidden produces empty or non-empty output can tell whether
address@hidden there were differences or not. But it seems like
address@hidden there are cases with output but no differences
address@hidden (testsuite basica-8b). It is not clear to me how
address@hidden useful it is for a script to be able to check
address@hidden whether there were differences.
address@hidden FIXCVS? In previous versions of CVS, cvs diff
address@hidden returned 0 for no differences, 1 for differences, or
address@hidden 2 for errors. Is this behavior worth trying to
address@hidden bring back (but what does it mean for VMS?)?
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden ~/.cvsrc
address@hidden Default options and the ~/.cvsrc file
address@hidden .cvsrc file
address@hidden Option defaults
+
+There are some @code{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
address@hidden support, actually) is that many people find the
+default output of the @samp{diff} command to be very
+hard to read, and that either context diffs or unidiffs
+are much easier to understand.
+
+The @file{~/.cvsrc} file is a way that you can add
+default options to @code{cvs_commands} within cvs,
+instead of relying on aliases or other shell scripts.
+
+The format of the @file{~/.cvsrc} file is simple. The
+file is searched for a line that begins with the same
+name as the @code{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 @emph{before} any
+options from the command line.
+
+If a command has two names (e.g., @code{checkout} and
address@hidden), 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
address@hidden/.cvsrc} file:
+
address@hidden
+log -N
+diff -uN
+rdiff -u
+update -Pd
+checkout -P
+release -d
address@hidden example
+
address@hidden
+the command @samp{cvs checkout foo} would have the
address@hidden option added to the arguments, as well as
address@hidden co foo}.
+
+With the example file above, the output from @samp{cvs
+diff foobar} will be in unidiff format. @samp{cvs diff
+-c foobar} will provide context diffs, as usual.
+Getting "old" format diffs would be slightly more
+complicated, because @code{diff} doesn't have an option
+to specify use of the "old" format, so you would need
address@hidden -f diff foobar}.
+
+In place of the command name you can use @code{cvs} to
+specify global options (@pxref{Global options}). For
+example the following line in @file{.cvsrc}
+
address@hidden
+cvs -z6
address@hidden example
+
address@hidden
+causes @sc{cvs} to use compression level 6.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Global options
address@hidden Global options
address@hidden Options, global
address@hidden Global options
address@hidden Left-hand options
+
+The available @samp{cvs_options} (that are given to the
+left of @samp{cvs_command}) are:
+
address@hidden @code
address@hidden address@hidden
+May be invoked multiple times to specify one legal @sc{cvsroot} directory with
+each invocation. Also causes CVS to preparse the configuration file for each
+specified root, which can be useful when configuring write proxies, See
address@hidden authentication server} & @ref{Write proxies}.
+
address@hidden Authentication, stream
address@hidden Stream authentication
address@hidden -a
+Authenticate all communication between the client and
+the server. Only has an effect on the @sc{cvs} client.
+As of this writing, this is only implemented when using
+a GSSAPI connection (@pxref{GSSAPI authenticated}).
+Authentication prevents certain sorts of attacks
+involving hijacking the active @sc{tcp} connection.
+Enabling authentication does not enable encryption.
+
address@hidden RCSBIN, overriding
address@hidden Overriding RCSBIN
address@hidden -b @var{bindir}
+In @sc{cvs} 1.9.18 and older, this specified that
address@hidden programs are in the @var{bindir} directory.
+Current versions of @sc{cvs} do not run @sc{rcs}
+programs; for compatibility this option is accepted,
+but it does nothing.
+
address@hidden TMPDIR, environment variable
address@hidden temporary file directory, set via command line
address@hidden temporary file directory, set via environment variable
address@hidden temporary file directory, set via config
address@hidden temporary files, location of
address@hidden -T @var{tempdir}
+Use @var{tempdir} as the directory where temporary files are
+located.
+
+The @sc{cvs} client and server store temporary files in a temporary directory.
+The path to this temporary directory is set via, in order of precedence:
+
address@hidden @bullet
address@hidden
+The argument to the global @samp{-T} option.
+
address@hidden
+The value set for @code{TmpDir} in the config file (server only -
address@hidden).
+
address@hidden
+The contents of the @code{$TMPDIR} environment variable (@code{%TMPDIR%} on
+Windows - @pxref{Environment variables}).
+
address@hidden
+/tmp
+
address@hidden itemize
+
+Temporary directories should always be specified as an absolute pathname.
+When running a CVS client, @samp{-T} affects only the local process;
+specifying @samp{-T} for the client has no effect on the server and
+vice versa.
+
address@hidden CVSROOT, overriding
address@hidden Overriding CVSROOT
address@hidden -d @var{cvs_root_directory}
+Use @var{cvs_root_directory} as the root directory
+pathname of the repository. Overrides the setting of
+the @code{$CVSROOT} environment variable. @xref{Repository}.
+
address@hidden EDITOR, overriding
address@hidden Overriding EDITOR
address@hidden -e @var{editor}
+Use @var{editor} to enter revision log information. Overrides the
+setting of the @code{$CVSEDITOR} and @code{$EDITOR}
+environment variables. For more information, see
address@hidden your changes}.
+
address@hidden -f
+Do not read the @file{~/.cvsrc} file. This
+option is most often used because of the
+non-orthogonality of the @sc{cvs} option set. For
+example, the @samp{cvs log} option @samp{-N} (turn off
+display of tag names) does not have a corresponding
+option to turn the display on. So if you have
address@hidden in the @file{~/.cvsrc} entry for @samp{log},
+you may need to use @samp{-f} to show the tag names.
+
address@hidden -H
address@hidden --help
+Display usage information about the specified @samp{cvs_command}
+(but do not actually execute the command). If you don't specify
+a command name, @samp{cvs -H} displays overall help for
address@hidden, including a list of other help options.
address@hidden It seems to me it is better to document it this way
address@hidden rather than trying to update this documentation
address@hidden every time that we add a --help-foo option. But
address@hidden perhaps that is confusing...
+
address@hidden Read-only repository mode
address@hidden -R
+Turns on read-only repository mode. This allows one to check out from a
+read-only repository, such as within an anoncvs server, or from a @sc{cd-rom}
+repository.
+
+Same effect as if the @code{CVSREADONLYFS} environment
+variable is set. Using @samp{-R} can also considerably
+speed up checkouts over NFS.
+
address@hidden Read-only mode
address@hidden -n
+Do not change any files. Attempt to execute the
address@hidden, but only to issue reports; do not remove,
+update, or merge any existing files, or create any new files.
+
+Note that @sc{cvs} will not necessarily produce exactly
+the same output as without @samp{-n}. In some cases
+the output will be the same, but in other cases
address@hidden will skip some of the processing that would
+have been required to produce the exact same output.
+
address@hidden -Q
+Cause the command to be really quiet; the command will only
+generate output for serious problems.
+
address@hidden -q
+Cause the command to be somewhat quiet; informational messages,
+such as reports of recursion through subdirectories, are
+suppressed.
+
address@hidden Read-only files, and -r
address@hidden -r
+Make new working files read-only. Same effect
+as if the @code{$CVSREAD} environment variable is set
+(@pxref{Environment variables}). The default is to
+make working files writable, unless watches are on
+(@pxref{Watches}).
+
address@hidden -s @address@hidden
+Set a user variable (@pxref{Variables}).
+
address@hidden Trace
address@hidden -t
+Trace program execution; display messages showing the steps of
address@hidden activity. Particularly useful with @samp{-n} to explore the
+potential impact of an unfamiliar command.
+
address@hidden -v
address@hidden --version
+Display version and copyright information for @sc{cvs}.
+
address@hidden CVSREAD, overriding
address@hidden Overriding CVSREAD
address@hidden -w
+Make new working files read-write. Overrides the
+setting of the @code{$CVSREAD} environment variable.
+Files are created read-write by default, unless @code{$CVSREAD} is
+set or @samp{-r} is given.
address@hidden Note that -w only overrides -r and CVSREAD; it has
address@hidden no effect on files which are readonly because of
address@hidden "cvs watch on". My guess is that is the way it
address@hidden should be (or should "cvs -w get" on a watched file
address@hidden be the same as a get and a cvs edit?), but I'm not
address@hidden completely sure whether to document it this way.
+
address@hidden -x
address@hidden Encryption
+Encrypt all communication between the client and the
+server. Only has an effect on the @sc{cvs} client. As
+of this writing, this is only implemented when using a
+GSSAPI connection (@pxref{GSSAPI authenticated}) or a
+Kerberos connection (@pxref{Kerberos authenticated}).
+Enabling encryption implies that message traffic is
+also authenticated. Encryption support is not
+available by default; it must be enabled using a
+special configure option, @file{--enable-encryption},
+when you build @sc{cvs}.
+
address@hidden -z @var{level}
address@hidden Compression
address@hidden Gzip
+Request compression @var{level} for network traffic.
address@hidden interprets @var{level} identically to the @code{gzip} program.
+Valid levels are 1 (high speed, low compression) to
+9 (low speed, high compression), or 0 to disable
+compression (the default). Data sent to the server will
+be compressed at the requested level and the client will request
+the server use the same compression level for data returned. The
+server will use the closest level allowed by the server administrator to
+compress returned data. This option only has an effect when passed to
+the @sc{cvs} client.
address@hidden table
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Common options
address@hidden Common command options
address@hidden Common options
address@hidden Right-hand options
+
+This section describes the @samp{command_options} that
+are available across several @sc{cvs} commands. These
+options are always given to the right of
address@hidden 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 @sc{cvs} command to the other).
+
address@hidden @samp{history} command is an exception; it supports
+many options that conflict even with these standard options.}
+
address@hidden @code
address@hidden Dates
address@hidden Time
address@hidden Specifying dates
address@hidden -D @var{date_spec}
+Use the most recent revision no later than @var{date_spec}.
address@hidden is a single argument, a date description
+specifying a date in the past.
+
+The specification is @dfn{sticky} when you use it to make a
+private copy of a source file; that is, when you get a working
+file using @samp{-D}, @sc{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, @pxref{Sticky tags}).
+
address@hidden is available with the @code{annotate}, @code{checkout},
address@hidden, @code{export}, @code{history}, @code{ls},
address@hidden, @code{rls}, @code{rtag}, @code{tag}, and @code{update} commands.
+(The @code{history} command uses this option in a
+slightly different way; @pxref{history options}).
+
+For a complete description of the date formats accepted by @sc{cvs},
address@hidden input formats}.
address@hidden What other formats should we accept? I don't want
address@hidden to start accepting a whole mess of non-standard
address@hidden new formats (there are a lot which are in wide use in
address@hidden one context or another), but practicality does
address@hidden dictate some level of flexibility.
address@hidden * POSIX.2 (e.g. touch, ls output, date) and other
address@hidden POSIX and/or de facto unix standards (e.g. at). The
address@hidden practice here is too inconsistent to be of any use.
address@hidden * VMS dates. This is not a formal standard, but
address@hidden there is a published specification (see SYS$ASCTIM
address@hidden and SYS$BINTIM in the _VMS System Services Reference
address@hidden Manual_), it is implemented consistently in VMS
address@hidden utilities, and VMS users will expect CVS running on
address@hidden VMS to support this format (and if we're going to do
address@hidden that, better to make CVS support it on all
address@hidden platforms. Maybe).
address@hidden
address@hidden One more note: In output, CVS should consistently
address@hidden use one date format, and that format should be one that
address@hidden it accepts in input as well. The former isn't
address@hidden really true (see survey below), and I'm not
address@hidden sure that either of those formats is accepted in
address@hidden input.
address@hidden
address@hidden cvs log
address@hidden current 1996/01/02 13:45:31
address@hidden Internet 02 Jan 1996 13:45:31 UT
address@hidden ISO 1996-01-02 13:45:31
address@hidden cvs ann
address@hidden current 02-Jan-96
address@hidden Internet-like 02 Jan 96
address@hidden ISO 96-01-02
address@hidden cvs status
address@hidden current Tue Jun 11 02:54:53 1996
address@hidden Internet [Tue,] 11 Jun 1996 02:54:53
address@hidden ISO 1996-06-11 02:54:53
address@hidden note: date possibly should be omitted entirely for
address@hidden other reasons.
address@hidden cvs editors
address@hidden current Tue Jun 11 02:54:53 1996 GMT
address@hidden cvs history
address@hidden current 06/11 02:54 +0000
address@hidden any others?
address@hidden There is a good chance the proper solution has to
address@hidden involve at least some level of letting the user
address@hidden decide which format (with the default being the
address@hidden formats CVS has always used; changing these might be
address@hidden _very_ disruptive since scripts may very well be
address@hidden parsing them).
address@hidden
address@hidden Another random bit of prior art concerning dates is
address@hidden the strptime function which takes templates such as
address@hidden "%m/%d/%y", and apparent a variant of getdate()
address@hidden which also honors them. See
address@hidden X/Open CAE Specification, System Interfaces and
address@hidden Headers Issue 4, Version 2 (September 1994), in the
address@hidden entry for getdate() on page 231
+
+Remember to quote the argument to the @samp{-D}
+flag so that your shell doesn't interpret spaces as
+argument separators. A command using the @samp{-D}
+flag can look like this:
+
address@hidden
+$ cvs diff -D "1 hour ago" cvs.texinfo
address@hidden example
+
address@hidden Forcing a tag match
address@hidden -f
+When you specify a particular date or tag to @sc{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} 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).
+
+Note that even with @samp{-f}, a tag that you specify
+must exist (that is, in some file, not necessary in
+every file). This is so that @sc{cvs} will continue to
+give an error if you mistype a tag name.
+
address@hidden 800
address@hidden is available with these commands:
address@hidden, @code{checkout}, @code{export},
address@hidden, @code{rtag}, and @code{update}.
+
address@hidden: The @code{commit} and @code{remove}
+commands also have a
address@hidden option, but it has a different behavior for
+those commands. See @ref{commit options}, and
address@hidden files}.}
+
address@hidden -k @var{kflag}
+Override the default processing of RCS keywords other than
address@hidden @xref{Keyword substitution}, for the meaning of
address@hidden Used with the @code{checkout} and @code{update}
+commands, your @var{kflag} specification is
address@hidden; that is, when you use this option
+with a @code{checkout} or @code{update} command,
address@hidden associates your selected @var{kflag} with any files
+it operates on, and continues to use that @var{kflag} with future
+commands on the same files until you specify otherwise.
+
+The @samp{-k} option is available with the @code{add},
address@hidden, @code{diff}, @code{export}, @code{import},
address@hidden, and @code{update} commands.
+
address@hidden: Prior to CVS version 1.12.2, the @samp{-k} flag
+overrode the @samp{-kb} indication for a binary file. This could
+sometimes corrupt binary files. @xref{Merging and keywords}, for
+more.}
+
address@hidden -l
+Local; run only in current working directory, rather than
+recursing through subdirectories.
+
+Available with the following commands: @code{annotate}, @code{checkout},
address@hidden, @code{diff}, @code{edit}, @code{editors}, @code{export},
address@hidden, @code{rdiff}, @code{remove}, @code{rtag},
address@hidden, @code{tag}, @code{unedit}, @code{update}, @code{watch},
+and @code{watchers}.
+
address@hidden Editor, avoiding invocation of
address@hidden Avoiding editor invocation
address@hidden -m @var{message}
+Use @var{message} as log information, instead of
+invoking an editor.
+
+Available with the following commands: @code{add},
address@hidden and @code{import}.
+
address@hidden -n
+Do not run any tag program. (A program can be
+specified to run in the modules
+database (@pxref{modules}); this option bypasses it).
+
address@hidden is not the same as the @samp{cvs -n}
+program option, which you can specify to the left of a cvs command!}
+
+Available with the @code{checkout}, @code{export},
+and @code{rtag} commands.
+
address@hidden -P
+Prune empty directories. See @ref{Removing directories}.
+
address@hidden -p
+Pipe the files retrieved from the repository to standard output,
+rather than writing them in the current directory. Available
+with the @code{checkout} and @code{update} commands.
+
address@hidden -R
+Process directories recursively. This is the default for all @sc{cvs}
+commands, with the exception of @code{ls} & @code{rls}.
+
+Available with the following commands: @code{annotate}, @code{checkout},
address@hidden, @code{diff}, @code{edit}, @code{editors}, @code{export},
address@hidden, @code{rdiff}, @code{remove}, @code{rls}, @code{rtag},
address@hidden, @code{tag}, @code{unedit}, @code{update}, @code{watch},
+and @code{watchers}.
+
address@hidden -r @var{tag}
address@hidden -r @var{tag}[:@var{date}]
address@hidden HEAD, special tag
address@hidden BASE, special tag
+Use the revision specified by the @var{tag} argument (and the @var{date}
+argument for the commands which accept it) instead of the
+default @dfn{head} revision. As well as arbitrary tags defined
+with the @code{tag} or @code{rtag} command, two special tags are
+always available: @samp{HEAD} refers to the most recent version
+available in the repository, and @samp{BASE} refers to the
+revision you last checked out into the current working directory.
+
address@hidden FIXME: What does HEAD really mean? I believe that
address@hidden the current answer is the head of the default branch
address@hidden for all cvs commands except diff. For diff, it
address@hidden seems to be (a) the head of the trunk (or the default
address@hidden branch?) if there is no sticky tag, (b) the head of the
address@hidden branch for the sticky tag, if there is a sticky tag.
address@hidden (b) is ugly as it differs
address@hidden from what HEAD means for other commands, but people
address@hidden and/or scripts are quite possibly used to it.
address@hidden See "head" tests in sanity.sh.
address@hidden Probably the best fix is to introduce two new
address@hidden special tags, ".thead" for the head of the trunk,
address@hidden and ".bhead" for the head of the current branch.
address@hidden Then deprecate HEAD. This has the advantage of
address@hidden not surprising people with a change to HEAD, and a
address@hidden side benefit of also phasing out the poorly-named
address@hidden HEAD (see discussion of reserved tag names in node
address@hidden "Tags"). Of course, .thead and .bhead should be
address@hidden carefully implemented (with the implementation the
address@hidden same for "diff" as for everyone else), test cases
address@hidden written (similar to the ones in "head"), new tests
address@hidden cases written for things like default branches, &c.
+
+The tag specification is sticky when you use this
+with @code{checkout} or @code{update} to make your own
+copy of a file: @sc{cvs} remembers the tag and continues to use it on
+future update commands, until you specify otherwise (for more information
+on sticky tags/dates, @pxref{Sticky tags}).
+
+The tag can be either a symbolic or numeric tag, as
+described in @ref{Tags}, or the name of a branch, as
+described in @ref{Branching and merging}.
+When @var{tag} is the name of a
+branch, some commands accept the optional @var{date} argument to specify
+the revision as of the given date on the branch.
+When a command expects a specific revision,
+the name of a branch is interpreted as the most recent
+revision on that branch.
+
+Specifying the @samp{-q} global option along with the
address@hidden command option is often useful, to suppress
+the warning messages when the @sc{rcs} file
+does not contain the specified tag.
+
address@hidden is not the same as the overall @samp{cvs -r} option,
+which you can specify to the left of a @sc{cvs} command!}
+
address@hidden @var{tag}} is available with the @code{commit} and @code{history}
+commands.
+
address@hidden @var{tag}[:@var{date}]} is available with the @code{annotate},
address@hidden, @code{diff}, @code{export}, @code{rdiff}, @code{rtag},
+and @code{update} commands.
+
address@hidden -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 @file{.cvswrappers} file.
+Available with the following commands: @code{import},
+and @code{update}.
+
address@hidden table
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden getdate-cvs.texi
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden admin
address@hidden admin---Administration
address@hidden Admin (subcommand)
+
address@hidden @bullet
address@hidden
+Requires: repository, working directory.
address@hidden
+Changes: repository.
address@hidden
+Synonym: rcs
address@hidden itemize
+
+This is the @sc{cvs} interface to assorted
+administrative facilities. Some of them have
+questionable usefulness for @sc{cvs} but exist for
+historical purposes. Some of the questionable options
+are likely to disappear in the future. This command
address@hidden work recursively, so extreme care should be
+used.
+
address@hidden cvsadmin
address@hidden UserAdminOptions, in CVSROOT/config
+On unix, if there is a group named @code{cvsadmin},
+only members of that group can run @code{cvs admin}
+commands, except for those specified using the
address@hidden configuration option in the
address@hidden/config} file. Options specified using
address@hidden can be run by any user. See
address@hidden for more on @code{UserAdminOptions}.
+
+The @code{cvsadmin} group should exist on the server,
+or any system running the non-client/server @sc{cvs}.
+To disallow @code{cvs admin} for all users, create a
+group with no users in it. On NT, the @code{cvsadmin}
+feature does not exist and all users
+can run @code{cvs admin}.
+
address@hidden
+* admin options:: admin options
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden admin options
address@hidden admin options
+
+Some of these options have questionable usefulness for
address@hidden but exist for historical purposes. Some even
+make it impossible to use @sc{cvs} until you undo the
+effect!
+
address@hidden @code
address@hidden address@hidden
+Might not work together with @sc{cvs}. Append the
+access list of @var{oldfile} to the access list of the
address@hidden file.
+
address@hidden address@hidden
+Might not work together with @sc{cvs}. Append the
+login names appearing in the comma-separated list
address@hidden to the access list of the @sc{rcs} file.
+
address@hidden address@hidden
+Set the default branch to @var{rev}. In @sc{cvs}, you
+normally do not manipulate default branches; sticky
+tags (@pxref{Sticky tags}) are a better way to decide
+which branch you want to work on. There is one reason
+to run @code{cvs admin -b}: to revert to the vendor's
+version when using vendor branches (@pxref{Reverting
+local changes}).
+There can be no space between @samp{-b} and its argument.
address@hidden Hmm, we don't document the usage where rev is
address@hidden omitted. Maybe that usage can/should be deprecated
address@hidden (and replaced with -bHEAD or something?) (so we can toss
address@hidden the optional argument). Note that -bHEAD does not
address@hidden work, as of 17 Sep 1997, but probably will once "cvs
address@hidden admin" is internal to CVS.
+
address@hidden Comment leader
address@hidden address@hidden
+Sets the comment leader to @var{string}. The comment
+leader is not used by current versions of @sc{cvs} or
address@hidden 5.7. Therefore, you can almost surely not
+worry about it. @xref{Keyword substitution}.
+
address@hidden address@hidden
+Might not work together with @sc{cvs}. Erase the login
+names appearing in the comma-separated list
address@hidden from the access list of the RCS file. If
address@hidden is omitted, erase the entire access list.
+There can be no space between @samp{-e} and its argument.
+
address@hidden -I
+Run interactively, even if the standard input is not a
+terminal. This option does not work with the
+client/server @sc{cvs} and is likely to disappear in
+a future release of @sc{cvs}.
+
address@hidden -i
+Useless with @sc{cvs}. This creates and initializes a
+new @sc{rcs} file, without depositing a revision. With
address@hidden, add files with the @code{cvs add} command
+(@pxref{Adding files}).
+
address@hidden address@hidden
+Set the default keyword
+substitution to @var{subst}. @xref{Keyword
+substitution}. Giving an explicit @samp{-k} option to
address@hidden update}, @code{cvs export}, or @code{cvs
+checkout} overrides this default.
+
address@hidden address@hidden
+Lock the revision with number @var{rev}. If a branch
+is given, lock the latest revision on that branch. If
address@hidden is omitted, lock the latest revision on the
+default branch. There can be no space between
address@hidden and its argument.
+
+This can be used in conjunction with the
address@hidden script in the @file{contrib}
+directory of the @sc{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 @file{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).
+
address@hidden -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 @sc{cvs}, strict locking must be
+set; see the discussion under the @samp{-l} option above.
+
address@hidden Changing a log message
address@hidden Replacing a log message
address@hidden Correcting a log message
address@hidden Fixing a log message
address@hidden Log message, correcting
address@hidden address@hidden:@var{msg}
+Replace the log message of revision @var{rev} with
address@hidden
+
address@hidden The rcs -M option, to suppress sending mail, has never been
address@hidden documented as a cvs admin option.
+
address@hidden address@hidden:address@hidden
+Act like @samp{-n}, except override any previous
+assignment of @var{name}. For use with magic branches,
+see @ref{Magic branch numbers}.
+
address@hidden address@hidden:address@hidden
+Associate the symbolic name @var{name} with the branch
+or revision @var{rev}. It is normally better to use
address@hidden tag} or @samp{cvs rtag} instead. Delete the
+symbolic name if both @samp{:} and @var{rev} are
+omitted; otherwise, print an error message if
address@hidden is already associated with another number.
+If @var{rev} is symbolic, it is expanded before
+association. A @var{rev} consisting of a branch number
+followed by a @samp{.} stands for the current latest
+revision in the branch. A @samp{:} with an empty
address@hidden stands for the current latest revision on the
+default branch, normally the trunk. For example,
address@hidden admin address@hidden:} associates @var{name} with the
+current latest revision of all the RCS files;
+this contrasts with @samp{cvs admin address@hidden:$} which
+associates @var{name} with the revision numbers
+extracted from keyword strings in the corresponding
+working files.
+
address@hidden Deleting revisions
address@hidden Outdating revisions
address@hidden Saving space
address@hidden address@hidden
+Deletes (@dfn{outdates}) the revisions given by
address@hidden
+
+Note that this command can be quite dangerous unless
+you know @emph{exactly} what you are doing (for example
+see the warnings below about how the
address@hidden:@var{rev2} syntax is confusing).
+
+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!
+If you delete different revisions than you planned,
+either due to carelessness or (heaven forbid) a @sc{cvs}
+bug, there is no opportunity to correct the error
+before the revisions are deleted. It probably would be
+a good idea to experiment on a copy of the repository
+first.
+
+Specify @var{range} in one of the following ways:
+
address@hidden @code
address@hidden @var{rev1}::@var{rev2}
+Collapse all revisions between rev1 and rev2, so that
address@hidden only stores the differences associated with going
+from rev1 to rev2, not intermediate steps. For
+example, after @samp{-o 1.3::1.5} one can retrieve
+revision 1.3, revision 1.5, or the differences to get
+from 1.3 to 1.5, but not the revision 1.4, or the
+differences between 1.3 and 1.4. Other examples:
address@hidden 1.3::1.4} and @samp{-o 1.3::1.3} have no
+effect, because there are no intermediate revisions to
+remove.
+
address@hidden ::@var{rev}
+Collapse revisions between the beginning of the branch
+containing @var{rev} and @var{rev} itself. The
+branchpoint and @var{rev} are left intact. For
+example, @samp{-o ::1.3.2.6} deletes revision 1.3.2.1,
+revision 1.3.2.5, and everything in between, but leaves
+1.3 and 1.3.2.6 intact.
+
address@hidden @var{rev}::
+Collapse revisions between @var{rev} and the end of the
+branch containing @var{rev}. Revision @var{rev} is
+left intact but the head revision is deleted.
+
address@hidden @var{rev}
+Delete the revision @var{rev}. For example, @samp{-o
+1.3} is equivalent to @samp{-o 1.2::1.4}.
+
address@hidden @var{rev1}:@var{rev2}
+Delete the revisions from @var{rev1} to @var{rev2},
+inclusive, on the same branch. One will not be able to
+retrieve @var{rev1} or @var{rev2} or any of the
+revisions in between. For example, the command
address@hidden admin -oR_1_01:R_1_02 .} is rarely useful.
+It means to delete revisions up to, and including, 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
address@hidden 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! In most cases you want to
+specify @var{rev1}::@var{rev2} instead.
+
address@hidden :@var{rev}
+Delete revisions from the beginning of the
+branch containing @var{rev} up to and including
address@hidden
+
address@hidden @var{rev}:
+Delete revisions from revision @var{rev}, including
address@hidden itself, to the end of the branch containing
address@hidden
address@hidden table
+
+None of the revisions to be deleted may have
+branches or locks.
+
+If any of the revisions to be deleted have symbolic
+names, and one specifies one of the @samp{::} syntaxes,
+then @sc{cvs} will give an error and not delete any
+revisions. If you really want to delete both the
+symbolic names and the revisions, first delete the
+symbolic names with @code{cvs tag -d}, then run
address@hidden admin -o}. If one specifies the
address@hidden::} syntaxes, then @sc{cvs} will delete the
+revisions but leave the symbolic names pointing to
+nonexistent revisions. This behavior is preserved for
+compatibility with previous versions of @sc{cvs}, but
+because it isn't very useful, in the future it may
+change to be like the @samp{::} case.
+
+Due to the way @sc{cvs} handles branches @var{rev}
+cannot be specified symbolically if it is a branch.
address@hidden branch numbers}, for an explanation.
address@hidden FIXME: is this still true? I suspect not.
+
+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 (@pxref{Merging two revisions}).
+
address@hidden -q
+Run quietly; do not print diagnostics.
+
address@hidden address@hidden:@var{rev}]
+Useful with @sc{cvs}. Set the state attribute of the
+revision @var{rev} to @var{state}. If @var{rev} is a
+branch number, assume the latest revision on that
+branch. If @var{rev} is omitted, assume the latest
+revision on the default branch. Any identifier is
+acceptable for @var{state}. A useful set of states is
address@hidden (for experimental), @samp{Stab} (for
+stable), and @samp{Rel} (for released). By default,
+the state of a new revision is set to @samp{Exp} when
+it is created. The state is visible in the output from
address@hidden log} (@pxref{log}), and in the
address@hidden@splitrcskeyword{Log}$} and @address@hidden keywords
+(@pxref{Keyword substitution}). Note that @sc{cvs}
+uses the @code{dead} state for its own purposes (@pxref{Attic}); to
+take a file to or from the @code{dead} state use
+commands like @code{cvs remove} and @code{cvs add}
+(@pxref{Adding and removing}), not @code{cvs admin -s}.
+
address@hidden address@hidden
+Useful with @sc{cvs}. Write descriptive text from the
+contents of the named @var{file} into the RCS file,
+deleting the existing text. The @var{file} pathname
+may not begin with @samp{-}. The descriptive text can be seen in the
+output from @samp{cvs log} (@pxref{log}).
+There can be no space between @samp{-t} and its argument.
+
+If @var{file} is omitted,
+obtain the text from standard input, terminated by
+end-of-file or by a line containing @samp{.} by itself.
+Prompt for the text if interaction is possible; see
address@hidden
+
address@hidden address@hidden
+Similar to @address@hidden Write descriptive text
+from the @var{string} into the @sc{rcs} file, deleting
+the existing text.
+There can be no space between @samp{-t} and its argument.
+
address@hidden The rcs -T option, do not update last-mod time for
address@hidden minor changes, has never been documented as a
address@hidden cvs admin option.
+
address@hidden -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 @sc{cvs}, strict locking must be
+set; see the discussion under the @samp{-l} option
+above.
+
address@hidden address@hidden
+See the option @samp{-l} above, for a discussion of
+using this option with @sc{cvs}. Unlock the revision
+with number @var{rev}. If a branch is given, unlock
+the latest revision on that branch. If @var{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 the original locker to be sent a @code{commit}
+notification (@pxref{Getting Notified}).
+There can be no space between @samp{-u} and its argument.
+
address@hidden address@hidden
+In previous versions of @sc{cvs}, this option meant to
+write an @sc{rcs} file which would be acceptable to
address@hidden version @var{n}, but it is now obsolete and
+specifying it will produce an error.
address@hidden Note that -V without an argument has never been
address@hidden documented as a cvs admin option.
+
address@hidden address@hidden
+In previous versions of @sc{cvs}, this was documented
+as a way of specifying the names of the @sc{rcs}
+files. However, @sc{cvs} has always required that the
address@hidden files used by @sc{cvs} end in @samp{,v}, so
+this option has never done anything useful.
+
address@hidden List long options after the short options
address@hidden --execute
+On unix systems, when @sc{cvs} adds a new file to a repository,
+the execute bits of the file are applied to the @sc{rcs} file
+and are thus preserved. This can be useful for shell scripts
+or other files that you want to be executable when they are
+later checked out (saves you from doing chmod +x to alter the
+file permissions).
+This option can turn on the execute bits for repository files
+that where originally added without them (or were made
+non-executable with the --no-execute option).
+
address@hidden --no-execute
+This option turns off the execute bits from repository files,
+(useful for files that where originally added as executables or
+were made executable with the --execute option) when you want to
+avoid those files from being executable on subsequent checkouts.
+
address@hidden The rcs -z option, to specify the timezone, has
address@hidden never been documented as a cvs admin option.
address@hidden table
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden annotate
address@hidden annotate---What revision modified each line of a file?
address@hidden annotate (subcommand)
+
address@hidden @bullet
address@hidden
+Synopsis: annotate [options] address@hidden
address@hidden
+Requires: repository.
address@hidden
+Changes: nothing.
address@hidden itemize
+
+For each file in @var{files}, print the head revision
+of the trunk, together with information on the last
+modification for each line.
+
address@hidden
+* annotate options:: annotate options
+* annotate example:: annotate example
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden annotate options
address@hidden annotate options
+
+These standard options are supported by @code{annotate}
+(@pxref{Common options}, for a complete description of
+them):
+
address@hidden @code
address@hidden -l
+Local directory only, no recursion.
+
address@hidden -R
+Process directories recursively.
+
address@hidden -f
+Use head revision if tag/date not found.
+
address@hidden -F
+Annotate binary files.
+
address@hidden -r @var{tag}[:@var{date}]
+Annotate file as of specified revision/tag or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{Common options}.
+
address@hidden -D @var{date}
+Annotate file as of specified date.
+
address@hidden -w @var{width}
+Modify the width of the username field (default 8).
+The specified @var{width} must be greater than 0 and less than 80.
address@hidden table
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden annotate example
address@hidden annotate example
+
+For example:
+
address@hidden
+$ cvs annotate ssfile
+Annotations for ssfile
+***************
+1.1 (mary 27-Mar-96): ssfile line 1
+1.2 (joe 28-Mar-96): ssfile line 2
address@hidden example
+
+The file @file{ssfile} currently contains two lines.
+The @code{ssfile line 1} line was checked in by
address@hidden on March 27. Then, on March 28, @code{joe}
+added a line @code{ssfile line 2}, without modifying
+the @code{ssfile line 1} line. This report doesn't
+tell you anything about lines which have been deleted
+or replaced; you need to use @code{cvs diff} for that
+(@pxref{diff}).
+
+The options to @code{cvs annotate} are listed in
address@hidden CVS}, and can be used to select the files
+and revisions to annotate. The options are described
+in more detail there and in @ref{Common options}.
+
address@hidden FIXME: maybe an example using the options? Just
address@hidden what it means to select a revision might be worth a
address@hidden few words of explanation ("you want to see who
address@hidden changed this line *before* 1.4"...).
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden checkout
address@hidden checkout---Check out sources for editing
address@hidden checkout (subcommand)
address@hidden co (subcommand)
+
address@hidden @bullet
address@hidden
+Synopsis: checkout [options] address@hidden
address@hidden
+Requires: repository.
address@hidden
+Changes: working directory.
address@hidden
+Synonyms: co, get
address@hidden itemize
+
+Create or update a working directory containing copies of the
+source files specified by @var{modules}. You must execute
address@hidden before using most of the other @sc{cvs}
+commands, since most of them operate on your working
+directory.
+
+The @var{modules} 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} file.
address@hidden
address@hidden Needs an example, particularly of the non-"modules"
address@hidden case but probably of both.
+
address@hidden FIXME: this seems like a very odd place to introduce
address@hidden people to how CVS works. The bit about unreserved
address@hidden checkouts is also misleading as it depends on how
address@hidden things are set up.
+Depending on the modules you specify, @code{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 @code{checkout} is used to create
+directories. The top-level directory created is always
+added to the directory where @code{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
address@hidden will show the relative path leading to
+each file as it is extracted into your private work
+area (unless you specify the @samp{-Q} global option).
+
+The files created by @code{checkout} are created
+read-write, unless the @samp{-r} option to @sc{cvs}
+(@pxref{Global options}) is specified, the
address@hidden environment variable is specified
+(@pxref{Environment variables}), or a watch is in
+effect for that file (@pxref{Watches}).
+
+Note that running @code{checkout} on a directory that was already
+built by a prior @code{checkout} is also permitted.
+This is similar to specifying the @samp{-d} option
+to the @code{update} command in the sense that new
+directories that have been created in the repository
+will appear in your work area.
+However, @code{checkout} takes a module name whereas
address@hidden takes a directory name. Also
+to use @code{checkout} this way it must be run from the
+top level directory (where you originally ran
address@hidden from), so before you run
address@hidden to update an existing directory, don't
+forget to change your directory to the top level
+directory.
+
+For the output produced by the @code{checkout} command
+see @ref{update output}.
+
address@hidden
+* checkout options:: checkout options
+* checkout examples:: checkout examples
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden checkout options
address@hidden checkout options
+
+These standard options are supported by @code{checkout}
+(@pxref{Common options}, for a complete description of
+them):
+
address@hidden @code
address@hidden -D @var{date}
+Use the most recent revision no later than @var{date}.
+This option is sticky, and implies @samp{-P}. See
address@hidden tags}, for more information on sticky tags/dates.
+
address@hidden -f
+Only useful with the @samp{-D} or @samp{-r} flags. If no matching revision is
+found, retrieve the most recent revision (instead of ignoring the file).
+
address@hidden -k @var{kflag}
+Process keywords according to @var{kflag}. See
address@hidden substitution}.
+This option is sticky; future updates of
+this file in this working directory will use the same
address@hidden The @code{status} command can be viewed
+to see the sticky options. See @ref{Invoking CVS}, for
+more information on the @code{status} command.
+
address@hidden -l
+Local; run only in current working directory.
+
address@hidden -n
+Do not run any checkout program (as specified
+with the @samp{-o} option in the modules file;
address@hidden).
+
address@hidden -P
+Prune empty directories. See @ref{Moving directories}.
+
address@hidden -p
+Pipe files to the standard output.
+
address@hidden -R
+Checkout directories recursively. This option is on by default.
+
address@hidden -r @var{tag}[:@var{date}]
+Checkout the revision specified by @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. This option is sticky, and implies @samp{-P}.
+See @ref{Sticky tags}, for more information on sticky tags/dates. Also,
+see @ref{Common options}.
address@hidden table
+
+In addition to those, you can use these special command
+options with @code{checkout}:
+
address@hidden @code
address@hidden -A
+Reset any sticky tags, dates, or @samp{-k} options.
+See @ref{Sticky tags}, for more information on sticky tags/dates.
+
address@hidden -c
+Copy the module file, sorted, to the standard output,
+instead of creating or modifying any files or
+directories in your working directory.
+
address@hidden -d @var{dir}
+Create a directory called @var{dir} for the working
+files, instead of using the module name. In general,
+using this flag is equivalent to using @samp{mkdir
address@hidden; cd @var{dir}} followed by the checkout
+command without the @samp{-d} flag.
+
+There is an important exception, however. It is very
+convenient when checking out a single item to have the
+output appear in a directory that doesn't contain empty
+intermediate directories. In this case @emph{only},
address@hidden tries to ``shorten'' pathnames to avoid those empty
+directories.
+
+For example, given a module @samp{foo} that contains
+the file @samp{bar.c}, the command @samp{cvs co -d dir
+foo} will create directory @samp{dir} and place
address@hidden inside. Similarly, given a module
address@hidden which has subdirectory @samp{baz} wherein
+there is a file @samp{quux.c}, the command @samp{cvs co
+-d dir bar/baz} will create directory @samp{dir} and
+place @samp{quux.c} inside.
+
+Using the @samp{-N} flag will defeat this behavior.
+Given the same module definitions above, @samp{cvs co
+-N -d dir foo} will create directories @samp{dir/foo}
+and place @samp{bar.c} inside, while @samp{cvs co -N -d
+dir bar/baz} will create directories @samp{dir/bar/baz}
+and place @samp{quux.c} inside.
+
address@hidden -j @var{tag}
+With two @samp{-j} options, merge changes from the
+revision specified with the first @samp{-j} option to
+the revision specified with the second @samp{j} option,
+into the working directory.
+
+With one @samp{-j} option, merge changes from the
+ancestor revision to the revision specified with the
address@hidden 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} 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:
address@hidden@var{Symbolic_Tag}:@var{Date_Specifier}}.
+
address@hidden and merging}.
+
address@hidden -N
+Only useful together with @samp{-d @var{dir}}. With
+this option, @sc{cvs} will not ``shorten'' module paths
+in your working directory when you check out a single
+module. See the @samp{-d} flag for examples and a
+discussion.
+
address@hidden -s
+Like @samp{-c}, but include the status of all modules,
+and sort it by the status string. @xref{modules}, for
+info about the @samp{-s} option that is used inside the
+modules file to set the module status.
address@hidden table
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden checkout examples
address@hidden checkout examples
+
+Get a copy of the module @samp{tc}:
+
address@hidden
+$ cvs checkout tc
address@hidden example
+
+Get a copy of the module @samp{tc} as it looked one day
+ago:
+
address@hidden
+$ cvs checkout -D yesterday tc
address@hidden example
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden commit
address@hidden commit---Check files into the repository
address@hidden commit (subcommand)
+
address@hidden @bullet
address@hidden
+Synopsis: commit [-lRf] [-m 'log_message' |
+-F file] [-r revision] address@hidden
address@hidden
+Requires: working directory, repository.
address@hidden
+Changes: repository.
address@hidden
+Synonym: ci
address@hidden itemize
+
+Use @code{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. @code{commit} is careful to change in the
+repository only those files that you have really
+changed. By default (or if you explicitly specify the
address@hidden option), files in subdirectories are also
+examined and committed if they have changed; you can
+use the @samp{-l} option to limit @code{commit} to the
+current directory only.
+
address@hidden 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} (@pxref{update}).
address@hidden does not call the @code{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 (@pxref{modules}, and @pxref{loginfo})
+and placed in the @sc{rcs} file inside the
+repository. This log message can be retrieved with the
address@hidden command; see @ref{log}. You can specify the
+log message on the command line with the @samp{-m
address@hidden option, and thus avoid the editor invocation,
+or use the @samp{-F @var{file}} option to specify
+that the argument file contains the log message.
+
+At @code{commit}, a unique commitid is placed in the @sc{rcs}
+file inside the repository. All files committed at once
+get the same commitid. The commitid can be retrieved with
+the @code{log} and @code{status} command; see @ref{log},
address@hidden status}.
+
address@hidden
+* commit options:: commit options
+* commit examples:: commit examples
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden commit options
address@hidden commit options
+
+These standard options are supported by @code{commit}
+(@pxref{Common options}, for a complete description of
+them):
+
address@hidden @code
address@hidden -l
+Local; run only in current working directory.
+
address@hidden -R
+Commit directories recursively. This is on by default.
+
address@hidden -r @var{revision}
+Commit to @var{revision}. @var{revision} must be
+either a branch, or a revision on the main trunk that
+is higher than any existing revision number
+(@pxref{Assigning revisions}). You
+cannot commit to a specific revision on a branch.
address@hidden FIXME: Need xref for branch case.
address@hidden table
+
address@hidden also supports these options:
+
address@hidden @code
address@hidden -c
+Refuse to commit files unless the user has registered a valid edit on the
+file via @code{cvs edit}. This is most useful when @samp{commit -c}
+and @samp{edit -c} have been placed in all @file{.cvsrc} files.
+A commit can be forced anyways by either regestering an edit retroactively
+via @code{cvs edit} (no changes to the file will be lost) or using the
address@hidden option to commit. Support for @code{commit -c} requires both
+client and a server versions 1.12.10 or greater.
+
address@hidden -F @var{file}
+Read the log message from @var{file}, instead
+of invoking an editor.
+
address@hidden -f
+Note that this is not the standard behavior of
+the @samp{-f} option as defined in @ref{Common options}.
+
+Force @sc{cvs} to commit a new revision even if you haven't
+made any changes to the file. As of @sc{cvs} version 1.12.10,
+it also causes the @code{-c} option to be ignored. If the current revision
+of @var{file} is 1.7, then the following two commands
+are equivalent:
+
address@hidden
+$ cvs commit -f @var{file}
+$ cvs commit -r 1.8 @var{file}
address@hidden example
+
address@hidden This is odd, but it's how CVS has worked for some
address@hidden time.
+The @samp{-f} option disables recursion (i.e., it
+implies @samp{-l}). To force @sc{cvs} to commit a new
+revision for all files in all subdirectories, you must
+use @samp{-f -R}.
+
address@hidden -m @var{message}
+Use @var{message} as the log message, instead of
+invoking an editor.
address@hidden table
+
address@hidden 2000
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden commit examples
address@hidden commit examples
+
address@hidden FIXME: this material wants to be somewhere
address@hidden in "Branching and merging".
+
address@hidden Committing to a branch
+
+You can commit to a branch revision (one that has an
+even number of dots) with the @samp{-r} option. To
+create a branch revision, use the @samp{-b} option
+of the @code{rtag} or @code{tag} commands
+(@pxref{Branching and merging}). Then, either @code{checkout} or
address@hidden can be used to base your sources on the
+newly created branch. From that point on, all
address@hidden 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:
+
address@hidden
+$ 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
address@hidden example
+
address@hidden
+This works automatically since the @samp{-r} option is
+sticky.
+
address@hidden 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 @sc{cvs} conflict resolution. The scenario might
+look like:
+
address@hidden FIXME: Should we be recommending tagging the branchpoint?
address@hidden
+[[ hacked sources are present ]]
+$ cvs tag -b EXPR1
+$ cvs update -r EXPR1
+$ cvs commit
address@hidden example
+
+The @code{update} command will make the @samp{-r
+EXPR1} option sticky on all files. Note that your
+changes to the files will never be removed by the
address@hidden command. The @code{commit} will
+automatically commit to the correct branch, because the
address@hidden is sticky. You could also do like this:
+
address@hidden FIXME: Should we be recommending tagging the branchpoint?
address@hidden
+[[ hacked sources are present ]]
+$ cvs tag -b EXPR1
+$ cvs commit -r EXPR1
address@hidden example
+
address@hidden
+but then, only those files that were changed by you
+will have the @samp{-r EXPR1} sticky flag. If you hack
+away, and commit without specifying the @samp{-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
+
address@hidden
+$ cvs checkout -r EXPR1 whatever_module
address@hidden example
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden diff
address@hidden diff---Show differences between revisions
address@hidden diff (subcommand)
+
address@hidden @bullet
address@hidden
+Synopsis: diff [-lR] [-k kflag] [format_options] [(-r rev1[:date1] | -D date1)
[-r rev2[:date2] | -D date2]] address@hidden
address@hidden
+Requires: working directory, repository.
address@hidden
+Changes: nothing.
address@hidden itemize
+
+The @code{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 for diff is different than for other
address@hidden commands; for details @ref{Exit status}.
+
address@hidden
+* diff options:: diff options
+* diff examples:: diff examples
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden diff options
address@hidden diff options
+
+These standard options are supported by @code{diff}
+(@pxref{Common options}, for a complete description of
+them):
+
address@hidden @code
address@hidden -D @var{date}
+Use the most recent revision no later than @var{date}.
+See @samp{-r} for how this affects the comparison.
+
address@hidden -k @var{kflag}
+Process keywords according to @var{kflag}. See
address@hidden substitution}.
+
address@hidden -l
+Local; run only in current working directory.
+
address@hidden -R
+Examine directories recursively. This option is on by
+default.
+
address@hidden -r @var{tag}[:@var{date}]
+Compare with revision specified by @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. Zero, one or two
address@hidden options can be present. With no @samp{-r}
+option, the working file will be compared with the
+revision it was based on. With one @samp{-r}, that
+revision will be compared to your current working file.
+With two @samp{-r} options those two revisions will be
+compared (and your working file will not affect the
+outcome in any way).
address@hidden We should be a lot more explicit, with examples,
address@hidden about the difference between "cvs diff" and "cvs
address@hidden diff -r HEAD". This often confuses new users.
+
+One or both @samp{-r} options can be replaced by a
address@hidden @var{date}} option, described above.
address@hidden table
+
address@hidden Conceptually, this is a disaster. There are 3
address@hidden zillion diff formats that we support via the diff
address@hidden library. It is not obvious to me that we should
address@hidden document them all. Maybe just the most common ones
address@hidden like -c and -u, and think about phasing out the
address@hidden obscure ones.
address@hidden FIXCVS: also should be a way to specify an external
address@hidden diff program (which can be different for different
address@hidden file types) and pass through
address@hidden arbitrary options, so that the user can do
address@hidden "--pass=-Z --pass=foo" or something even if CVS
address@hidden doesn't know about the "-Z foo" option to diff.
address@hidden This would fit nicely with deprecating/eliminating
address@hidden the obscure options of the diff library, because it
address@hidden would let people specify an external GNU diff if
address@hidden they are into that sort of thing.
+The following options specify the format of the
+output. They have the same meaning as in GNU diff.
+Most options have two equivalent names, one of which is a single letter
+preceded by @samp{-}, and the other of which is a long name preceded by
address@hidden
+
address@hidden @samp
address@hidden address@hidden
+Show @var{lines} (an integer) lines of context. This option does not
+specify an output format by itself; it has no effect unless it is
+combined with @samp{-c} or @samp{-u}. This option is obsolete. For proper
+operation, @code{patch} typically needs at least two lines of context.
+
address@hidden -a
+Treat all files as text and compare them line-by-line, even if they
+do not seem to be text.
+
address@hidden -b
+Ignore trailing white space and consider all other sequences of one or
+more white space characters to be equivalent.
+
address@hidden -B
+Ignore changes that just insert or delete blank lines.
+
address@hidden --binary
+Read and write data in binary mode.
+
address@hidden --brief
+Report only whether the files differ, not the details of the
+differences.
+
address@hidden -c
+Use the context output format.
+
address@hidden -C @var{lines}
address@hidden address@hidden@address@hidden
+Use the context output format, showing @var{lines} (an integer) lines of
+context, or three if @var{lines} is not given.
+For proper operation, @code{patch} typically needs at least two lines of
+context.
+
address@hidden address@hidden
+Use @var{format} to output a line group containing differing lines from
+both files in if-then-else format. @xref{Line group formats}.
+
address@hidden -d
+Change the algorithm to perhaps find a smaller set of changes. This makes
address@hidden slower (sometimes much slower).
+
address@hidden -e
address@hidden --ed
+Make output that is a valid @code{ed} script.
+
address@hidden --expand-tabs
+Expand tabs to spaces in the output, to preserve the alignment of tabs
+in the input files.
+
address@hidden -f
+Make output that looks vaguely like an @code{ed} script but has changes
+in the order they appear in the file.
+
address@hidden -F @var{regexp}
+In context and unified format, for each hunk of differences, show some
+of the last preceding line that matches @var{regexp}.
+
address@hidden --forward-ed
+Make output that looks vaguely like an @code{ed} script but has changes
+in the order they appear in the file.
+
address@hidden -H
+Use heuristics to speed handling of large files that have numerous
+scattered small changes.
+
address@hidden address@hidden
+Do not discard the last @var{lines} lines of the common prefix
+and the first @var{lines} lines of the common suffix.
+
address@hidden -i
+Ignore changes in case; consider upper- and lower-case letters
+equivalent.
+
address@hidden -I @var{regexp}
+Ignore changes that just insert or delete lines that match @var{regexp}.
+
address@hidden address@hidden
+Make merged if-then-else output using @var{name}.
+
address@hidden --ignore-all-space
+Ignore white space when comparing lines.
+
address@hidden --ignore-blank-lines
+Ignore changes that just insert or delete blank lines.
+
address@hidden --ignore-case
+Ignore changes in case; consider upper- and lower-case to be the same.
+
address@hidden address@hidden
+Ignore changes that just insert or delete lines that match @var{regexp}.
+
address@hidden --ignore-space-change
+Ignore trailing white space and consider all other sequences of one or
+more white space characters to be equivalent.
+
address@hidden --initial-tab
+Output a tab rather than a space before the text of a line in normal or
+context format. This causes the alignment of tabs in the line to look
+normal.
+
address@hidden -L @var{label}
+Use @var{label} instead of the file name in the context format
+and unified format headers.
+
address@hidden address@hidden
+Use @var{label} instead of the file name in the context format
+and unified format headers.
+
address@hidden --left-column
+Print only the left column of two common lines in side by side format.
+
address@hidden address@hidden
+Use @var{format} to output all input lines in if-then-else format.
address@hidden formats}.
+
address@hidden --minimal
+Change the algorithm to perhaps find a smaller set of changes. This
+makes @code{diff} slower (sometimes much slower).
+
address@hidden -n
+Output RCS-format diffs; like @samp{-f} except that each command
+specifies the number of lines affected.
+
address@hidden -N
address@hidden --new-file
+In directory comparison, if a file is found in only one directory,
+treat it as present but empty in the other directory.
+
address@hidden address@hidden
+Use @var{format} to output a group of lines taken from just the second
+file in if-then-else format. @xref{Line group formats}.
+
address@hidden address@hidden
+Use @var{format} to output a line taken from just the second file in
+if-then-else format. @xref{Line formats}.
+
address@hidden address@hidden
+Use @var{format} to output a group of lines taken from just the first
+file in if-then-else format. @xref{Line group formats}.
+
address@hidden address@hidden
+Use @var{format} to output a line taken from just the first file in
+if-then-else format. @xref{Line formats}.
+
address@hidden -p
+Show which C function each change is in.
+
address@hidden --rcs
+Output RCS-format diffs; like @samp{-f} except that each command
+specifies the number of lines affected.
+
address@hidden --report-identical-files
address@hidden -s
+Report when two files are the same.
+
address@hidden --show-c-function
+Show which C function each change is in.
+
address@hidden address@hidden
+In context and unified format, for each hunk of differences, show some
+of the last preceding line that matches @var{regexp}.
+
address@hidden --side-by-side
+Use the side by side output format.
+
address@hidden --speed-large-files
+Use heuristics to speed handling of large files that have numerous
+scattered small changes.
+
address@hidden --suppress-common-lines
+Do not print common lines in side by side format.
+
address@hidden -t
+Expand tabs to spaces in the output, to preserve the alignment of tabs
+in the input files.
+
address@hidden -T
+Output a tab rather than a space before the text of a line in normal or
+context format. This causes the alignment of tabs in the line to look
+normal.
+
address@hidden --text
+Treat all files as text and compare them line-by-line, even if they
+do not appear to be text.
+
address@hidden -u
+Use the unified output format.
+
address@hidden address@hidden
+Use @var{format} to output a group of common lines taken from both files
+in if-then-else format. @xref{Line group formats}.
+
address@hidden address@hidden
+Use @var{format} to output a line common to both files in if-then-else
+format. @xref{Line formats}.
+
address@hidden -U @var{lines}
address@hidden address@hidden@address@hidden
+Use the unified output format, showing @var{lines} (an integer) lines of
+context, or three if @var{lines} is not given.
+For proper operation, @code{patch} typically needs at least two lines of
+context.
+
address@hidden -w
+Ignore white space when comparing lines.
+
address@hidden -W @var{columns}
address@hidden address@hidden
+Use an output width of @var{columns} in side by side format.
+
address@hidden -y
+Use the side by side output format.
address@hidden table
+
address@hidden
+* Line group formats:: Line group formats
+* Line formats:: Line formats
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden Line group formats
address@hidden Line group formats
+
+Line group formats let you specify formats suitable for many
+applications that allow if-then-else input, including programming
+languages and text formatting languages. A line group format specifies
+the output format for a contiguous group of similar lines.
+
+For example, the following command compares the TeX file @file{myfile}
+with the original version from the repository,
+and outputs a merged file in which old regions are
+surrounded by @address@hidden@address@hidden@address@hidden lines, and new
+regions are surrounded by @address@hidden@address@hidden@address@hidden lines.
+
address@hidden
+cvs diff \
+ --old-group-format='address@hidden@}
+%<address@hidden@}
+' \
+ --new-group-format='address@hidden@}
+%>address@hidden@}
+' \
+ myfile
address@hidden example
+
+The following command is equivalent to the above example, but it is a
+little more verbose, because it spells out the default line group formats.
+
address@hidden
+cvs diff \
+ --old-group-format='address@hidden@}
+%<address@hidden@}
+' \
+ --new-group-format='address@hidden@}
+%>address@hidden@}
+' \
+ --unchanged-group-format='%=' \
+ --changed-group-format='address@hidden@}
+%<address@hidden@}
address@hidden@}
+%>address@hidden@}
+' \
+ myfile
address@hidden example
+
+Here is a more advanced example, which outputs a diff listing with
+headers containing line numbers in a ``plain English'' style.
+
address@hidden
+cvs diff \
+ --unchanged-group-format='' \
+ --old-group-format='-------- %dn line%(n=1?:s) deleted at %df:
+%<' \
+ --new-group-format='-------- %dN line%(N=1?:s) added after %de:
+%>' \
+ --changed-group-format='-------- %dn line%(n=1?:s) changed at %df:
+%<-------- to:
+%>' \
+ myfile
address@hidden example
+
+To specify a line group format, use one of the options
+listed below. You can specify up to four line group formats, one for
+each kind of line group. You should quote @var{format}, because it
+typically contains shell metacharacters.
+
address@hidden @samp
address@hidden address@hidden
+These line groups are hunks containing only lines from the first file.
+The default old group format is the same as the changed group format if
+it is specified; otherwise it is a format that outputs the line group as-is.
+
address@hidden address@hidden
+These line groups are hunks containing only lines from the second
+file. The default new group format is same as the changed group
+format if it is specified; otherwise it is a format that outputs the
+line group as-is.
+
address@hidden address@hidden
+These line groups are hunks containing lines from both files. The
+default changed group format is the concatenation of the old and new
+group formats.
+
address@hidden address@hidden
+These line groups contain lines common to both files. The default
+unchanged group format is a format that outputs the line group as-is.
address@hidden table
+
+In a line group format, ordinary characters represent themselves;
+conversion specifications start with @samp{%} and have one of the
+following forms.
+
address@hidden @samp
address@hidden %<
+stands for the lines from the first file, including the trailing newline.
+Each line is formatted according to the old line format (@pxref{Line formats}).
+
address@hidden %>
+stands for the lines from the second file, including the trailing newline.
+Each line is formatted according to the new line format.
+
address@hidden %=
+stands for the lines common to both files, including the trailing newline.
+Each line is formatted according to the unchanged line format.
+
address@hidden %%
+stands for @samp{%}.
+
address@hidden %c'@var{C}'
+where @var{C} is a single character, stands for @var{C}.
address@hidden may not be a backslash or an apostrophe.
+For example, @samp{%c':'} stands for a colon, even inside
+the then-part of an if-then-else format, which a colon would
+normally terminate.
+
address@hidden %c'address@hidden'
+where @var{O} is a string of 1, 2, or 3 octal digits,
+stands for the character with octal code @var{O}.
+For example, @samp{%c'\0'} stands for a null character.
+
address@hidden @address@hidden
+where @var{F} is a @code{printf} conversion specification and @var{n} is one
+of the following letters, stands for @var{n}'s value formatted with @var{F}.
+
address@hidden @samp
address@hidden e
+The line number of the line just before the group in the old file.
+
address@hidden f
+The line number of the first line in the group in the old file;
+equals @var{e} + 1.
+
address@hidden l
+The line number of the last line in the group in the old file.
+
address@hidden m
+The line number of the line just after the group in the old file;
+equals @var{l} + 1.
+
address@hidden n
+The number of lines in the group in the old file; equals @var{l} - @var{f} + 1.
+
address@hidden E, F, L, M, N
+Likewise, for lines in the new file.
+
address@hidden table
+
+The @code{printf} conversion specification can be @samp{%d},
address@hidden, @samp{%x}, or @samp{%X}, specifying decimal, octal,
+lower case hexadecimal, or upper case hexadecimal output
+respectively. After the @samp{%} the following options can appear in
+sequence: a @samp{-} specifying left-justification; an integer
+specifying the minimum field width; and a period followed by an
+optional integer specifying the minimum number of digits.
+For example, @samp{%5dN} prints the number of new lines in the group
+in a field of width 5 characters, using the @code{printf} format @code{"%5d"}.
+
address@hidden (@address@hidden@var{T}:@var{E})
+If @var{A} equals @var{B} then @var{T} else @var{E}.
address@hidden and @var{B} are each either a decimal constant
+or a single letter interpreted as above.
+This format spec is equivalent to @var{T} if
address@hidden's value equals @var{B}'s; otherwise it is equivalent to @var{E}.
+
+For example, @samp{%(N=0?no:%dN) line%(N=1?:s)} is equivalent to
address@hidden lines} if @var{N} (the number of lines in the group in the
+new file) is 0, to @samp{1 line} if @var{N} is 1, and to @samp{%dN lines}
+otherwise.
address@hidden table
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden Line formats
address@hidden Line formats
+
+Line formats control how each line taken from an input file is
+output as part of a line group in if-then-else format.
+
+For example, the following command outputs text with a one-column
+change indicator to the left of the text. The first column of output
+is @samp{-} for deleted lines, @samp{|} for added lines, and a space
+for unchanged lines. The formats contain newline characters where
+newlines are desired on output.
+
address@hidden
+cvs diff \
+ --old-line-format='-%l
+' \
+ --new-line-format='|%l
+' \
+ --unchanged-line-format=' %l
+' \
+ myfile
address@hidden example
+
+To specify a line format, use one of the following options. You should
+quote @var{format}, since it often contains shell metacharacters.
+
address@hidden @samp
address@hidden address@hidden
+formats lines just from the first file.
+
address@hidden address@hidden
+formats lines just from the second file.
+
address@hidden address@hidden
+formats lines common to both files.
+
address@hidden address@hidden
+formats all lines; in effect, it sets all three above options simultaneously.
address@hidden table
+
+In a line format, ordinary characters represent themselves;
+conversion specifications start with @samp{%} and have one of the
+following forms.
+
address@hidden @samp
address@hidden %l
+stands for the contents of the line, not counting its trailing
+newline (if any). This format ignores whether the line is incomplete.
+
address@hidden %L
+stands for the contents of the line, including its trailing newline
+(if any). If a line is incomplete, this format preserves its
+incompleteness.
+
address@hidden %%
+stands for @samp{%}.
+
address@hidden %c'@var{C}'
+where @var{C} is a single character, stands for @var{C}.
address@hidden may not be a backslash or an apostrophe.
+For example, @samp{%c':'} stands for a colon.
+
address@hidden %c'address@hidden'
+where @var{O} is a string of 1, 2, or 3 octal digits,
+stands for the character with octal code @var{O}.
+For example, @samp{%c'\0'} stands for a null character.
+
address@hidden @var{F}n
+where @var{F} is a @code{printf} conversion specification,
+stands for the line number formatted with @var{F}.
+For example, @samp{%.5dn} prints the line number using the
address@hidden format @code{"%.5d"}. @xref{Line group formats}, for
+more about printf conversion specifications.
+
address@hidden table
+
+The default line format is @samp{%l} followed by a newline character.
+
+If the input contains tab characters and it is important that they line
+up on output, you should ensure that @samp{%l} or @samp{%L} in a line
+format is just after a tab stop (e.g.@: by preceding @samp{%l} or
address@hidden with a tab character), or you should use the @samp{-t} or
address@hidden option.
+
+Taken together, the line and line group formats let you specify many
+different formats. For example, the following command uses a format
+similar to @code{diff}'s normal format. You can tailor this command
+to get fine control over @code{diff}'s output.
+
address@hidden
+cvs diff \
+ --old-line-format='< %l
+' \
+ --new-line-format='> %l
+' \
+ --old-group-format='%df%(f=l?:,%dl)d%dE
+%<' \
+ --new-group-format='%dea%dF%(F=L?:,%dL)
+%>' \
+ --changed-group-format='%df%(f=l?:,%dl)c%dF%(F=L?:,%dL)
+%<---
+%>' \
+ --unchanged-group-format='' \
+ myfile
address@hidden example
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden diff examples
address@hidden diff examples
+
+The following line produces a Unidiff (@samp{-u} flag)
+between revision 1.14 and 1.19 of
address@hidden Due to the @samp{-kk} flag no
+keywords are substituted, so differences that only depend
+on keyword substitution are ignored.
+
address@hidden
+$ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
address@hidden example
+
+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:
+
address@hidden
+$ cvs diff -r RELEASE_1_0 -r EXPR1
address@hidden example
+
+A command like this can be used to produce a context
+diff between two releases:
+
address@hidden
+$ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
address@hidden example
+
+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.
+
address@hidden
+$ cvs diff -u | less
address@hidden example
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden export
address@hidden export---Export sources from CVS, similar to checkout
address@hidden export (subcommand)
+
address@hidden @bullet
address@hidden
+Synopsis: export [-flNnR] (-r rev[:date] | -D date) [-k subst] [-d dir]
address@hidden
address@hidden
+Requires: repository.
address@hidden
+Changes: current directory.
address@hidden itemize
+
+This command is a variant of @code{checkout}; use it
+when you want a copy of the source for module without
+the @sc{cvs} administrative directories. For example, you
+might use @code{export} to prepare source for shipment
+off-site. This command requires that you specify a
+date or tag (with @samp{-D} or @samp{-r}), so that you
+can count on reproducing the source you ship to others
+(and thus it always prunes empty directories).
+
+One often would like to use @samp{-kv} with @code{cvs
+export}. This causes any 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
address@hidden, one can no longer use the @code{ident}
+command (which is part of the @sc{rcs} suite---see
+ident(1)) which looks for keyword strings. If
+you want to be able to use @code{ident} you must not
+use @samp{-kv}.
+
address@hidden
+* export options:: export options
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden export options
address@hidden export options
+
+These standard options are supported by @code{export}
+(@pxref{Common options}, for a complete description of
+them):
+
address@hidden @code
address@hidden -D @var{date}
+Use the most recent revision no later than @var{date}.
+
address@hidden -f
+If no matching revision is found, retrieve the most
+recent revision (instead of ignoring the file).
+
address@hidden -l
+Local; run only in current working directory.
+
address@hidden -n
+Do not run any checkout program.
+
address@hidden -R
+Export directories recursively. This is on by default.
+
address@hidden -r @var{tag}[:@var{date}]
+Export the revision specified by @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{Common options}.
address@hidden table
+
+In addition, these options (that are common to
address@hidden and @code{export}) are also supported:
+
address@hidden @code
address@hidden -d @var{dir}
+Create a directory called @var{dir} for the working
+files, instead of using the module name.
address@hidden options}, for complete details on how
address@hidden handles this flag.
+
address@hidden -k @var{subst}
+Set keyword expansion mode (@pxref{Substitution modes}).
+
address@hidden -N
+Only useful together with @samp{-d @var{dir}}.
address@hidden options}, for complete details on how
address@hidden handles this flag.
address@hidden table
+
address@hidden
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden @node export examples
address@hidden export examples
+
+Contributed examples are gratefully accepted.
address@hidden -- Examples here!!
address@hidden ignore
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden history
address@hidden history---Show status of files and users
address@hidden history (subcommand)
+
address@hidden @bullet
address@hidden
+Synopsis: history [-report] [-flags] [-options args] address@hidden
address@hidden
+Requires: the file @file{$CVSROOT/CVSROOT/history}
address@hidden
+Changes: nothing.
address@hidden itemize
+
address@hidden can keep a history log that tracks each use of most @sc{cvs}
+commands. You can use @code{history} to display this information in
+various formats.
+
+To enable logging, the @samp{LogHistory} config option must be set to
+some value other than the empty string and the history file specified by
+the @samp{HistoryLogPath} option must be writable by all users who may run
+the @sc{cvs} executable (@pxref{config}).
+
+To enable the @code{history} command, logging must be enabled as above and
+the @samp{HistorySearchPath} config option (@pxref{config}) must be set to
+specify some number of the history logs created thereby and these files must
+be readable by each user who might run the @code{history} command.
+
+Creating a repository via the @code{cvs init} command will enable logging of
+all possible events to a single history log file
+(@file{$CVSROOT/CVSROOT/history}) with read and write permissions for all
+users (@pxref{Creating a repository}).
+
address@hidden@code{history} uses @samp{-f}, @samp{-l},
address@hidden, and @samp{-p} in ways that conflict with the
+normal use inside @sc{cvs} (@pxref{Common options}).}
+
address@hidden
+* history options:: history options
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden history options
address@hidden history options
+
+Several options (shown above as @samp{-report}) control what
+kind of report is generated:
+
address@hidden @code
address@hidden -c
+Report on each time commit was used (i.e., each time
+the repository was modified).
+
address@hidden -e
+Everything (all record types). Equivalent to
+specifying @samp{-x} with all record types. Of course,
address@hidden will also include record types which are
+added in a future version of @sc{cvs}; if you are
+writing a script which can only handle certain record
+types, you'll want to specify @samp{-x}.
+
address@hidden -m @var{module}
+Report on a particular module. (You can meaningfully
+use @samp{-m} more than once on the command line.)
+
address@hidden -o
+Report on checked-out modules. This is the default report type.
+
address@hidden -T
+Report on all tags.
+
address@hidden -x @var{type}
+Extract a particular set of record types @var{type} from the @sc{cvs}
+history. The types are indicated by single letters,
+which you may specify in combination.
+
+Certain commands have a single record type:
+
address@hidden @code
address@hidden F
+release
address@hidden O
+checkout
address@hidden E
+export
address@hidden T
+rtag
address@hidden table
+
address@hidden
+One of five record types may result from an update:
+
address@hidden @code
address@hidden C
+A merge was necessary but collisions were
+detected (requiring manual merging).
address@hidden G
+A merge was necessary and it succeeded.
address@hidden U
+A working file was copied from the repository.
address@hidden P
+A working file was patched to match the repository.
address@hidden W
+The working copy of a file was deleted during
+update (because it was gone from the repository).
address@hidden table
+
address@hidden
+One of three record types results from commit:
+
address@hidden @code
address@hidden A
+A file was added for the first time.
address@hidden M
+A file was modified.
address@hidden R
+A file was removed.
address@hidden table
address@hidden table
+
+The options shown as @samp{-flags} constrain or expand
+the report without requiring option arguments:
+
address@hidden @code
address@hidden -a
+Show data for all users (the default is to show data
+only for the user executing @code{history}).
+
address@hidden -l
+Show last modification only.
+
address@hidden -w
+Show only the records for modifications done from the
+same working directory where @code{history} is
+executing.
address@hidden table
+
+The options shown as @samp{-options @var{args}} constrain the report
+based on an argument:
+
address@hidden @code
address@hidden -b @var{str}
+Show data back to a record containing the string
address@hidden in either the module name, the file name, or
+the repository path.
+
address@hidden -D @var{date}
+Show data since @var{date}. This is slightly different
+from the normal use of @samp{-D @var{date}}, which
+selects the newest revision older than @var{date}.
+
address@hidden -f @var{file}
+Show data for a particular file
+(you can specify several @samp{-f} options on the same command line).
+This is equivalent to specifying the file on the command line.
+
address@hidden -n @var{module}
+Show data for a particular module
+(you can specify several @samp{-n} options on the same command line).
+
address@hidden -p @var{repository}
+Show data for a particular source repository (you
+can specify several @samp{-p} options on the same command
+line).
+
address@hidden -r @var{rev}
+Show records referring to revisions since the revision
+or tag named @var{rev} appears in individual @sc{rcs}
+files. Each @sc{rcs} file is searched for the revision or
+tag.
+
address@hidden -t @var{tag}
+Show records since tag @var{tag} was last added to the
+history file. This differs from the @samp{-r} flag
+above in that it reads only the history file, not the
address@hidden files, and is much faster.
+
address@hidden -u @var{name}
+Show records for user @var{name}.
+
address@hidden -z @var{timezone}
+Show times in the selected records using the specified
+time zone instead of UTC.
address@hidden table
+
address@hidden
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden @node history examples
address@hidden history examples
+
+Contributed examples will gratefully be accepted.
address@hidden -- Examples here!
address@hidden ignore
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden import
address@hidden import---Import sources into CVS, using vendor branches
address@hidden import (subcommand)
+
address@hidden FIXME: This node is way too long for one which has subnodes.
+
address@hidden @bullet
address@hidden
+Synopsis: import [-options] repository vendortag address@hidden
address@hidden
+Requires: Repository, source distribution directory.
address@hidden
+Changes: repository.
address@hidden itemize
+
+Use @code{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. @xref{Tracking sources}, for
+a discussion on this subject.
+
+The @var{repository} argument gives a directory name
+(or a path to a directory) under the @sc{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 @samp{checkout
+-j} to reconcile the differences, as import instructs
+you to do.
+
+If @sc{cvs} decides a file should be ignored
+(@pxref{cvsignore}), it does not import it and prints
address@hidden } followed by the filename (@pxref{import output}, for a
+complete description of the output).
+
+If the file @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. @xref{Wrappers}.
+
+The outside source is saved in a first-level
+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.
address@hidden is needed to identify the collection
+of source. @var{vendortag} is a tag for the entire
+branch (e.g., for 1.1.1). You must also specify at
+least one @var{releasetag} to uniquely identify the files at
+the leaves created each time you execute @code{import}. The
address@hidden should be new, not previously existing in the
+repository file, and uniquely identify the imported release,
+
address@hidden I'm not completely sure this belongs here. But
address@hidden we need to say it _somewhere_ reasonably obvious; it
address@hidden is a common misconception among people first learning CVS
+Note that @code{import} does @emph{not} change the
+directory in which you invoke it. In particular, it
+does not set up that directory as a @sc{cvs} working
+directory; if you want to work with the sources import
+them first and then check them out into a different
+directory (@pxref{Getting the source}).
+
address@hidden
+* import options:: import options
+* import output:: import output
+* import examples:: import examples
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden import options
address@hidden import options
+
+This standard option is supported by @code{import}
+(@pxref{Common options}, for a complete description):
+
address@hidden @code
address@hidden -m @var{message}
+Use @var{message} as log information, instead of
+invoking an editor.
address@hidden table
+
+There are the following additional special options.
+
address@hidden @code
address@hidden -b @var{branch}
+See @ref{Multiple vendor branches}.
+
address@hidden -k @var{subst}
+Indicate the 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 @ref{Substitution modes}, for a
+list of valid @samp{-k} settings.
+
address@hidden -I @var{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 !'.
+
address@hidden can be a file name pattern of the same type
+that you can specify in the @file{.cvsignore} file.
address@hidden
address@hidden -- Is this really true?
+
address@hidden -W @var{spec}
+Specify file names that should be filtered during
+import. You can use this option repeatedly.
+
address@hidden can be a file name pattern of the same type
+that you can specify in the @file{.cvswrappers}
+file. @xref{Wrappers}.
+
address@hidden -X
+Modify the algorithm used by @sc{cvs} when importing new files
+so that new files do not immediately appear on the main trunk.
+
+Specifically, this flag causes @sc{cvs} to mark new files as
+if they were deleted on the main trunk, by taking the following
+steps for each file in addition to those normally taken on import:
+creating a new revision on the main trunk indicating that
+the new file is @code{dead}, resetting the new file's default branch,
+and placing the file in the Attic (@pxref{Attic}) directory.
+
+Use of this option can be forced on a repository-wide basis
+by setting the @samp{ImportNewFilesToVendorBranchOnly} option in
+CVSROOT/config (@pxref{config}).
address@hidden table
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden import output
address@hidden import output
+
address@hidden keeps you informed of its progress by printing a line
+for each file, preceded by one character indicating the status of the file:
+
address@hidden @code
address@hidden U @var{file}
+The file already exists in the repository and has not been locally
+modified; a new revision has been created (if necessary).
+
address@hidden N @var{file}
+The file is a new file which has been added to the repository.
+
address@hidden C @var{file}
+The file already exists in the repository but has been locally modified;
+you will have to merge the changes.
+
address@hidden I @var{file}
+The file is being ignored (@pxref{cvsignore}).
+
address@hidden Symbolic link, importing
address@hidden Link, symbolic, importing
address@hidden FIXME: also (somewhere else) probably
address@hidden should be documenting what happens if you "cvs add"
address@hidden a symbolic link. Also maybe what happens if
address@hidden you manually create symbolic links within the
address@hidden repository (? - not sure why we'd want to suggest
address@hidden doing that).
address@hidden L @var{file}
+The file is a symbolic link; @code{cvs import} ignores symbolic links.
+People periodically suggest that this behavior should
+be changed, but if there is a consensus on what it
+should be changed to, it is not apparent.
+(Various options in the @file{modules} file can be used
+to recreate symbolic links on checkout, update, etc.;
address@hidden)
address@hidden table
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden import examples
address@hidden import examples
+
+See @ref{Tracking sources}, and @ref{From files}.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden log
address@hidden log---Print out log information for files
address@hidden log (subcommand)
+
address@hidden @bullet
address@hidden
+Synopsis: log [options] address@hidden
address@hidden
+Requires: repository, working directory.
address@hidden
+Changes: nothing.
address@hidden itemize
+
+Display log information for files. @code{log} used to
+call the @sc{rcs} utility @code{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 @sc{cvs}
+commands.
+
address@hidden Timezone, in output
address@hidden Zone, time, in output
+The output includes the location of the @sc{rcs} file,
+the @dfn{head} revision (the latest revision on the
+trunk), all symbolic names (tags) and some other
+things. For each revision, the revision number, the
+date, the author, the number of lines added/deleted, the commitid
+and the log message are printed. All dates are displayed
+in local time at the client. This is typically specified in
+the @code{$TZ} environment variable, which can be set to
+govern how @code{log} displays dates.
+
address@hidden@code{log} uses @samp{-R} in a way that conflicts
+with the normal use inside @sc{cvs} (@pxref{Common options}).}
+
address@hidden
+* log options:: log options
+* log examples:: log examples
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden log options
address@hidden log options
+
+By default, @code{log} prints all information that is
+available. All other options restrict the output. Note that the revision
+selection options (@code{-d}, @code{-r}, @code{-s}, and @code{-w}) have no
+effect, other than possibly causing a search for files in Attic directories,
+when used in conjunction with the options that restrict the output to only
address@hidden header fields (@code{-b}, @code{-h}, @code{-R}, and @code{-t})
+unless the @code{-S} option is also specified.
+
address@hidden @code
address@hidden -b
+Print information about the revisions on the default
+branch, normally the highest branch on the trunk.
+
address@hidden -d @var{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 @samp{-D} option to
+many other @sc{cvs} commands (@pxref{Common options}).
+Dates can be combined into ranges as follows:
+
address@hidden Should we be thinking about accepting ISO8601
address@hidden ranges? For example "1972-09-10/1972-09-12".
address@hidden @code
address@hidden @var{d1}<@var{d2}
address@hidden @var{d2}>@var{d1}
+Select the revisions that were deposited between
address@hidden and @var{d2}.
+
address@hidden <@var{d}
address@hidden @var{d}>
+Select all revisions dated @var{d} or earlier.
+
address@hidden @var{d}<
address@hidden >@var{d}
+Select all revisions dated @var{d} or later.
+
address@hidden @var{d}
+Select the single, latest revision dated @var{d} or
+earlier.
address@hidden table
+
+The @samp{>} or @samp{<} characters may be followed by
address@hidden to indicate an inclusive range rather than an
+exclusive one.
+
+Note that the separator is a semicolon (;).
+
address@hidden -h
+Print only the name of the @sc{rcs} file, name
+of the file in the working directory, head,
+default branch, access list, locks, symbolic names, and
+suffix.
+
address@hidden -l
+Local; run only in current working directory. (Default
+is to run recursively).
+
address@hidden -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.
+
address@hidden -R
+Print only the name of the @sc{rcs} file.
+
address@hidden Note that using a bare revision (in addition to not
address@hidden being explicitly documented here) is potentially
address@hidden confusing; it shows the log message to get from the
address@hidden previous revision to that revision. "-r1.3 -r1.6"
address@hidden (equivalent to "-r1.3,1.6") is even worse; it
address@hidden prints the messages to get from 1.2 to 1.3 and 1.5
address@hidden to 1.6. By analogy with "cvs diff", users might
address@hidden expect that it is more like specifying a range.
address@hidden It is not 100% clear to me how much of this should
address@hidden be documented (for example, multiple -r options
address@hidden perhaps could/should be deprecated given the false
address@hidden analogy with "cvs diff").
address@hidden In general, this section should be rewritten to talk
address@hidden about messages to get from revision rev1 to rev2,
address@hidden rather than messages for revision rev2 (that is, the
address@hidden messages are associated with a change not a static
address@hidden revision and failing to make this distinction causes
address@hidden much confusion).
address@hidden address@hidden
+Print information about revisions given in the
+comma-separated list @var{revisions} of revisions and
+ranges. The following table explains the available
+range formats:
+
address@hidden @code
address@hidden @var{rev1}:@var{rev2}
+Revisions @var{rev1} to @var{rev2} (which must be on
+the same branch).
+
address@hidden @var{rev1}::@var{rev2}
+The same, but excluding @var{rev1}.
+
address@hidden :@var{rev}
address@hidden ::@var{rev}
+Revisions from the beginning of the branch up to
+and including @var{rev}.
+
address@hidden @var{rev}:
+Revisions starting with @var{rev} to the end of the
+branch containing @var{rev}.
+
address@hidden @var{rev}::
+Revisions starting just after @var{rev} to the end of the
+branch containing @var{rev}.
+
address@hidden @var{branch}
+An argument that is a branch means all revisions on
+that branch.
+
address@hidden @var{branch1}:@var{branch2}
address@hidden @var{branch1}::@var{branch2}
+A range of branches means all revisions
+on the branches in that range.
+
address@hidden @var{branch}.
+The latest revision in @var{branch}.
address@hidden table
+
+A bare @samp{-r} with no revisions means the latest
+revision on the default branch, normally the trunk.
+There can be no space between the @samp{-r} option and
+its argument.
+
address@hidden -S
+Suppress the header if no revisions are selected.
+
address@hidden -s @var{states}
+Print information about revisions whose state
+attributes match one of the states given in the
+comma-separated list @var{states}. Individual states may
+be any text string, though @sc{cvs} commonly only uses two
+states, @samp{Exp} and @samp{dead}. See @ref{admin options}
+for more information.
+
address@hidden -t
+Print the same as @samp{-h}, plus the descriptive text.
+
address@hidden address@hidden
+Print information about revisions checked in by users
+with login names appearing in the comma-separated list
address@hidden If @var{logins} is omitted, the user's
+login is assumed. There can be no space between the
address@hidden option and its argument.
address@hidden table
+
address@hidden prints the intersection of the revisions
+selected with the options @samp{-d}, @samp{-s}, and
address@hidden, intersected with the union of the revisions
+selected by @samp{-b} and @samp{-r}.
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden log examples
address@hidden log examples
+
address@hidden Timezone, in output
address@hidden Zone, time, in output
+Since @code{log} shows dates in local time,
+you might want to see them in Coordinated Universal Time (UTC) or
+some other timezone.
+To do this you can set your @code{$TZ} environment
+variable before invoking @sc{cvs}:
+
address@hidden
+$ TZ=UTC cvs log foo.c
+$ TZ=EST cvs log bar.c
address@hidden example
+
+(If you are using a @code{csh}-style shell, like @code{tcsh},
+you would need to prefix the examples above with @code{env}.)
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden ls & rls
address@hidden ls & rls
address@hidden ls (subcommand)
address@hidden rls (subcommand)
+
address@hidden @bullet
address@hidden
+ls [-e | -l] [-RP] [-r tag[:date]] [-D date] address@hidden
address@hidden
+Requires: repository for @code{rls}, repository & working directory for
address@hidden
address@hidden
+Changes: nothing.
address@hidden
+Synonym: @code{dir} & @code{list} are synonyms for @code{ls} and @code{rdir}
+& @code{rlist} are synonyms for @code{rls}.
address@hidden itemize
+
+The @code{ls} and @code{rls} commands are used to list
+files and directories in the repository.
+
+By default @code{ls} lists the files and directories
+that belong in your working directory, what would be
+there after an @code{update}.
+
+By default @code{rls} lists the files and directories
+on the tip of the trunk in the topmost directory of the
+repository.
+
+Both commands accept an optional list of file and
+directory names, relative to the working directory for
address@hidden and the topmost directory of the repository
+for @code{rls}. Neither is recursive by default.
+
address@hidden
+* ls & rls options:: ls & rls options
+* rls examples: rls examples
address@hidden menu
+
address@hidden ls & rls options
address@hidden ls & rls options
+
+These standard options are supported by @code{ls} & @code{rls}:
+
address@hidden @code
address@hidden -d
+Show dead revisions (with tag when specified).
+
address@hidden -e
+Display in CVS/Entries format. This format is meant to remain easily parsable
+by automation.
+
address@hidden -l
+Display all details.
+
address@hidden -P
+Don't list contents of empty directories when recursing.
+
address@hidden -R
+List recursively.
+
address@hidden -r @var{tag}[:@var{date}]
+Show files specified by @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{Common options}.
+
address@hidden -D @var{date}
+Show files from date.
address@hidden table
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden rls examples
address@hidden rls examples
+
address@hidden
+$ cvs rls
+cvs rls: Listing module: `.'
+CVSROOT
+first-dir
address@hidden example
+
address@hidden
+$ cvs rls CVSROOT
+cvs rls: Listing module: `CVSROOT'
+checkoutlist
+commitinfo
+config
+cvswrappers
+loginfo
+modules
+notify
+rcsinfo
+taginfo
+verifymsg
+
address@hidden example
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden rdiff
address@hidden rdiff---'patch' format diffs between releases
address@hidden rdiff (subcommand)
+
address@hidden @bullet
address@hidden
+rdiff [-flags] [-V vn] (-r tag1[:date1] | -D date1) [-r tag2[:date2] | -D
date2] address@hidden
address@hidden
+Requires: repository.
address@hidden
+Changes: nothing.
address@hidden
+Synonym: patch
address@hidden itemize
+
+Builds a Larry Wall format patch(1) file between two
+releases, that can be fed directly into the @code{patch}
+program to bring an old release up-to-date with the new
+release. (This is one of the few @sc{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 @samp{-r} and
address@hidden 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 @sc{rcs} file.
+
+Note that if the software release affected is contained
+in more than one directory, then it may be necessary to
+specify the @samp{-p} option to the @code{patch} command when
+patching the old sources, so that @code{patch} is able to find
+the files that are located in other directories.
+
address@hidden
+* rdiff options:: rdiff options
+* rdiff examples:: rdiff examples
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden rdiff options
address@hidden rdiff options
+
+These standard options are supported by @code{rdiff}
+(@pxref{Common options}, for a complete description of
+them):
+
address@hidden @code
address@hidden -D @var{date}
+Use the most recent revision no later than @var{date}.
+
address@hidden -f
+If no matching revision is found, retrieve the most
+recent revision (instead of ignoring the file).
+
address@hidden -k @var{kflag}
+Process keywords according to @var{kflag}. See
address@hidden substitution}.
+
address@hidden -l
+Local; don't descend subdirectories.
+
address@hidden -R
+Examine directories recursively. This option is on by default.
+
address@hidden -r @var{tag}
+Use the revision specified by @var{tag}, or when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{Common options}.
address@hidden table
+
+In addition to the above, these options are available:
+
address@hidden @code
address@hidden -c
+Use the context diff format. This is the default format.
+
address@hidden -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.
+
address@hidden -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.
+
address@hidden -u
+Use the unidiff format for the context diffs.
+Remember that old versions
+of the @code{patch} 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}.
+
address@hidden -V @var{vn}
+Expand keywords according to the rules current in
address@hidden version @var{vn} (the expansion format changed with
address@hidden version 5). Note that this option is no
+longer accepted. @sc{cvs} will always expand keywords the
+way that @sc{rcs} version 5 does.
address@hidden table
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden rdiff examples
address@hidden rdiff examples
+
+Suppose you receive mail from @t{foo@@example.net} asking for an
+update from release 1.2 to 1.4 of the tc compiler. You
+have no such patches on hand, but with @sc{cvs} that can
+easily be fixed with a command such as this:
+
address@hidden
+$ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
+$$ Mail -s 'The patches you asked for' foo@@example.net
address@hidden example
+
+Suppose you have made release 1.3, and forked a branch
+called @samp{R_1_3fix} for bug fixes. @samp{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:
+
address@hidden
+$ 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
address@hidden example
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden release
address@hidden release---Indicate that a Module is no longer in use
address@hidden release (subcommand)
+
address@hidden @bullet
address@hidden
+release [-d] address@hidden
address@hidden
+Requires: Working directory.
address@hidden
+Changes: Working directory, history log.
address@hidden itemize
+
+This command is meant to safely cancel the effect of
address@hidden checkout}. Since @sc{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 @sc{cvs} history
+file (@pxref{history file}) that you've abandoned your
+checkout.
+
+Use @samp{cvs release} to avoid these problems. This
+command checks that no uncommitted changes are
+present; that you are executing it from immediately
+above a @sc{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, @samp{cvs release}
+leaves a record of its execution (attesting to your
+intentionally abandoning your checkout) in the @sc{cvs}
+history log.
+
address@hidden
+* release options:: release options
+* release output:: release output
+* release examples:: release examples
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden release options
address@hidden release options
+
+The @code{release} command supports one command option:
+
address@hidden @code
address@hidden -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.
+
address@hidden: The @code{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 @code{add}
+command; @pxref{Adding files}) will be silently deleted---even
+if it is non-empty!}
address@hidden table
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden release output
address@hidden release output
+
+Before @code{release} releases your sources it will
+print a one-line message for any file that is not
+up-to-date.
+
address@hidden @code
address@hidden U @var{file}
+There exists a newer revision of this file in the
+repository, and you have not modified your local copy
+of the file.
+
address@hidden A @var{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.
+
address@hidden R @var{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. @xref{commit}.
+
address@hidden M @var{file}
+The file is modified in your working directory. There
+might also be a newer revision inside the repository.
+
address@hidden ? @var{file}
address@hidden is in your working directory, but does not
+correspond to anything in the source repository, and is
+not in the list of files for @sc{cvs} to ignore (see the
+description of the @samp{-I} option, and
address@hidden). If you remove your working
+sources, this file will be lost.
address@hidden table
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden release examples
address@hidden release examples
+
+Release the @file{tc} directory, and delete your local working copy
+of the files.
+
address@hidden
+$ cd .. # @r{You must stand immediately above the}
+ # @r{sources when you issue @samp{cvs release}.}
+$ cvs release -d tc
+You have [0] altered files in this repository.
+Are you sure you want to release (and delete) directory `tc': y
+$
address@hidden example
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden server & pserver
address@hidden server & pserver---Act as a server for a client on stdin/stdout
address@hidden pserver (subcommand)
address@hidden server (subcommand)
+
address@hidden @bullet
address@hidden
+pserver [-c path]
+
+server [-c path]
address@hidden
+Requires: repository, client conversation on stdin/stdout
address@hidden
+Changes: Repository or, indirectly, client working directory.
address@hidden itemize
+
+The @sc{cvs} @code{server} and @code{pserver} commands are used to provide
+repository access to remote clients and expect a client conversation on
+stdin & stdout. Typically these commands are launched from @code{inetd} or
+via @code{ssh} (@pxref{Remote repositories}).
+
address@hidden expects that the client has already been authenticated somehow,
+typically via @sc{ssh}, and @code{pserver} attempts to authenticate the client
+itself.
+
+Only one option is available with the @code{server} and @code{pserver}
+commands:
+
address@hidden configuration file
address@hidden @code
address@hidden -c path
+Load configuration from @var{path} rather than the default location
address@hidden/CVSROOT/config} (@pxref{config}). @var{path} must be
address@hidden/etc/cvs.conf} or prefixed by @file{/etc/cvs/}. This option is
+supported beginning with @sc{cvs} release 1.12.13.
address@hidden table
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden update
address@hidden update---Bring work tree in sync with repository
address@hidden update (subcommand)
+
address@hidden @bullet
address@hidden
+update [-ACdflPpR] [-I name] [-j rev [-j rev]] [-k kflag] [-r tag[:date] | -D
date] [-W spec] address@hidden
address@hidden
+Requires: repository, working directory.
address@hidden
+Changes: working directory.
address@hidden itemize
+
+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} command from
+within your working directory to reconcile your work
+with any revisions applied to the source repository
+since your last checkout or update. Without the @code{-C}
+option, @code{update} will also merge any differences
+between the local copy of files and their base revisions
+into any destination revisions specified with @code{-r},
address@hidden, or @code{-A}.
+
address@hidden
+* update options:: update options
+* update output:: update output
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden update options
address@hidden update options
+
+These standard options are available with @code{update}
+(@pxref{Common options}, for a complete description of
+them):
+
address@hidden @code
address@hidden -D date
+Use the most recent revision no later than @var{date}.
+This option is sticky, and implies @samp{-P}.
+See @ref{Sticky tags}, for more information on sticky tags/dates.
+
address@hidden -f
+Only useful with the @samp{-D} or @samp{-r} flags. If no matching revision
+is found, retrieve the most recent revision (instead of ignoring the file).
+
address@hidden -k @var{kflag}
+Process keywords according to @var{kflag}. See
address@hidden substitution}.
+This option is sticky; future updates of
+this file in this working directory will use the same
address@hidden The @code{status} command can be viewed
+to see the sticky options. See @ref{Invoking CVS}, for
+more information on the @code{status} command.
+
address@hidden -l
+Local; run only in current working directory. @xref{Recursive behavior}.
+
address@hidden -P
+Prune empty directories. See @ref{Moving directories}.
+
address@hidden -p
+Pipe files to the standard output.
+
address@hidden -R
+Update directories recursively (default). @xref{Recursive
+behavior}.
+
address@hidden -r @var{tag}[:@var{date}]
+Retrieve the revisions specified by @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. This option is sticky, and implies @samp{-P}.
+See @ref{Sticky tags}, for more information on sticky tags/dates. Also
+see @ref{Common options}.
address@hidden table
+
address@hidden 800
+These special options are also available with
address@hidden
+
address@hidden @code
address@hidden -A
+Reset any sticky tags, dates, or @samp{-k} options.
+See @ref{Sticky tags}, for more information on sticky tags/dates.
+
address@hidden -C
+Overwrite locally modified files with clean copies from
+the repository (the modified file is saved in
address@hidden@address@hidden, however).
+
address@hidden -d
+Create any directories that exist in the repository if
+they're missing from the working directory. Normally,
address@hidden 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} will create
+those directories, which may not be what you want.
+
address@hidden -I @var{name}
+Ignore files whose names match @var{name} (in your
+working directory) during the update. You can specify
address@hidden more than once on the command line to specify
+several files to ignore. Use @samp{-I !} to avoid
+ignoring any files at all. @xref{cvsignore}, for other
+ways to make @sc{cvs} ignore some files.
+
address@hidden address@hidden
+Specify file names that should be filtered during
+update. You can use this option repeatedly.
+
address@hidden can be a file name pattern of the same type
+that you can specify in the @file{.cvswrappers}
+file. @xref{Wrappers}.
+
address@hidden address@hidden
+With two @samp{-j} options, merge changes from the
+revision specified with the first @samp{-j} option to
+the revision specified with the second @samp{j} option,
+into the working directory.
+
+With one @samp{-j} option, merge changes from the
+ancestor revision to the revision specified with the
address@hidden 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} option.
+
+Note that using a single @samp{-j @var{tagname}} option rather than
address@hidden @var{branchname}} to merge changes from a branch will
+often not remove files which were removed on the branch.
address@hidden adds and removals}, for more.
+
+In addition, each @samp{-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:
address@hidden@var{Symbolic_Tag}:@var{Date_Specifier}}.
+
address@hidden and merging}.
+
address@hidden table
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden update output
address@hidden update output
+
address@hidden and @code{checkout} keep you informed of
+their progress by printing a line for each file, preceded
+by one character indicating the status of the file:
+
address@hidden @code
address@hidden U @var{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 working directory, and for files
+that you haven't changed but are not the most recent
+versions available in the repository.
+
address@hidden A @var{file}
+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} on the file. This is a
+reminder to you that the file needs to be committed.
+
address@hidden R @var{file}
+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} on the file. This is a
+reminder to you that the file needs to be committed.
+
address@hidden M @var{file}
+The file is modified in your working directory.
+
address@hidden 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.
+
address@hidden 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}) will be made. The exact
+name of that file is printed while @code{update} runs.
+
address@hidden C @var{file}
address@hidden .# files
address@hidden __ files (VMS)
+A conflict was detected while trying to merge your
+changes to @var{file} with changes from the source
+repository. @var{file} (the copy in your working
+directory) is now the result of attempting to merge
+the two revisions; an unmodified copy of your file
+is also in your working directory, with the name
address@hidden@address@hidden where @var{revision}
+is the revision that your modified file started
+from. Resolve the conflict as described in
address@hidden example}.
address@hidden "some systems" as in out-of-the-box OSes? Not as
address@hidden far as I know. We need to advise sysadmins as well
address@hidden as users how to set up this kind of purge, if that is
address@hidden what they want.
address@hidden We also might want to think about cleaner solutions,
address@hidden like having CVS remove the .# file once the conflict
address@hidden has been resolved or something like that.
+(Note that some systems automatically purge
+files that begin with @file{.#} 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 @sc{vms}, the file name starts with
address@hidden rather than @file{.#}.
+
address@hidden ? @var{file}
address@hidden is in your working directory, but does not
+correspond to anything in the source repository, and is
+not in the list of files for @sc{cvs} to ignore (see the
+description of the @samp{-I} option, and
address@hidden).
address@hidden table
+
address@hidden ----- END MAN 1 -----
address@hidden
---------------------------------------------------------------------
address@hidden Invoking CVS
address@hidden Quick reference to CVS commands
address@hidden Command reference
address@hidden Reference, commands
address@hidden Invoking CVS
+
+This appendix describes how to invoke @sc{cvs}, with
+references to where each command or feature is
+described in detail. For other references run the
address@hidden --help} command, or see @ref{Index}.
+
+A @sc{cvs} command looks like:
+
address@hidden
+cvs [ @var{global_options} ] @var{command} [ @var{command_options} ] [
@var{command_args} ]
address@hidden example
+
+Global options:
+
address@hidden @code
address@hidden address@hidden
+Specify legal @sc{cvsroot} directory (server only) (not
+in @sc{cvs} 1.9 and older). See @ref{Password
+authentication server}.
+
address@hidden -a
+Authenticate all communication (client only) (not in @sc{cvs}
+1.9 and older). See @ref{Global options}.
+
address@hidden -b
+Specify RCS location (@sc{cvs} 1.9 and older). See
address@hidden options}.
+
address@hidden -d @var{root}
+Specify the @sc{cvsroot}. See @ref{Repository}.
+
address@hidden -e @var{editor}
+Edit messages with @var{editor}. See @ref{Committing
+your changes}.
+
address@hidden -f
+Do not read the @file{~/.cvsrc} file. See @ref{Global
+options}.
+
address@hidden -H
address@hidden --help
+Print a help message. See @ref{Global options}.
+
address@hidden -n
+Do not change any files. See @ref{Global options}.
+
address@hidden -Q
+Be really quiet. See @ref{Global options}.
+
address@hidden -q
+Be somewhat quiet. See @ref{Global options}.
+
address@hidden -r
+Make new working files read-only. See @ref{Global options}.
+
address@hidden -s @address@hidden
+Set a user variable. See @ref{Variables}.
+
address@hidden -T @var{tempdir}
+Put temporary files in @var{tempdir}. See @ref{Global
+options}.
+
address@hidden -t
+Trace @sc{cvs} execution. See @ref{Global options}.
+
address@hidden -v
address@hidden --version
+Display version and copyright information for @sc{cvs}.
+
address@hidden -w
+Make new working files read-write. See @ref{Global
+options}.
+
address@hidden -x
+Encrypt all communication (client only).
+See @ref{Global options}.
+
address@hidden -z @var{gzip-level}
address@hidden Compression
address@hidden Gzip
+Set the compression level (client only).
+See @ref{Global options}.
address@hidden table
+
+Keyword expansion modes (@pxref{Substitution modes}):
+
address@hidden
+-kkv address@hidden: file1,v 1.1 1993/12/09 03:21:13 joe Exp $
+-kkvl address@hidden: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
+-kk address@hidden
+-kv file1,v 1.1 1993/12/09 03:21:13 joe Exp
+-ko @i{no expansion}
+-kb @i{no expansion, file is binary}
address@hidden example
+
+Keywords (@pxref{Keyword list}):
+
address@hidden
address@hidden: joe $
address@hidden: 1993/12/09 03:21:13 $
address@hidden: files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
address@hidden: /home/files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
address@hidden: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
address@hidden: harry $
address@hidden: snapshot_1_14 $
address@hidden: file1,v $
address@hidden: 1.1 $
address@hidden: /home/files/file1,v $
address@hidden: Exp $
address@hidden: file1,v $
+Revision 1.1 1993/12/09 03:30:17 joe
+Initial revision
+
address@hidden example
+
+Tags (@pxref{Tags (builtin)})
+
address@hidden
+.trunk
+.head
+.base
+.origin
+.root
+.prev
+.next
+.commitid
+
address@hidden example
+
address@hidden The idea behind this table is that we want each item
address@hidden to be a sentence or two at most. Preferably a
address@hidden single line.
address@hidden
address@hidden In some cases refs to "foo options" are just to get
address@hidden this thing written quickly, not because the "foo
address@hidden options" node is really the best place to point.
+Commands, command options, and command arguments:
+
address@hidden @code
address@hidden ------------------------------------------------------------
address@hidden add address@hidden address@hidden@dots{}]
+Add a new file/directory. See @ref{Adding files}.
+
address@hidden @code
address@hidden -k @var{kflag}
+Set keyword expansion.
+
address@hidden -m @var{msg}
+Set file description.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden admin address@hidden address@hidden@dots{}]
+Administration of history files in the repository. See
address@hidden
address@hidden This list omits those options which are not
address@hidden documented as being useful with CVS. That might be
address@hidden a mistake...
+
address@hidden @code
address@hidden address@hidden
+Set default branch. See @ref{Reverting local changes}.
+
address@hidden address@hidden
+Set comment leader.
+
address@hidden address@hidden
+Set keyword substitution. See @ref{Keyword
+substitution}.
+
address@hidden address@hidden
+Lock revision @var{rev}, or latest revision.
+
address@hidden address@hidden:@var{msg}
+Replace the log message of revision @var{rev} with
address@hidden
+
address@hidden address@hidden
+Delete revisions from the repository. See
address@hidden options}.
+
address@hidden -q
+Run quietly; do not print diagnostics.
+
address@hidden address@hidden:@var{rev}]
+Set the state. See @ref{admin options} for more information on possible
+states.
+
address@hidden Does not work for client/server CVS
address@hidden -t
+Set file description from standard input.
+
address@hidden address@hidden
+Set file description from @var{file}.
+
address@hidden address@hidden
+Set file description to @var{string}.
+
address@hidden address@hidden
+Unlock revision @var{rev}, or latest revision.
+
address@hidden List long options after the short options
address@hidden --execute
+Turn on execute bits on repository file.
+See @ref{admin options} for more information.
+
address@hidden --no-execute
+Turn off execute bits on repository file.
+See @ref{admin options} for more information.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden annotate address@hidden address@hidden@dots{}]
+Show last revision where each line was modified. See
address@hidden
+
address@hidden @code
address@hidden -D @var{date}
+Annotate the most recent revision no later than
address@hidden See @ref{Common options}.
+
address@hidden -F
+Force annotation of binary files. (Without this option,
+binary files are skipped with a message.)
+
address@hidden -f
+Use head revision if tag/date not found. See
address@hidden options}.
+
address@hidden -l
+Local; run only in current working directory. @xref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
address@hidden -r @var{tag}[:@var{date}]
+Annotate revisions specified by @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{Common options}.
+
address@hidden -w @var{width}
+Modify the width of the username field (default 8).
+The specified @var{width} must be greater than 0 and less than 80.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden checkout address@hidden @address@hidden
+Get a copy of the sources. See @ref{checkout}.
+
address@hidden @code
address@hidden -A
+Reset any sticky tags/date/options. See @ref{Sticky
+tags} and @ref{Keyword substitution}.
+
address@hidden -c
+Output the module database. See @ref{checkout options}.
+
address@hidden -D @var{date}
+Check out revisions as of @var{date} (is sticky). See
address@hidden options}.
+
address@hidden -d @var{dir}
+Check out into @var{dir}. See @ref{checkout options}.
+
address@hidden -f
+Use head revision if tag/date not found. See
address@hidden options}.
+
address@hidden Probably want to use rev1/rev2 style like for diff
address@hidden -r. Here and in on-line help.
address@hidden -j @var{tag}[:@var{date}]
+Merge in the change specified by @var{tag}, or when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{checkout options}.
+
address@hidden -k @var{kflag}
+Use @var{kflag} keyword expansion. See
address@hidden modes}.
+
address@hidden -l
+Local; run only in current working directory. @xref{Recursive behavior}.
+
address@hidden -N
+Don't ``shorten'' module paths if -d specified. See
address@hidden options}.
+
address@hidden -n
+Do not run module program (if any). See @ref{checkout options}.
+
address@hidden -P
+Prune empty directories. See @ref{Moving directories}.
+
address@hidden -p
+Check out files to standard output (avoids
+stickiness). See @ref{checkout options}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
address@hidden -r @var{tag}[:@var{date}]
+Checkout the revision already tagged with @var{tag} or, when @var{date} is
+specified and @var{tag} is a branch tag, the version from the branch @var{tag}
+as it existed on @var{date}. This . See @ref{Common options}.
+
address@hidden -s
+Like -c, but include module status. See @ref{checkout options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden commit address@hidden address@hidden@dots{}]
+Check changes into the repository. See @ref{commit}.
+
address@hidden @code
address@hidden -c
+Check for valid edits before committing. Requires a @sc{cvs} client and server
+both version 1.12.10 or greater.
+
address@hidden -F @var{file}
+Read log message from @var{file}. See @ref{commit options}.
+
address@hidden -f
address@hidden What is this "disables recursion"? It is from the
address@hidden on-line help; is it documented in this manual?
+Force the file to be committed; disables recursion.
+See @ref{commit options}.
+
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -m @var{msg}
+Use @var{msg} as log message. See @ref{commit options}.
+
address@hidden -n
+Do not run module program (if any). See @ref{commit options}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
address@hidden -r @var{rev}
+Commit to @var{rev}. See @ref{commit options}.
address@hidden FIXME: should be dragging over text from
address@hidden commit options, especially if it can be cleaned up
address@hidden and made concise enough.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden diff address@hidden address@hidden@dots{}]
+Show differences between revisions. See @ref{diff}.
+In addition to the options shown below, accepts a wide
+variety of options to control output style, for example
address@hidden for context diffs.
+
address@hidden @code
address@hidden -D @var{date1}
+Diff revision for date against working file. See
address@hidden options}.
+
address@hidden -D @var{date2}
+Diff @var{rev1}/@var{date1} against @var{date2}. See
address@hidden options}.
+
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -N
+Include diffs for added and removed files. See
address@hidden options}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
address@hidden -r @var{tag1}[:@var{date1}]
+Diff the revisions specified by @var{tag1} or, when @var{date1} is specified
+and @var{tag1} is a branch tag, the version from the branch @var{tag1} as it
+existed on @var{date1}, against the working file. See @ref{diff options}
+and @ref{Common options}.
+
address@hidden -r @var{tag2}[:@var{date2}]
+Diff the revisions specified by @var{tag2} or, when @var{date2} is specified
+and @var{tag2} is a branch tag, the version from the branch @var{tag2} as it
+existed on @var{date2}, against @var{rev1}/@var{date1}. See @ref{diff options}
+and @ref{Common options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden edit address@hidden address@hidden@dots{}]
+Get ready to edit a watched file. See @ref{Editing files}.
+
address@hidden @code
address@hidden -a @var{actions}
+Specify actions for temporary watch, where
address@hidden is @code{edit}, @code{unedit},
address@hidden, @code{all}, or @code{none}. See
address@hidden files}.
+
address@hidden -c
+Check edits: Edit fails if someone else is already editting the file.
+Requires a @sc{cvs} client and server both of version 1.12.10 or greater.
+
address@hidden -f
+Force edit; ignore other edits. Added in CVS 1.12.10.
+
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden editors address@hidden address@hidden@dots{}]
+See who is editing a watched file. See @ref{Watch information}.
+
address@hidden @code
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden export address@hidden @address@hidden
+Export files from @sc{cvs}. See @ref{export}.
+
address@hidden @code
address@hidden -D @var{date}
+Check out revisions as of @var{date}. See
address@hidden options}.
+
address@hidden -d @var{dir}
+Check out into @var{dir}. See @ref{export options}.
+
address@hidden -f
+Use head revision if tag/date not found. See
address@hidden options}.
+
address@hidden -k @var{kflag}
+Use @var{kflag} keyword expansion. See
address@hidden modes}.
+
address@hidden -l
+Local; run only in current working directory. @xref{Recursive behavior}.
+
address@hidden -N
+Don't ``shorten'' module paths if -d specified. See
address@hidden options}.
+
address@hidden -n
+Do not run module program (if any). See @ref{export options}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
address@hidden -r @var{tag}[:@var{date}]
+Export the revisions specified by @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{Common options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden history address@hidden address@hidden@dots{}]
+Show repository access history. See @ref{history}.
+
address@hidden @code
address@hidden -a
+All users (default is self). See @ref{history options}.
+
address@hidden -b @var{str}
+Back to record with @var{str} in module/file/repos
+field. See @ref{history options}.
+
address@hidden -c
+Report on committed (modified) files. See @ref{history options}.
+
address@hidden -D @var{date}
+Since @var{date}. See @ref{history options}.
+
address@hidden -e
+Report on all record types. See @ref{history options}.
+
address@hidden -l
+Last modified (committed or modified report). See @ref{history options}.
+
address@hidden -m @var{module}
+Report on @var{module} (repeatable). See @ref{history options}.
+
address@hidden -n @var{module}
+In @var{module}. See @ref{history options}.
+
address@hidden -o
+Report on checked out modules. See @ref{history options}.
+
address@hidden -p @var{repository}
+In @var{repository}. See @ref{history options}.
+
address@hidden -r @var{rev}
+Since revision @var{rev}. See @ref{history options}.
+
address@hidden -T
address@hidden What the @address@hidden is a TAG? Same as a tag? This
address@hidden wording is also in the online-line help.
+Produce report on all TAGs. See @ref{history options}.
+
address@hidden -t @var{tag}
+Since tag record placed in history file (by anyone).
+See @ref{history options}.
+
address@hidden -u @var{user}
+For user @var{user} (repeatable). See @ref{history options}.
+
address@hidden -w
+Working directory must match. See @ref{history options}.
+
address@hidden -x @var{types}
+Report on @var{types}, one or more of
address@hidden See @ref{history options}.
+
address@hidden -z @var{zone}
+Output for time zone @var{zone}. See @ref{history options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden import address@hidden @var{repository} @var{vendor-tag}
@address@hidden
+Import files into @sc{cvs}, using vendor branches. See
address@hidden
+
address@hidden @code
address@hidden -b @var{bra}
+Import to vendor branch @var{bra}. See
address@hidden vendor branches}.
+
address@hidden -d
+Use the file's modification time as the time of
+import. See @ref{import options}.
+
address@hidden -k @var{kflag}
+Set default keyword substitution mode. See
address@hidden options}.
+
address@hidden -m @var{msg}
+Use @var{msg} for log message. See
address@hidden options}.
+
address@hidden -I @var{ign}
+More files to ignore (! to reset). See
address@hidden options}.
+
address@hidden -W @var{spec}
+More wrappers. See @ref{import options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden init
+Create a @sc{cvs} repository if it doesn't exist. See
address@hidden a repository}.
+
address@hidden ------------------------------------------------------------
address@hidden kserver
+Kerberos authenticated server.
+See @ref{Kerberos authenticated}.
+
address@hidden ------------------------------------------------------------
address@hidden log address@hidden address@hidden@dots{}]
+Print out history information for files. See @ref{log}.
+
address@hidden @code
address@hidden -b
+Only list revisions on the default branch. See @ref{log options}.
+
address@hidden -d @var{dates}
+Specify dates (@var{d1}<@var{d2} for range, @var{d} for
+latest before). See @ref{log options}.
+
address@hidden -h
+Only print header. See @ref{log options}.
+
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -N
+Do not list tags. See @ref{log options}.
+
address@hidden -R
+Only print name of RCS file. See @ref{log options}.
+
address@hidden address@hidden
+Only list revisions @var{revs}. See @ref{log options}.
+
address@hidden -s @var{states}
+Only list revisions with specified states. See @ref{log options}.
+
address@hidden -t
+Only print header and descriptive text. See @ref{log
+options}.
+
address@hidden address@hidden
+Only list revisions checked in by specified logins. See @ref{log options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden login
+Prompt for password for authenticating server. See
address@hidden authentication client}.
+
address@hidden ------------------------------------------------------------
address@hidden logout
+Remove stored password for authenticating server. See
address@hidden authentication client}.
+
address@hidden ------------------------------------------------------------
address@hidden pserver
+Password authenticated server.
+See @ref{Password authentication server}.
+
address@hidden ------------------------------------------------------------
address@hidden rannotate address@hidden address@hidden@dots{}]
+Show last revision where each line was modified. See
address@hidden
+
address@hidden @code
address@hidden -D @var{date}
+Annotate the most recent revision no later than
address@hidden See @ref{Common options}.
+
address@hidden -F
+Force annotation of binary files. (Without this option,
+binary files are skipped with a message.)
+
address@hidden -f
+Use head revision if tag/date not found. See
address@hidden options}.
+
address@hidden -l
+Local; run only in current working directory. @xref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive behavior}.
+
address@hidden -r @var{tag}[:@var{date}]
+Annotate the revision specified by @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag}
+as it existed on @var{date}. See @ref{Common options}.
+
address@hidden -w @var{width}
+Modify the width of the username field (default 8).
+The specified @var{width} must be greater than 0 and less than 80.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden rdiff address@hidden @address@hidden
+Show differences between releases. See @ref{rdiff}.
+
address@hidden @code
address@hidden -c
+Context diff output format (default). See @ref{rdiff options}.
+
address@hidden -D @var{date}
+Select revisions based on @var{date}. See @ref{Common options}.
+
address@hidden -f
+Use head revision if tag/date not found. See
address@hidden options}.
+
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
address@hidden -r @var{tag}[:@var{date}]
+Select the revisions specified by @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{diff options} and @ref{Common options}.
+
address@hidden -s
+Short patch - one liner per file. See @ref{rdiff options}.
+
address@hidden -t
+Top two diffs - last change made to the file. See
address@hidden options}.
+
address@hidden -u
+Unidiff output format. See @ref{rdiff options}.
+
address@hidden -V @var{vers}
+Use RCS Version @var{vers} for keyword expansion (obsolete). See
address@hidden options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden release address@hidden @var{directory}
+Indicate that a directory is no longer in use. See
address@hidden
+
address@hidden @code
address@hidden -d
+Delete the given directory. See @ref{release options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden remove address@hidden address@hidden@dots{}]
+Remove an entry from the repository. See @ref{Removing files}.
+
address@hidden @code
address@hidden -f
+Delete the file before removing it. See @ref{Removing files}.
+
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden rlog address@hidden address@hidden@dots{}]
+Print out history information for modules. See @ref{log}.
+
address@hidden @code
address@hidden -b
+Only list revisions on the default branch. See @ref{log options}.
+
address@hidden -d @var{dates}
+Specify dates (@var{d1}<@var{d2} for range, @var{d} for
+latest before). See @ref{log options}.
+
address@hidden -h
+Only print header. See @ref{log options}.
+
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -N
+Do not list tags. See @ref{log options}.
+
address@hidden -R
+Only print name of RCS file. See @ref{log options}.
+
address@hidden address@hidden
+Only list revisions @var{revs}. See @ref{log options}.
+
address@hidden -s @var{states}
+Only list revisions with specified states. See @ref{log options}.
+
address@hidden -t
+Only print header and descriptive text. See @ref{log options}.
+
address@hidden address@hidden
+Only list revisions checked in by specified logins. See @ref{log options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden rtag address@hidden @var{tag} @address@hidden
+Add a symbolic tag to a module.
+See @ref{Revisions} and @ref{Branching and merging}.
+
address@hidden @code
address@hidden -a
+Clear tag from removed files that would not otherwise
+be tagged. See @ref{Tagging add/remove}.
+
address@hidden -b
+Create a branch named @var{tag}. See @ref{Branching and merging}.
+
address@hidden -B
+Used in conjunction with -F or -d, enables movement and deletion of
+branch tags. Use with extreme caution.
+
address@hidden -D @var{date}
+Tag revisions as of @var{date}. See @ref{Tagging by date/tag}.
+
address@hidden -d
+Delete @var{tag}. See @ref{Modifying tags}.
+
address@hidden -F
+Move @var{tag} if it already exists. See @ref{Modifying tags}.
+
address@hidden -f
+Force a head revision match if tag/date not found.
+See @ref{Tagging by date/tag}.
+
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -n
+No execution of tag program. See @ref{Common options}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
address@hidden -r @var{tag}[:@var{date}]
+Tag the revision already tagged with @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{Tagging by date/tag} and @ref{Common options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden server
+Rsh server. See @ref{Connecting via rsh}.
+
address@hidden ------------------------------------------------------------
address@hidden status address@hidden @address@hidden
+Display status information in a working directory. See
address@hidden status}.
+
address@hidden @code
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive behavior}.
+
address@hidden -v
+Include tag information for file. See @ref{Tags}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden tag address@hidden @var{tag} address@hidden@dots{}]
+Add a symbolic tag to checked out version of files.
+See @ref{Revisions} and @ref{Branching and merging}.
+
address@hidden @code
address@hidden -b
+Create a branch named @var{tag}. See @ref{Branching and merging}.
+
address@hidden -c
+Check that working files are unmodified. See
address@hidden the working directory}.
+
address@hidden -D @var{date}
+Tag revisions as of @var{date}. See @ref{Tagging by date/tag}.
+
address@hidden -d
+Delete @var{tag}. See @ref{Modifying tags}.
+
address@hidden -F
+Move @var{tag} if it already exists. See @ref{Modifying tags}.
+
address@hidden -f
+Force a head revision match if tag/date not found.
+See @ref{Tagging by date/tag}.
+
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive behavior}.
+
address@hidden -r @var{tag}[:@var{date}]
+Tag the revision already tagged with @var{tag}, or when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{Tagging by date/tag} and @ref{Common options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden unedit address@hidden address@hidden@dots{}]
+Undo an edit command. See @ref{Editing files}.
+
address@hidden @code
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive behavior}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden update address@hidden address@hidden@dots{}]
+Bring work tree in sync with repository. See
address@hidden
+
address@hidden @code
address@hidden -A
+Reset any sticky tags/date/options. See @ref{Sticky
+tags} and @ref{Keyword substitution}.
+
address@hidden -C
+Overwrite locally modified files with clean copies from
+the repository (the modified file is saved in
address@hidden@address@hidden, however).
+
address@hidden -D @var{date}
+Check out revisions as of @var{date} (is sticky). See
address@hidden options}.
+
address@hidden -d
+Create directories. See @ref{update options}.
+
address@hidden -f
+Use head revision if tag/date not found. See
address@hidden options}.
+
address@hidden -I @var{ign}
+More files to ignore (! to reset). See
address@hidden options}.
+
address@hidden Probably want to use rev1/rev2 style like for diff
address@hidden -r. Here and in on-line help.
address@hidden -j @var{tag}[:@var{date}]
+Merge in changes from revisions specified by @var{tag} or, when @var{date} is
+specified and @var{tag} is a branch tag, the version from the branch @var{tag}
+as it existed on @var{date}. See @ref{update options}.
+
address@hidden -k @var{kflag}
+Use @var{kflag} keyword expansion. See
address@hidden modes}.
+
address@hidden -l
+Local; run only in current working directory. @xref{Recursive behavior}.
+
address@hidden -P
+Prune empty directories. See @ref{Moving directories}.
+
address@hidden -p
+Check out files to standard output (avoids
+stickiness). See @ref{update options}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
address@hidden -r @var{tag}[:@var{date}]
+Checkout the revisions specified by @var{tag} or, when @var{date} is specified
+and @var{tag} is a branch tag, the version from the branch @var{tag} as it
+existed on @var{date}. See @ref{Common options}.
+
address@hidden -W @var{spec}
+More wrappers. See @ref{import options}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden version
address@hidden version (subcommand)
+
+Display the version of @sc{cvs} being used. If the repository
+is remote, display both the client and server versions.
+
address@hidden ------------------------------------------------------------
address@hidden watch [on|off|add|remove] address@hidden address@hidden@dots{}]
+
+on/off: turn on/off read-only checkouts of files. See
address@hidden a watch}.
+
+add/remove: add or remove notification on actions. See
address@hidden Notified}.
+
address@hidden @code
address@hidden -a @var{actions}
+Specify actions for temporary watch, where
address@hidden is @code{edit}, @code{unedit},
address@hidden, @code{all}, or @code{none}. See
address@hidden files}.
+
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
address@hidden table
+
address@hidden ------------------------------------------------------------
address@hidden watchers address@hidden address@hidden@dots{}]
+See who is watching a file. See @ref{Watch information}.
+
address@hidden @code
address@hidden -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
address@hidden -R
+Operate recursively (default). @xref{Recursive
+behavior}.
address@hidden table
+
address@hidden table
+
address@hidden
---------------------------------------------------------------------
address@hidden Administrative files
address@hidden Reference manual for Administrative files
address@hidden Administrative files (reference)
address@hidden Files, reference manual
address@hidden Reference manual (files)
address@hidden CVSROOT (file)
+
+Inside the repository, in the directory
address@hidden/CVSROOT}, there are a number of
+supportive files for @sc{cvs}. You can use @sc{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 @ref{Intro
+administrative files}.
+
+The most important of these files is the @file{modules}
+file, which defines the modules inside the repository.
+
address@hidden
+* modules:: Defining modules
+* Wrappers:: Specify binary-ness based on file name
+* Trigger Scripts:: Launch scripts in response to server events
+* rcsinfo:: Templates for the log messages
+* cvsignore:: Ignoring files via cvsignore
+* checkoutlist:: Adding your own administrative files
+* history file:: History information
+* Variables:: Various variables are expanded
+* config:: Miscellaneous CVS configuration
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden modules
address@hidden The modules file
address@hidden Modules (admin file)
address@hidden Defining modules (reference manual)
+
+The @file{modules} file records your definitions of
+names for collections of source code. @sc{cvs} will
+use these definitions if you use @sc{cvs} to update the
+modules file (use normal commands like @code{add},
address@hidden, etc).
+
+The @file{modules} file may contain blank lines and
+comments (lines beginning with @samp{#}) as well as
+module definitions. Long lines can be continued on the
+next line by specifying a backslash (@samp{\}) as the
+last character on the line.
+
+There are three basic types of modules: alias modules,
+regular modules, and ampersand modules. The difference
+between them is the way that they map files in the
+repository to files in the working directory. In all
+of the following examples, the top-level repository
+contains a directory called @file{first-dir}, which
+contains two files, @file{file1} and @file{file2}, and a
+directory @file{sdir}. @file{first-dir/sdir} contains
+a file @file{sfile}.
+
address@hidden FIXME: should test all the examples in this section.
+
address@hidden
+* Alias modules:: The simplest kind of module
+* Regular modules::
+* Ampersand modules::
+* Excluding directories:: Excluding directories from a module
+* Module options:: Regular and ampersand modules can take options
+* Module program options:: How the modules ``program options'' programs
+ are run.
address@hidden menu
+
address@hidden Alias modules
address@hidden Alias modules
address@hidden Alias modules
address@hidden -a, in modules file
+
+Alias modules are the simplest kind of module:
+
address@hidden @code
address@hidden @var{mname} -a @address@hidden
+This represents the simplest way of defining a module
address@hidden The @samp{-a} flags the definition as a
+simple alias: @sc{cvs} will treat any use of @var{mname} (as
+a command argument) as if the list of names
address@hidden had been specified instead.
address@hidden may contain either other module names or
+paths. When you use paths in aliases, @code{checkout}
+creates all intermediate directories in the working
+directory, just as if the path had been specified
+explicitly in the @sc{cvs} arguments.
address@hidden table
+
+For example, if the modules file contains:
+
address@hidden
+amodule -a first-dir
address@hidden example
+
address@hidden
+then the following two commands are equivalent:
+
address@hidden
+$ cvs co amodule
+$ cvs co first-dir
address@hidden example
+
address@hidden
+and they each would provide output such as:
+
address@hidden
+cvs checkout: Updating first-dir
+U first-dir/file1
+U first-dir/file2
+cvs checkout: Updating first-dir/sdir
+U first-dir/sdir/sfile
address@hidden example
+
address@hidden Regular modules
address@hidden Regular modules
address@hidden Regular modules
+
address@hidden @code
address@hidden @var{mname} [ options ] @var{dir} [ @address@hidden ]
+In the simplest case, this form of module definition
+reduces to @address@hidden @var{dir}}. This defines
+all the files in directory @var{dir} as module mname.
address@hidden is a relative path (from @code{$CVSROOT}) to a
+directory of source in the source repository. In this
+case, on checkout, a single directory called
address@hidden is created as a working directory; no
+intermediate directory levels are used by default, even
+if @var{dir} was a path involving several directory
+levels.
address@hidden table
+
+For example, if a module is defined by:
+
address@hidden
+regmodule first-dir
address@hidden example
+
address@hidden
+then regmodule will contain the files from first-dir:
+
address@hidden
+$ cvs co regmodule
+cvs checkout: Updating regmodule
+U regmodule/file1
+U regmodule/file2
+cvs checkout: Updating regmodule/sdir
+U regmodule/sdir/sfile
+$
address@hidden example
+
+By explicitly specifying files in the module definition
+after @var{dir}, you can select particular files from
+directory @var{dir}. Here is
+an example:
+
address@hidden
+regfiles first-dir/sdir sfile
address@hidden example
+
address@hidden
+With this definition, getting the regfiles module
+will create a single working directory
address@hidden containing the file listed, which
+comes from a directory deeper
+in the @sc{cvs} source repository:
+
address@hidden
+$ cvs co regfiles
+U regfiles/sfile
+$
address@hidden example
+
address@hidden Ampersand modules
address@hidden Ampersand modules
address@hidden Ampersand modules
address@hidden &, in modules file
+
+A module definition can refer to other modules by
+including @samp{&@var{module}} in its definition.
address@hidden
address@hidden [ options ] @var{&address@hidden
address@hidden example
+
+Then getting the module creates a subdirectory for each such
+module, in the directory containing the module. For
+example, if modules contains
+
address@hidden
+ampermod &first-dir
address@hidden example
+
address@hidden
+then a checkout will create an @code{ampermod} directory
+which contains a directory called @code{first-dir},
+which in turns contains all the directories and files
+which live there. For example, the command
+
address@hidden
+$ cvs co ampermod
address@hidden example
+
address@hidden
+will create the following files:
+
address@hidden
+ampermod/first-dir/file1
+ampermod/first-dir/file2
+ampermod/first-dir/sdir/sfile
address@hidden example
+
+There is one quirk/bug: the messages that @sc{cvs}
+prints omit the @file{ampermod}, and thus do not
+correctly display the location to which it is checking
+out the files:
+
address@hidden
+$ cvs co ampermod
+cvs checkout: Updating first-dir
+U first-dir/file1
+U first-dir/file2
+cvs checkout: Updating first-dir/sdir
+U first-dir/sdir/sfile
+$
address@hidden example
+
+Do not rely on this buggy behavior; it may get fixed in
+a future release of @sc{cvs}.
+
address@hidden FIXCVS: What happens if regular and & modules are
address@hidden combined, as in "ampermodule first-dir &second-dir"?
address@hidden When I tried it, it seemed to just ignore the
address@hidden "first-dir". I think perhaps it should be an error
address@hidden (but this needs further investigation).
address@hidden In addition to discussing what each one does, we
address@hidden should put in a few words about why you would use one or
address@hidden the other in various situations.
+
address@hidden Excluding directories
address@hidden Excluding directories
address@hidden Excluding directories, in modules file
address@hidden !, in modules file
+
+An alias module may exclude particular directories from
+other modules by using an exclamation mark (@samp{!})
+before the name of each directory to be excluded.
+
+For example, if the modules file contains:
+
address@hidden
+exmodule -a !first-dir/sdir first-dir
address@hidden example
+
address@hidden
+then checking out the module @samp{exmodule} will check
+out everything in @samp{first-dir} except any files in
+the subdirectory @samp{first-dir/sdir}.
address@hidden Note that the "!first-dir/sdir" sometimes must be listed
address@hidden before "first-dir". That seems like a probable bug, in which
address@hidden case perhaps it should be fixed (to allow either
address@hidden order) rather than documented. See modules4 in testsuite.
+
address@hidden Module options
address@hidden Module options
address@hidden Options, in modules file
+
+Either regular modules or ampersand modules can contain
+options, which supply additional information concerning
+the module.
+
address@hidden @code
address@hidden -d, in modules file
address@hidden -d @var{name}
+Name the working directory something other than the
+module name.
address@hidden FIXME: Needs a bunch of examples, analogous to the
address@hidden examples for alias, regular, and ampersand modules
address@hidden which show where the files go without -d.
+
address@hidden Export program
address@hidden -e, in modules file
address@hidden -e @var{prog}
+Specify a program @var{prog} to run whenever files in a
+module are exported. @var{prog} runs with a single
+argument, the module name.
address@hidden FIXME: Is it run on server? client?
+
address@hidden Checkout program
address@hidden -o, in modules file
address@hidden -o @var{prog}
+Specify a program @var{prog} to run whenever files in a
+module are checked out. @var{prog} runs with a single
+argument, the module name. See @ref{Module program options} for
+information on how @var{prog} is called.
address@hidden FIXME: Is it run on server? client?
+
address@hidden Status of a module
address@hidden Module status
address@hidden -s, in modules file
address@hidden -s @var{status}
+Assign a status to the module. When the module file is
+printed with @samp{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.
+
address@hidden Tag program
address@hidden -t, in modules file
address@hidden -t @var{prog}
+Specify a program @var{prog} to run whenever files in a
+module are tagged with @code{rtag}. @var{prog} runs
+with two arguments: the module name and the symbolic
+tag specified to @code{rtag}. It is not run
+when @code{tag} is executed. Generally you will find
+that the @file{taginfo} file is a better solution (@pxref{taginfo}).
address@hidden FIXME: Is it run on server? client?
address@hidden Problems with -t include:
address@hidden * It is run after the tag not before
address@hidden * It doesn't get passed all the information that
address@hidden taginfo does ("mov", &c).
address@hidden * It only is run for rtag, not tag.
address@hidden table
+
+You should also see @pxref{Module program options} about how the
+``program options'' programs are run.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
+
address@hidden Module program options
address@hidden How the modules file ``program options'' programs are run
address@hidden Modules file program options
address@hidden -t, in modules file
address@hidden -o, in modules file
address@hidden -e, in modules file
+
address@hidden
+For checkout, rtag, and export, the program is server-based, and as such the
+following applies:-
+
+If using remote access methods (pserver, ext, etc.),
address@hidden will execute this program on the server from a temporary
+directory. The path is searched for this program.
+
+If using ``local access'' (on a local or remote NFS file system, i.e.
+repository set just to a path),
+the program will be executed from the newly checked-out tree, if
+found there, or alternatively searched for in the path if not.
+
+The programs are all run after the operation has effectively
+completed.
+
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Wrappers
address@hidden The cvswrappers file
address@hidden cvswrappers (admin file)
address@hidden CVSWRAPPERS, environment variable
address@hidden Wrappers
+
address@hidden FIXME: need some better way of separating this out
address@hidden by functionality. -m is
address@hidden one feature, and -k is a another. And this discussion
address@hidden should be better motivated (e.g. start with the
address@hidden problems, then explain how the feature solves it).
+
+Wrappers refers to a @sc{cvs} feature which lets you
+control certain settings based on the name of the file
+which is being operated on. The settings are @samp{-k}
+for binary files, and @samp{-m} for nonmergeable text
+files.
+
+The @samp{-m} option
+specifies the merge methodology that should be used when
+a non-binary file is updated. @code{MERGE} means the usual
address@hidden behavior: try to merge the files. @code{COPY}
+means that @code{cvs update} will refuse to merge
+files, as it also does for files specified as binary
+with @samp{-kb} (but if the file is specified as
+binary, there is no need to specify @samp{-m 'COPY'}).
address@hidden will provide the user with the
+two versions of the files, and require the user using
+mechanisms outside @sc{cvs}, to insert any necessary
+changes.
+
address@hidden: do not use @code{COPY} with
address@hidden 1.9 or earlier - such versions of @sc{cvs} will
+copy one version of your file over the other, wiping
+out the previous contents.}
address@hidden Ordinarily we don't document the behavior of old
address@hidden versions. But this one is so dangerous, I think we
address@hidden must. I almost renamed it to -m 'NOMERGE' so we
address@hidden could say "never use -m 'COPY'".
+The @samp{-m} wrapper option only affects behavior when
+merging is done on update; it does not affect how files
+are stored. See @ref{Binary files}, for more on
+binary files.
+
+The basic format of the file @file{cvswrappers} is:
+
address@hidden FIXME: @example is all wrong for this. Use @deffn or
address@hidden something more sensible.
address@hidden
+wildcard [option value][option value]...
+
+where option is one of
+-m update methodology value: MERGE or COPY
+-k keyword expansion value: expansion mode
+
+and value is a single-quote delimited value.
address@hidden example
+
address@hidden
address@hidden
+*.nib -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
+*.c -t 'indent %s %s'
address@hidden example
address@hidden When does the filter need to be an absolute pathname
address@hidden and when will something like the above work? I
address@hidden suspect it relates to the PATH of the server (which
address@hidden in turn depends on all kinds of stuff, e.g. inetd
address@hidden for pserver). I'm not sure whether/where to discuss
address@hidden this.
address@hidden FIXME: What do the %s's stand for?
+
address@hidden
+The above example of a @file{cvswrappers} file
+states that all files/directories that end with a @code{.nib}
+should be filtered with the @file{wrap} program before
+checking the file into the repository. The file should
+be filtered though the @file{unwrap} program when the
+file is checked out of the repository. The
address@hidden file also states that a @code{COPY}
+methodology should be used when updating the files in
+the repository (that is, no merging should be performed).
+
address@hidden What pitfalls arise when using indent this way? Is
address@hidden it a winning thing to do? Would be nice to at least
address@hidden hint at those issues; we want our examples to tell
address@hidden how to solve problems, not just to say that cvs can
address@hidden do certain things.
+The last example line says that all files that end with
address@hidden should be filtered with @file{indent}
+before being checked into the repository. Unlike the previous
+example, no filtering of the @code{.c} file is done when
+it is checked out of the repository.
address@hidden
+The @code{-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.
+
address@hidden
+The @code{-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.
+
+Note that the @samp{-t}/@samp{-f} features do not
+conveniently handle one portion of @sc{cvs}'s operation:
+determining when files are modified. @sc{cvs} will still
+want a file (or directory) to exist, and it will use
+its modification time to determine whether a file is
+modified. If @sc{cvs} erroneously thinks a file is
+unmodified (for example, a directory is unchanged but
+one of the files within it is changed), you can force
+it to check in the file anyway by specifying the
address@hidden option to @code{cvs commit} (@pxref{commit
+options}).
address@hidden This is, of course, a serious design flaw in -t/-f.
address@hidden Probably the whole functionality needs to be
address@hidden redesigned (starting from requirements) to fix this.
address@hidden ignore
+
address@hidden FIXME: We don't document -W or point to where it is
address@hidden documented. Or .cvswrappers.
+For example, the following command imports a
+directory, treating files whose name ends in
address@hidden as binary:
+
address@hidden
+cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
address@hidden example
+
address@hidden Another good example, would be storing files
address@hidden (e.g. binary files) compressed in the repository.
address@hidden ::::::::::::::::::
address@hidden cvswrappers
address@hidden ::::::::::::::::::
address@hidden *.t12 -m 'COPY'
address@hidden *.t[0-9][0-9] -f 'gunzipcp %s' -t 'gzipcp %s %s' -m 'COPY'
address@hidden
address@hidden ::::::::::::::::::
address@hidden gunzipcp
address@hidden ::::::::::::::::::
address@hidden :
address@hidden [ -f $1 ] || exit 1
address@hidden zcat $1 > /tmp/.#$1.$$
address@hidden mv /tmp/.#$1.$$ $1
address@hidden
address@hidden ::::::::::::::::::
address@hidden gzipcp
address@hidden ::::::::::::::::::
address@hidden :
address@hidden DIRNAME=`echo $1 | sed -e "s|/.*/||g"`
address@hidden if [ ! -d $DIRNAME ] ; then
address@hidden DIRNAME=`echo $1 | sed -e "s|.*/||g"`
address@hidden fi
address@hidden gzip -c $DIRNAME > $2
address@hidden One catch--"cvs diff" will not invoke the wrappers
address@hidden (probably a CVS bug, although I haven't thought it out).
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Trigger Scripts
address@hidden The Trigger Scripts
address@hidden info files
address@hidden trigger scripts
address@hidden script hooks
+
address@hidden FIXME
address@hidden Somewhere there needs to be a more "how-to" guide to writing
these.
address@hidden One particular issue that people sometimes are worried about is
performance,
address@hidden and the impact of writing in perl or sh or ____. Performance
comparisons
address@hidden should probably remain outside the scope of this document, but
at least
address@hidden _that_ much could be referenced, perhaps with links to other
sources.
+
+Several of the administrative files support triggers, or the launching external
+scripts or programs at specific times before or after particular events, during
+the execution of @sc{cvs} commands. These hooks can be used to prevent certain
+actions, log them, and/or maintain anything else you deem practical.
+
+All the trigger scripts are launched in a copy of the user sandbox being
+committed, on the server, in client-server mode. In local mode, the scripts
+are actually launched directly from the user sandbox directory being committed.
+For most intents and purposes, the same scripts can be run in both locations
+without alteration.
+
address@hidden
+* syntax:: The common syntax
+* Trigger Script Security:: Trigger script security
+
+* commit files:: The commit support files (commitinfo,
+ verifymsg, loginfo)
+* commitinfo:: Pre-commit checking
+* verifymsg:: How are log messages evaluated?
+* loginfo:: Where should log messages be sent?
+
+* postadmin:: Logging admin commands
+* taginfo:: Verifying/Logging tags
+* posttag:: Logging tags
+* postwatch:: Logging watch commands
+
+* preproxy:: Launch a script on a secondary server prior
+ to becoming a write proxy
+* postproxy:: Launch a script on a secondary server after
+ completing proxy operations
address@hidden menu
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden syntax
address@hidden The common syntax
address@hidden info files, common syntax
address@hidden script hooks, common syntax
address@hidden trigger script hooks, common syntax
address@hidden syntax of trigger script hooks
+
address@hidden FIXME: having this so totally separate from the
address@hidden Variables node is rather bogus.
+
+The administrative files such as @file{commitinfo},
address@hidden, @file{rcsinfo}, @file{verifymsg}, etc.,
+all have a common format. The purpose of the files are
+described later on. The common syntax is described
+here.
+
address@hidden Regular expression syntax
+Each line contains the following:
+
address@hidden @bullet
address@hidden @samp{ALL} keyword, in lieu of regular expressions in script
hooks
address@hidden @samp{DEFAULT} keyword, in lieu of regular expressions in script
hooks
address@hidden
+A regular expression or the literal string @samp{DEFAULT}. Some script hooks
+also support the literal string @samp{ALL}. Other than the @samp{ALL} and
address@hidden keywords, this is a basic regular expression in the syntax used
+by GNU emacs. See the descriptions of the individual script hooks for
+information on whether the @samp{ALL} keyword is supported
+(@pxref{Trigger Scripts}).
address@hidden FIXME: What we probably should be saying is "POSIX Basic
address@hidden Regular Expression with the following extensions (`\('
address@hidden `\|' '+' etc)"
address@hidden rather than define it with reference to emacs.
address@hidden The reference to emacs is not strictly speaking
address@hidden true, as we don't support \=, \s, or \S. Also it isn't
address@hidden clear we should document and/or promise to continue to
address@hidden support all the obscure emacs extensions like \<.
address@hidden Also need to better cite (or include) full
address@hidden documentation for the syntax.
address@hidden Also see comment in configure.in about what happens to the
address@hidden syntax if we pick up a system-supplied regexp matcher.
+
address@hidden
+A whitespace separator---one or more spaces and/or tabs.
+
address@hidden
+A file name or command-line template.
address@hidden itemize
+
address@hidden
+Blank lines are ignored. Lines that start with the
+character @samp{#} are treated as comments. Long lines
+unfortunately can @emph{not} be broken in two parts in
+any way.
+
+The first regular expression that matches the current
+directory name in the repository or the first line containing @samp{DEFAULT}
+in lieu of a regular expression is used and all lines containing @samp{ALL} is
+used for the hooks which support the @samp{ALL} keyword. The rest of the line
+is used as a file name or command-line template as appropriate. See the
+descriptions of the individual script hooks for information on whether the
address@hidden keyword is supported (@pxref{Trigger Scripts}).
+
address@hidden format strings
address@hidden format strings, common syntax
address@hidden info files, common syntax, format strings
address@hidden Common syntax of info files, format strings
address@hidden
address@hidden: The following information on format strings is valid
+as long as the line @code{UseNewInfoFmtStrings=yes} appears in
+your repository's config file (@pxref{config}). Otherwise,
+default format strings may be appended to the command line and
+the @samp{loginfo} file, especially, can exhibit slightly
+different behavior. For more information,
address@hidden Commit Files}.}
+
+In the cases where the second segment of the matched line is a
+command line template (e.g. @file{commitinfo}, @file{loginfo},
+& @file{verifymsg}), the command line template may contain format
+strings which will be replaced with specific values before the
+script is run.
address@hidden FIXCVS then FIXME - it really would make sense to allow %r &
maybe even %p
address@hidden to be used in rcsinfo to construct a path, but I haven't
address@hidden coded this yet.
+
+Format strings can represent a single variable or one or more
+attributes of a list variable. An example of a list variable
+would be the list available to scripts hung on the loginfo hooks
+- the list of files which were just committed. In the case of
+loginfo, three attributes are available for each list item: file
+name, precommit version, and postcommit version.
+
+Format strings consist of a @samp{%} character followed by an optional
address@hidden@{} (required in the multiple list attribute case), a
+single format character representing a variable or a single attribute of
+list elements or multiple format characters representing attributes of
+list elements, and a closing @address@hidden when the open bracket was present.
+
address@hidden format strings}, or single format characters which get replaced
+with a single value, will generate a single argument
+to the called script, regardless of whether the replacement variable contains
+white space or other special characters.
+
address@hidden attributes} will generate an argument for each attribute
+requested for each list item. For example, @address@hidden@}}
+in a @file{loginfo} command template will generate three
+arguments (file name, precommit version, postcommit version,
+...) for each file committed. As in the flat format string
+case, each attribute will be passed in as a single argument
+regardless of whether it contains white space or other
+special characters.
+
address@hidden will be replaced with a literal @samp{%}.
+
+The format strings available to all script hooks are:
+
address@hidden @t
address@hidden c
+The canonical name of the command being executed. For instance, in the case of
+a hook run from @code{cvs up}, @sc{cvs} would replace @samp{%c} with the string
address@hidden and, in the case of a hook run from @code{cvs ci}, @sc{cvs} would
+replace @samp{%c} with the string @samp{commit}.
address@hidden n
+The null, or empty, string.
address@hidden p
+The name of the directory being operated on within the repository.
address@hidden r
+The name of the repository (the path portion of @code{$CVSROOT}).
address@hidden R
+On a server, the name of the referrer, if any. The referrer is the CVSROOT the
+client reports it used to contact a server which then referred it to this
+server. Should usually be set on a primary server with a write proxy setup.
address@hidden table
+
+Other format strings are file specific. See the docs on the
+particular script hooks for more information
+(@pxref{Trigger Scripts}).
+
+As an example, the following line in a @file{loginfo} file would
+match only the directory @file{module} and any subdirectories of
address@hidden:
+
address@hidden
+^module\(/\|$\) (echo; echo %p; echo address@hidden@}; cat)
>>$CVSROOT/CVSROOT/commitlog
address@hidden example
+
+Using this same line and assuming a commit of new revisions
+1.5.4.4 and 1.27.4.1 based on old revisions 1.5.4.3 and 1.27,
+respectively, of file1 and file2 in module, something like the
+following log message should be appended to commitlog:
+
address@hidden
+
+module
+file1 1.5.4.3 1.5.4.4 file2 1.27 1.27.4.1
+Update of /cvsroot/module
+In directory localhost.localdomain:/home/jrandom/work/module
+
+Modified Files:
+ file1 file2
+Log Message:
+A log message.
address@hidden example
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden Trigger Script Security
address@hidden Security and the Trigger Scripts
address@hidden info files, security
address@hidden script hooks, security
address@hidden trigger scripts, security
+
+Security is a huge subject, and implementing a secure system is a non-trivial
+task. This section will barely touch on all the issues involved, but it is
+well to note that, as with any script you will be allowing an untrusted
+user to run on your server, there are measures you can take to help prevent
+your trigger scripts from being abused.
+
+For instance, since the CVS trigger scripts all run in a copy of the user's
+sandbox on the server, a naively coded Perl trigger script which attempts to
+use a Perl module that is not installed on the system can be hijacked by any
+user with commit access who is checking in a file with the correct name. Other
+scripting languages may be vulnerable to similar hacks.
+
+One way to make a script more secure, at least with Perl, is to use scripts
+which invoke the @code{-T}, or "taint-check" switch on their @code{#!} line.
+In the most basic terms, this causes Perl to avoid running code that may have
+come from an external source. Please run the @code{perldoc perlsec} command
+for more on Perl security. Again, other languages may implement other security
+verification hooks which look more or less like Perl's "taint-check" mechanism.
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden commit files
address@hidden The commit support files
address@hidden Commits, administrative support files
address@hidden commit files, see Info files
+
+The @samp{-i} flag in the @file{modules} file can be
+used to run a certain program whenever files are
+committed (@pxref{modules}). The files described in
+this section provide other, more flexible, ways to run
+programs whenever something is committed.
+
+There are three kinds 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.
+
address@hidden @file
address@hidden 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. @xref{commitinfo}.
+
address@hidden verifymsg
+The specified program is used to evaluate the log message,
+and possibly verify that it contains all required
+fields. This is most useful in combination with the
address@hidden file, which can hold a log message
+template (@pxref{rcsinfo}). @xref{verifymsg}.
+
address@hidden 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, address@hidden Your
+imagination is the limit! @xref{loginfo}.
address@hidden table
+
address@hidden
+* Updating Commit Files:: Updating legacy repositories to stop using
+ deprecated command line template formats
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden Updating Commit Files
address@hidden Updating legacy repositories to stop using deprecated command
line template formats
address@hidden info files, common syntax, updating legacy repositories
address@hidden Syntax of info files, updating legacy repositories
address@hidden Common syntax of info files, updating legacy repositories
+New repositories are created set to use the new format strings by default, so
+if you are creating a new repository, you shouldn't have to worry about this
+section.
+
+If you are attempting to maintain a legacy repository which was
+making use of the @file{commitinfo}, @file{editinfo}, @file{verifymsg},
address@hidden, and/or @file{taginfo} script hooks, you should have no
+immediate problems with using the current @sc{cvs} executable, but your users
+will probably start to see deprecation warnings.
+
+The reason for this is that all of the script hooks have been updated to
+use a new command line parser that extensibly supports multiple
address@hidden & @file{notify} style format strings (@pxref{syntax})
+and this support is not completely compatible with the old style format
+strings.
+
+The quick upgrade method is to stick a @samp{1} after each format string
+in your old @file{loginfo} file. For example:
+
address@hidden
+DEFAULT (echo ""; id; echo address@hidden@}; date; cat) >>
$CVSROOT/CVSROOT/commitlog
address@hidden example
+
+would become:
+
address@hidden
+DEFAULT (echo ""; id; echo address@hidden@}; date; cat) >>
$CVSROOT/CVSROOT/commitlog
address@hidden example
+
+If you were counting on the fact that only the first @samp{%} in the line was
+replaced as a format string, you may also have to double up any further
+percent signs on the line.
+
+If you did this all at once and checked it in, everything should still be
+running properly.
+
+Now add the following line to your config file (@pxref{config}):
address@hidden
+UseNewInfoFmtStrings=yes
address@hidden example
+
+Everything should still be running properly, but your users will probably
+start seeing new deprecation warnings.
+
+Dealing with the deprecation warnings now generated by @file{commitinfo},
address@hidden, @file{verifymsg}, and @file{taginfo} should be easy. Simply
+specify what are currently implicit arguments explicitly. This means appending
+the following strings to each active command line template in each file:
address@hidden @code
address@hidden commitinfo
address@hidden %r/%p %s}
address@hidden editinfo
address@hidden %l}
address@hidden taginfo
address@hidden %t %o %p address@hidden@}}
address@hidden verifymsg
address@hidden %l}
address@hidden table
+
+If you don't desire that any of the newly available information be passed to
+the scripts hanging off of these hooks, no further modifications to these
+files should be necessary to insure current and future compatibility with
address@hidden's format strings.
+
+Fixing @file{loginfo} could be a little tougher. The old style
address@hidden format strings caused a single space and comma separated
+argument to be passed in in place of the format string. This is what will
+continue to be generated due to the deprecated @samp{1} you inserted into
+the format strings.
+
+Since the new format separates each individual item and passes it into the
+script as a separate argument (for a good reason - arguments containing commas
+and/or white space are now parsable), to remove the deprecated @samp{1} from
+your @file{loginfo} command line templates, you will most likely have to
+rewrite any scripts called by the hook to handle the new argument format.
+
+Also note that the way @samp{%} followed by unrecognized characters and by
address@hidden@address@hidden was treated in past versions of CVS is not
strictly adhered to as
+there were bugs in the old versions. Specifically, @address@hidden@}} would
eat the
+next character and unrecognized strings resolved only to the empty string,
+which was counter to what was stated in the documentation. This version will
+do what the documentation said it should have (if you were using only some
+combination of @address@hidden@}}, e.g. @address@hidden@}},
@address@hidden@}}, or
address@hidden, you should have no troubles).
+
+On the bright side, you should have plenty of time to do this before all
+support for the old format strings is removed from @sc{cvs}, so you can just
+put up with the deprecation warnings for awhile if you like.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden commitinfo
address@hidden Commitinfo
address@hidden @file{commitinfo}
address@hidden Commits, precommit verification of
address@hidden commitinfo (admin file)
address@hidden info files, commitinfo
address@hidden script hooks, commitinfo
address@hidden trigger scripts, commitinfo
address@hidden info files, precommit verification of commits
address@hidden script hooks, precommit verification of commits
address@hidden trigger scripts, precommit verification of commits
+
+The @file{commitinfo} file defines programs to execute
+whenever @samp{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.
+
+The @file{commitinfo} file has the standard form for script hooks
+(@pxref{Trigger Scripts}), where each line is a regular expression followed by
+a command to execute. It supports only the DEFAULT keywords.
+
address@hidden format strings, commitinfo admin file
+In addition to the common format strings (@pxref{syntax}),
address@hidden supports:
+
address@hidden @t
address@hidden @address@hidden
+a list of the names of files to be committed
address@hidden table
+
address@hidden commitinfo (admin file), updating legacy repositories
address@hidden compatibility notes, commitinfo admin file
+Currently, if no format strings are specified, a default
+string of @samp{ %r/%p address@hidden@}} will be appended to the command
+line template before replacement is performed, but this
+feature is deprecated. It is simply in place so that legacy
+repositories will remain compatible with the new @sc{cvs} application.
+For information on updating, @pxref{Updating Commit Files}.
+
address@hidden Exit status, of commitinfo
address@hidden commitinfo (admin file), exit status
+The first line with a regular expression matching the
+directory within the repository will be used. If the
+command returns a non-zero exit status the commit will
+be aborted.
address@hidden FIXME: need example(s) of what "directory within the
address@hidden repository" means.
+
address@hidden @file{commitinfo}, working directory
address@hidden @file{commitinfo}, command environment
+The command will be run in the root of the workspace
+containing the new versions of any files the user would like
+to modify (commit), @emph{or in a copy of the workspace on
+the server (@pxref{Remote repositories})}. If a file is
+being removed, there will be no copy of the file under the
+current directory. If a file is being added, there will be
+no corresponding archive file in the repository unless the
+file is being resurrected.
+
+Note that both the repository directory and the corresponding
+Attic (@pxref{Attic}) directory may need to be checked to
+locate the archive file corresponding to any given file being
+committed. Much of the information about the specific commit
+request being made, including the destination branch, commit
+message, and command line options specified, is not available
+to the command.
+
address@hidden FIXME: should discuss using commitinfo to control
address@hidden who has checkin access to what (e.g. Joe can check into
address@hidden directories a, b, and c, and Mary can check into
address@hidden directories b, c, and d--note this case cannot be
address@hidden conveniently handled with unix groups). Of course,
address@hidden adding a new set of features to CVS might be a more
address@hidden natural way to fix this problem than telling people to
address@hidden use commitinfo.
address@hidden FIXME: Should make some reference, especially in
address@hidden the context of controlling who has access, to the fact
address@hidden that commitinfo can be circumvented. Perhaps
address@hidden mention SETXID (but has it been carefully examined
address@hidden for holes?). This fits in with the discussion of
address@hidden general CVS security in "Password authentication
address@hidden security" (the bit which is not pserver-specific).
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden verifymsg
address@hidden Verifying log messages
address@hidden @file{verifymsg} (admin file)
address@hidden Log message, verifying
address@hidden logging, commits
+
+Once you have entered a log message, you can evaluate
+that message to check for specific content, such as
+a bug ID. Use the @file{verifymsg} file to
+specify a program that is used to verify the log message.
+This program could be a simple script that checks
+that the entered message contains the required fields.
+
+The @file{verifymsg} file is often most useful together
+with the @file{rcsinfo} file, which can be used to
+specify a log message template (@pxref{rcsinfo}).
+
+The @file{verifymsg} file has the standard form for script hooks
+(@pxref{Trigger Scripts}), where each line is a regular expression followed by
+a command to execute. It supports only the DEFAULT keywords.
+
address@hidden format strings, verifymsg admin file
+In addition to the common format strings (@pxref{syntax}),
address@hidden supports:
+
address@hidden @t
address@hidden l
+the full path to the file containing the log message to be verified
address@hidden @address@hidden
+File attributes, where:
address@hidden @t
address@hidden s
+file name
address@hidden V
+old version number (pre-checkin)
address@hidden table
address@hidden table
+
address@hidden verifymsg (admin/commit file), updating legacy repositories
address@hidden compatibility notes, verifymsg admin file
+Currently, if no format strings are specified, a default
+string of @samp{ %l} will be appended to the command
+line template before replacement is performed, but this
+feature is deprecated. It is simply in place so that legacy
+repositories will remain compatible with the new @sc{cvs} application.
+For information on updating, @pxref{Updating Commit Files}.
+
+One thing that should be noted is that the @samp{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 verification script in a
+directory, and then overriding it in a subdirectory.
+
address@hidden Exit status, of @file{verifymsg}
+If the verification script exits with a non-zero exit status,
+the commit is aborted.
+
address@hidden @file{verifymsg}, changing the log message
+In the default configuration, CVS allows the
+verification script to change the log message. This is
+controlled via the RereadLogAfterVerify CVSROOT/config
+option.
+
+When @samp{RereadLogAfterVerify=always} or
address@hidden, the log message will
+either always be reread after the verification script
+is run or reread only if the log message file status
+has changed.
+
address@hidden, for more on CVSROOT/config options.
+
+It is NOT a good idea for a @file{verifymsg} script to
+interact directly with the user in the various
+client/server methods. For the @code{pserver} method,
+there is no protocol support for communicating between
address@hidden and the client on the remote end. For the
address@hidden and @code{server} methods, it is possible
+for CVS to become confused by the characters going
+along the same channel as the CVS protocol
+messages. See @ref{Remote repositories}, for more
+information on client/server setups. In addition, at the time
+the @file{verifymsg} script runs, the CVS
+server has locks in place in the repository. If control is
+returned to the user here then other users may be stuck waiting
+for access to the repository.
+
+This option can be useful if you find yourself using an
+rcstemplate that needs to be modified to remove empty
+elements or to fill in default values. It can also be
+useful if the rcstemplate has changed in the repository
+and the CVS/Template was not updated, but is able to be
+adapted to the new format by the verification script
+that is run by @file{verifymsg}.
+
+An example of an update might be to change all
+occurrences of 'BugId:' to be 'DefectId:' (which can be
+useful if the rcstemplate has recently been changed and
+there are still checked-out user trees with cached
+copies in the CVS/Template file of the older version).
+
+Another example of an update might be to delete a line
+that contains 'BugID: none' from the log message after
+validation of that value as being allowed is made.
+
address@hidden
+* verifymsg example:: Verifymsg example
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden verifymsg example
address@hidden Verifying log messages
address@hidden verifymsg, example
+The following is a little silly example of a
address@hidden file, together with the corresponding
address@hidden file, the log message template and a
+verification 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
address@hidden/usr/cvssupport/tc.template}.
+
address@hidden
+BugId:
address@hidden example
+
+The script @file{/usr/cvssupport/bugid.verify} is used to
+evaluate the log message.
+
address@hidden
+#!/bin/sh
+#
+# bugid.verify filename
+#
+# Verify that the log message contains a valid bugid
+# on the first line.
+#
+if sed 1q < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
+ exit 0
+elif sed 1q < $1 | grep '^BugId:[ ]*none$' > /dev/null; then
+ # It is okay to allow commits with 'BugId: none',
+ # but do not put that text into the real log message.
+ grep -v '^BugId:[ ]*none$' > $1.rewrite
+ mv $1.rewrite $1
+ exit 0
+else
+ echo "No BugId found."
+ exit 1
+fi
address@hidden example
+
+The @file{verifymsg} file contains this line:
+
address@hidden
+^tc /usr/cvssupport/bugid.verify %l
address@hidden example
+
+The @file{rcsinfo} file contains this line:
+
address@hidden
+^tc /usr/cvssupport/tc.template
address@hidden example
+
+The @file{config} file contains this line:
+
address@hidden
+RereadLogAfterVerify=always
address@hidden example
+
+
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden loginfo
address@hidden Loginfo
address@hidden loginfo (admin file)
address@hidden logging, commits
address@hidden Storing log messages
address@hidden Mailing log messages
address@hidden Distributing log messages
address@hidden Log messages
+
+The @file{loginfo} file is used to control where log information is sent after
+versioned changes are made to repository archive files and after directories
+are added to the repository. @ref{posttag} for how to log tagging
+information and @ref{postadmin} for how to log changes due to the @code{admin}
+command.
+
+The @file{loginfo} file has the standard form for script hooks
+(@pxref{Trigger Scripts}), where each line is a regular expression followed by
+a command to execute. It supports the ALL and DEFAULT keywords.
+
+Any specified scripts are called:
+
address@hidden @code
address@hidden commit
+Once per directory, immediately after a successfully completing the commit of
+all files within that directory.
address@hidden import
+Once per import, immediately after completion of all write operations.
address@hidden add
+Immediately after the successful @code{add} of a directory.
address@hidden table
+
+Any script called via @file{loginfo} will be fed the log information on its
+standard input. Note that the filter program @strong{must} read @strong{all}
+of the log information from its standard input or @sc{cvs} may fail with a
+broken pipe signal.
+
address@hidden format strings, loginfo admin file
+In addition to the common format strings (@pxref{syntax}),
address@hidden supports:
+
address@hidden @t
address@hidden @address@hidden
+File attributes, where:
address@hidden @t
address@hidden s
+file name
address@hidden T
+tag name of destination, or the empty string when there is no associated
+tag name (this usually means the trunk)
address@hidden V
+old version number (pre-checkin)
address@hidden v
+new version number (post-checkin)
address@hidden table
address@hidden table
+
+For example, some valid format strings are @samp{%%},
address@hidden, @address@hidden@}}, and @address@hidden@}}.
+
address@hidden loginfo (admin file), updating legacy repositories
address@hidden compatibility notes, loginfo admin file
+Currently, if @samp{UseNewInfoFmtStrings} is not set in the @file{config}
+administration file (@pxref{config}), the format strings will be substituted
+as they were in past versions of @sc{cvs}, but this feature is deprecated.
+It is simply in place so that legacy repositories will remain compatible with
+the new @sc{cvs} application. For information on updating,
+please see @ref{Updating Commit Files}.
+
+As an example, if @samp{/u/src/master/yoyodyne/tc} is the repository, @samp{%p}
+and @address@hidden@}} are the format strings, and three files (@t{ChangeLog},
address@hidden, @t{foo.c}) were modified, the output might be:
+
address@hidden
+yoyodyne/tc ChangeLog 1.1 1.2 Makefile 1.3 1.4 foo.c 1.12 1.13
address@hidden example
+
+Note: when @sc{cvs} is accessing a remote repository,
address@hidden will be run on the @emph{remote}
+(i.e., server) side, not the client side (@pxref{Remote
+repositories}).
+
address@hidden
+* loginfo example:: Loginfo example
+* Keeping a checked out copy:: Updating a tree on every checkin
address@hidden menu
+
address@hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
address@hidden loginfo example
address@hidden Loginfo example
+
+The following @file{loginfo} file, together with the
+tiny shell-script below, appends all log messages
+to the file @file{$CVSROOT/CVSROOT/commitlog},
+and any commits to the administrative files (inside
+the @file{CVSROOT} directory) are also logged in
address@hidden/usr/adm/cvsroot-log}.
+Commits to the @file{prog1} directory are mailed to @t{ceder}.
+
address@hidden FIXME: is it a CVS feature or bug that only the
address@hidden first matching line is used? It is documented
address@hidden above, but is it useful? For example, if we wanted
address@hidden to run both "cvs-log" and "Mail" for the CVSROOT
address@hidden directory, it is kind of awkward if
address@hidden only the first matching line is used.
address@hidden
+ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER
+^CVSROOT\(/\|$\) /usr/local/bin/cvs-log /usr/adm/cvsroot-log $USER
+^prog1\(/\|$\) Mail -s "%p %s" ceder
address@hidden example
+
+The shell-script @file{/usr/local/bin/cvs-log} looks
+like this:
+
address@hidden
+#!/bin/sh
+(echo "------------------------------------------------------";
+ echo -n "$2 ";
+ date;
+ echo;
+ cat) >> $1
address@hidden example
+
+
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden Keeping a checked out copy
address@hidden Keeping a checked out copy
+
address@hidden What other index entries? It seems like
address@hidden people might want to use a lot of different
address@hidden words for this functionality.
address@hidden Keeping a checked out copy
address@hidden Checked out copy, keeping
address@hidden Web pages, maintaining with CVS
+
+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 @sc{cvs} and want every checkin to cause the files
+used by the web server to be updated.
address@hidden Can we offer more details on the web example? Or
address@hidden point the user at how to figure it out? This text
address@hidden strikes me as sufficient for someone who already has
address@hidden some idea of what we mean but not enough for the naive
address@hidden user/sysadmin to understand it and set it up.
+
+The way to do this is by having loginfo invoke
address@hidden update}. Doing so in the naive way will
+cause a problem with locks, so the @code{cvs update}
+must be run in the background.
address@hidden Should we try to describe the problem with locks?
address@hidden It seems like a digression for someone who just
address@hidden wants to know how to make it work.
address@hidden Another choice which might work for a single file
address@hidden is to use "cvs -n update -p" which doesn't take
address@hidden out locks (I think) but I don't see many advantages
address@hidden of that and we might as well document something which
address@hidden works for multiple files.
+Here is an example for unix (this should all be on one line):
+
address@hidden
+^cyclic-pages\(/\|$\) (date; cat; (sleep 2; cd /u/www/local-docs;
+ cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
address@hidden example
+
+This will cause checkins to repository directory @code{cyclic-pages}
+and its subdirectories to update the checked
+out tree in @file{/u/www/local-docs}.
address@hidden More info on some of the details? The "sleep 2" is
address@hidden so if we are lucky the lock will be gone by the time
address@hidden we start and we can wait 2 seconds instead of 30.
+
+
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden postadmin
address@hidden Logging admin commands
address@hidden postadmin (admin file)
address@hidden script hook, postadmin
address@hidden Admin commands, logging
+
+The @file{postadmin} file defines programs to execute after an @code{admin}
+command modifies files. The @file{postadmin} file has the standard form
+for script hooks (@pxref{Trigger Scripts}), where each line is a regular
+expression followed by a command to execute. It supports the ALL and DEFAULT
+keywords.
+
address@hidden format strings, postadmin admin file
+The @file{postadmin} file supports no format strings other than the common
+ones (@pxref{syntax}),
+
+
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden taginfo
address@hidden Taginfo
address@hidden taginfo (admin file)
address@hidden script hook, taginfo
address@hidden Tags, logging
address@hidden Tags, verifying
+The @file{taginfo} file defines programs to execute
+when someone executes a @code{tag} or @code{rtag}
+command. The @file{taginfo} file has the standard form
+for script hooks (@pxref{Trigger Scripts}), where each line
+is a regular expression followed by a command to execute.
+It supports the ALL and DEFAULT keywords.
+
address@hidden format strings, taginfo admin file
+In addition to the common format strings (@pxref{syntax}),
address@hidden supports:
+
address@hidden @t
address@hidden b
+tag type (@code{T} for branch, @code{N} for not-branch, or @code{?} for
+unknown, as during delete operations)
address@hidden o
+operation (@code{add} for @code{tag}, @code{mov} for @code{tag -F}, or
address@hidden for @code{tag -d})
address@hidden t
+new tag name
address@hidden @address@hidden
+file attributes, where:
address@hidden @t
address@hidden s
+file name
address@hidden T
+tag name of destination, or the empty string when there is no associated
+tag name (this usually means the trunk)
address@hidden V
+old version number (for a move or delete operation)
address@hidden v
+new version number (for an add or move operation)
address@hidden table
address@hidden table
+
+For example, some valid format strings are @samp{%%}, @samp{%p}, @samp{%t},
address@hidden, @address@hidden@}}, and @address@hidden@}}.
+
address@hidden taginfo (admin file), updating legacy repositories
address@hidden compatibility notes, taginfo admin file
+Currently, if no format strings are specified, a default
+string of @samp{ %t %o %p address@hidden@}} will be appended to the command
+line template before replacement is performed, but this
+feature is deprecated. It is simply in place so that legacy
+repositories will remain compatible with the new @sc{cvs} application.
+For information on updating, @pxref{Updating Commit Files}.
+
address@hidden Exit status, of taginfo admin file
address@hidden taginfo (admin file), exit status
+A non-zero exit of the filter program will cause the tag to be
+aborted.
+
+Here is an example of using @file{taginfo} to log @code{tag} and @code{rtag}
+commands. In the @file{taginfo} file put:
+
address@hidden
+ALL /usr/local/cvsroot/CVSROOT/loggit %t %b %o %p address@hidden@}
address@hidden example
+
address@hidden
+Where @file{/usr/local/cvsroot/CVSROOT/loggit} contains the
+following script:
+
address@hidden
+#!/bin/sh
+echo "$@@" >>/home/kingdon/cvsroot/CVSROOT/taglog
address@hidden example
+
+
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden posttag
address@hidden Logging tags
address@hidden posttag (admin file)
address@hidden script hook, posttag
address@hidden Tags, logging
+
+The @file{posttag} file defines programs to execute after a @code{tag} or
address@hidden command modifies files. The @file{posttag} file has the standard
+form for script hooks (@pxref{Trigger Scripts}), where each line is a regular
+expression followed by a command to execute. It supports the ALL and DEFAULT
+keywords.
+
address@hidden format strings, posttag admin file
+The @file{posttag} admin file supports the same format strings as the
address@hidden file (@pxref{taginfo}),
+
+
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden postwatch
address@hidden Logging watch commands
address@hidden postwatch (admin file)
address@hidden script hook, postwatch
address@hidden Watch family of commands, logging
+
+The @file{postwatch} file defines programs to execute after any command (for
+instance, @code{watch}, @code{edit}, @code{unedit}, or @code{commit}) modifies
+any @file{CVS/fileattr} file in the repository (@pxref{Watches}). The
address@hidden file has the standard form for script hooks
+(@pxref{Trigger Scripts}), where each line is a regular expression followed by
+a command to execute. It supports the ALL and DEFAULT keywords.
+
address@hidden format strings, postwatch admin file
+The @file{postwatch} file supports no format strings other than the common
+ones (@pxref{syntax}), but it is worth noting that the @code{%c} format string
+may not be replaced as you might expect. Client runs of @code{edit} and
address@hidden can sometimes skip contacting the @sc{cvs} server and cache the
+notification of the file attribute change to be sent the next time the client
+contacts the server for whatever other reason,
+
+
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden preproxy
address@hidden Launch a Script before Proxying
address@hidden preproxy (admin file)
address@hidden script hook, preproxy
address@hidden Write proxy, verifying
address@hidden Write proxy, logging
+
+The @file{preproxy} file defines programs to execute after a secondary
+server receives a write request from a client, just before it starts up the
+primary server and becomes a write proxy. This hook could be used to
+dial a modem, launch an SSH tunnel, establish a VPN, or anything else that
+might be necessary to do before contacting the primary server.
+
address@hidden scripts are called once, at the time of the write request, with
+the repository argument (if requested) set from the topmost directory sent by
+the client.
+
+The @file{preproxy} file has the standard form
+for script hooks (@pxref{Trigger Scripts}), where each line is a regular
+expression followed by a command to execute. It supports the ALL and DEFAULT
+keywords.
+
address@hidden format strings, preproxy admin file
+In addition to the common format strings, the @file{preproxy} file supports the
+following format string:
+
address@hidden @t
address@hidden P
+the CVSROOT string which specifies the primary server
address@hidden table
+
+
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden postproxy
address@hidden Launch a Script after Proxying
address@hidden postproxy (admin file)
address@hidden script hook, postproxy
address@hidden Write proxy, logging
address@hidden Write proxy, pull updates
address@hidden secondary server, pull updates
+
+The @file{postproxy} file defines programs to execute after a secondary
+server notes that the connection to the primary server has shut down and before
+it releases the client by shutting down the connection to the client.
+This could hook could be used to
+disconnect a modem, an SSH tunnel, a VPN, or anything else that
+might be necessary to do after contacting the primary server. This hook should
+also be used to pull updates from the primary server before allowing the client
+which did the write to disconnect since otherwise the client's next read
+request may generate error messages and fail upon encountering an out of date
+repository on the secondary server.
+
address@hidden scripts are called once per directory.
+
+The @file{postproxy} file has the standard form
+for script hooks (@pxref{Trigger Scripts}), where each line is a regular
+expression followed by a command to execute. It supports the ALL and DEFAULT
+keywords.
+
address@hidden format strings, postproxy admin file
+In addition to the common format strings, the @file{postproxy} file supports
+the following format string:
+
address@hidden @t
address@hidden P
+the CVSROOT string which specifies the primary server
address@hidden table
+
+
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden rcsinfo
address@hidden Rcsinfo
address@hidden rcsinfo (admin file)
address@hidden Form for log message
address@hidden Log message template
address@hidden Template for log message
address@hidden logging, commits
+
+The @file{rcsinfo} file can be used to specify a form to
+edit when filling out the commit log. The
address@hidden file has a syntax similar to the
address@hidden, @file{commitinfo} and @file{loginfo}
+files. @xref{syntax}. Unlike the other files the second
+part is @emph{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 @samp{DEFAULT}
+line is used, if it is specified.
+
+All occurrences of the name @samp{ALL} appearing as a
+regular expression are used in addition to the first
+matching regular expression or @samp{DEFAULT}.
+
address@hidden FIXME: should be offering advice, somewhere around
address@hidden here, about where to put the template file. The
address@hidden verifymsg example uses /usr/cvssupport but doesn't
address@hidden say anything about what that directory is for or
address@hidden whether it is hardwired into CVS or who creates
address@hidden it or anything. In particular we should say
address@hidden how to version control the template file. A
address@hidden probably better answer than the /usr/cvssupport
address@hidden stuff is to use checkoutlist (with xref to the
address@hidden checkoutlist doc).
address@hidden Also I am starting to see a connection between
address@hidden this and the Keeping a checked out copy node.
address@hidden Probably want to say something about that.
+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}} or @samp{cvs commit -f
address@hidden that log message will override the
+template.
+
address@hidden, for an example @file{rcsinfo}
+file.
+
+When @sc{cvs} is accessing a remote repository,
+the contents of @file{rcsinfo} at the time a directory
+is first checked out will specify a template. This
+template will be updated on all @samp{cvs update}
+commands. It will also be added to new directories
+added with a @samp{cvs add new-directory} command.
+In versions of @sc{cvs} prior to version 1.12, the
address@hidden/Template} file was not updated. If the
address@hidden server is at version 1.12 or higher an older
+client may be used and the @file{CVS/Template} will
+be updated from the server.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden cvsignore
address@hidden Ignoring files via cvsignore
address@hidden cvsignore (admin file), global
address@hidden Global cvsignore
address@hidden Ignoring files
address@hidden -- This chapter should maybe be moved to the
address@hidden tutorial part of the manual?
+
+There are certain file names that frequently occur
+inside your working copy, but that you don't want to
+put under @sc{cvs} control. Examples are all the object
+files that you get while you compile your sources.
+Normally, when you run @samp{cvs update}, it prints a
+line for each file it encounters that it doesn't know
+about (@pxref{update output}).
+
address@hidden has a list of files (or sh(1) file name patterns)
+that it should ignore while running @code{update},
address@hidden and @code{release}.
address@hidden -- Are those the only three commands affected?
+This list is constructed in the following way.
+
address@hidden @bullet
address@hidden
+The list is initialized to include certain file name
+patterns: names associated with @sc{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:
+
address@hidden Ignored files
address@hidden Automatically ignored files
address@hidden
+ 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
address@hidden example
+
address@hidden
+The per-repository list in
address@hidden/CVSROOT/cvsignore} is appended to
+the list, if that file exists.
+
address@hidden
+The per-user list in @file{.cvsignore} in your home
+directory is appended to the list, if it exists.
+
address@hidden
+Any entries in the environment variable
address@hidden is appended to the list.
+
address@hidden
+Any @samp{-I} options given to @sc{cvs} is appended.
+
address@hidden
+As @sc{cvs} traverses through your directories, the contents
+of any @file{.cvsignore} will be appended to the list.
+The patterns found in @file{.cvsignore} are only valid
+for the directory that contains them, not for
+any sub-directories.
address@hidden itemize
+
+In any of the 5 places listed above, a single
+exclamation mark (@samp{!}) clears the ignore list.
+This can be used if you want to store any file which
+normally is ignored by @sc{cvs}.
+
+Specifying @samp{-I !} to @code{cvs import} will import
+everything, which is generally what you want to do if
+you are importing files from a pristine distribution or
+any other source which is known to not contain any
+extraneous files. However, looking at the rules above
+you will see there is a fly in the ointment; if the
+distribution contains any @file{.cvsignore} files, then
+the patterns from those files will be processed even if
address@hidden !} is specified. The only workaround is to
+remove the @file{.cvsignore} files in order to do the
+import. Because this is awkward, in the future
address@hidden !} might be modified to override
address@hidden files in each directory.
+
+Note that the syntax of the ignore files consists of a
+series of lines, each of which contains a space
+separated list of filenames. This offers no clean way
+to specify filenames which contain spaces, but you can
+use a workaround like @file{foo?bar} to match a file
+named @file{foo bar} (it also matches @file{fooxbar}
+and the like). Also note that there is currently no
+way to specify comments.
address@hidden FIXCVS? I don't _like_ this syntax at all, but
address@hidden changing it raises all the usual compatibility
address@hidden issues and I'm also not sure what to change it to.
+
address@hidden checkoutlist
address@hidden The checkoutlist file
address@hidden checkoutlist
+
+It may be helpful to use @sc{cvs} to maintain your own
+files in the @file{CVSROOT} directory. For example,
+suppose that you have a script @file{logcommit.pl}
+which you run by including the following line in the
address@hidden administrative file:
+
address@hidden
+ALL $CVSROOT/CVSROOT/logcommit.pl %r/%p %s
address@hidden example
+
+To maintain @file{logcommit.pl} with @sc{cvs} you would
+add the following line to the @file{checkoutlist}
+administrative file:
+
address@hidden
+logcommit.pl
address@hidden example
+
+The format of @file{checkoutlist} is one line for each
+file that you want to maintain using @sc{cvs}, giving
+the name of the file, followed optionally by more whitespace
+and any error message that should print if the file cannot be
+checked out into CVSROOT after a commit:
+
address@hidden
+logcommit.pl Could not update CVSROOT/logcommit.pl.
address@hidden example
+
+After setting up @file{checkoutlist} in this fashion,
+the files listed there will function just like
address@hidden's built-in administrative files. For example,
+when checking in one of the files you should get a
+message such as:
+
address@hidden
+cvs commit: Rebuilding administrative file database
address@hidden example
+
address@hidden
+and the checked out copy in the @file{CVSROOT}
+directory should be updated.
+
+Note that listing @file{passwd} (@pxref{Password
+authentication server}) in @file{checkoutlist} is not
+recommended for security reasons.
+
+For information about keeping a checkout out copy in a
+more general context than the one provided by
address@hidden, see @ref{Keeping a checked out
+copy}.
+
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden history file
address@hidden The history file
address@hidden History file
address@hidden Log information, saving
+
+By default, the file @file{$CVSROOT/CVSROOT/history} is used
+to log information for the @code{history} command (@pxref{history}).
+This file name may be changed with the @samp{HistoryLogPath} and
address@hidden config options (@pxref{config}).
+
+The file format of the @file{history} file is
+documented only in comments in the @sc{cvs} source
+code, but generally programs should use the @code{cvs
+history} command to access it anyway, in case the
+format changes with future releases of @sc{cvs}.
+
address@hidden Variables
address@hidden Expansions in administrative files
address@hidden Internal variables
address@hidden Variables
+
+Sometimes in writing an administrative file, you might
+want the file to be able to know various things based
+on environment @sc{cvs} is running in. There are
+several mechanisms to do that.
+
+To find the home directory of the user running @sc{cvs}
+(from the @code{HOME} environment variable), use
address@hidden followed by @samp{/} or the end of the line.
+Likewise for the home directory of @var{user}, use
address@hidden@var{user}}. These variables are expanded on
+the server machine, and don't get any reasonable
+expansion if pserver (@pxref{Password authenticated})
+is in use; therefore user variables (see below) may be
+a better choice to customize behavior based on the user
+running @sc{cvs}.
address@hidden Based on these limitations, should we deprecate ~?
address@hidden What is it good for? Are people using it?
+
+One may want to know about various pieces of
+information internal to @sc{cvs}. A @sc{cvs} internal
+variable has the syntax @address@hidden@address@hidden,
+where @var{variable} starts with a letter and consists
+of alphanumeric characters and @samp{_}. If the
+character following @var{variable} is a
+non-alphanumeric character other than @samp{_}, the
address@hidden@{} and @address@hidden can be omitted. The @sc{cvs}
+internal variables are:
+
address@hidden @code
address@hidden CVSROOT
address@hidden CVSROOT, internal variable
+This is the absolute path to the current @sc{cvs} root directory.
address@hidden, for a description of the various
+ways to specify this, but note that the internal
+variable contains just the directory and not any
+of the access method information.
+
address@hidden RCSBIN
address@hidden RCSBIN, internal variable
+In @sc{cvs} 1.9.18 and older, this specified the
+directory where @sc{cvs} was looking for @sc{rcs}
+programs. Because @sc{cvs} no longer runs @sc{rcs}
+programs, specifying this internal variable is now an
+error.
+
address@hidden CVSEDITOR
address@hidden CVSEDITOR, internal variable
address@hidden EDITOR
address@hidden EDITOR, internal variable
address@hidden VISUAL
address@hidden VISUAL, internal variable
+These all expand to the same value, which is the editor
+that @sc{cvs} is using. @xref{Global options}, for how
+to specify this.
+
address@hidden USER
address@hidden USER, internal variable
+Username of the user running @sc{cvs} (on the @sc{cvs}
+server machine).
+When using pserver, this is the user specified in the repository
+specification which need not be the same as the username the
+server is running as (@pxref{Password authentication server}).
+Do not confuse this with the environment variable of the same name.
+
address@hidden SESSIONID
address@hidden COMMITID, internal variable
+Unique Session ID of the @sc{cvs} process. This is a
+random string of printable characters of at least 16
+characters length. Users should assume that it may
+someday grow to at most 256 characters in length.
+
address@hidden COMMITID
address@hidden COMMITID, internal variable
+Unique Session ID of the @sc{cvs} process. This is a
+random string of printable characters of at least 16
+characters length. Users should assume that it may
+someday grow to at most 256 characters in length.
address@hidden table
+
+If you want to pass a value to the administrative files
+which the user who is running @sc{cvs} can specify,
+use a user variable.
address@hidden User variables
+To expand a user variable, the
+administrative file contains
address@hidden@address@hidden@}}. To set a user variable,
+specify the global option @samp{-s} to @sc{cvs}, with
+argument @address@hidden@var{value}}. It may be
+particularly useful to specify this option via
address@hidden (@pxref{~/.cvsrc}).
+
+For example, if you want the administrative file to
+refer to a test directory you might create a user
+variable @code{TESTDIR}. Then if @sc{cvs} is invoked
+as
+
address@hidden
+cvs -s TESTDIR=/work/local/tests
address@hidden example
+
address@hidden
+and the
+administrative file contains @code{sh
address@hidden@}/runtests}, then that string is expanded
+to @code{sh /work/local/tests/runtests}.
+
+All other strings containing @samp{$} are reserved;
+there is no way to quote a @samp{$} character so that
address@hidden represents itself.
+
+Environment variables passed to administrative files are:
+
address@hidden @code
address@hidden environment variables, passed to administrative files
+
address@hidden CVS_USER
address@hidden CVS_USER, environment variable
+The @sc{cvs}-specific username provided by the user, if it
+can be provided (currently just for the pserver access
+method), and to the empty string otherwise. (@code{CVS_USER}
+and @code{USER} may differ when @file{$CVSROOT/CVSROOT/passwd}
+is used to map @sc{cvs} usernames to system usernames.)
+
address@hidden LOGNAME
address@hidden LOGNAME, environment variable
+The username of the system user.
+
address@hidden USER
address@hidden USER, environment variable
+Same as @code{LOGNAME}.
+Do not confuse this with the internal variable of the same name.
address@hidden table
+
address@hidden config
address@hidden The CVSROOT/config configuration file
+
address@hidden configuration file
address@hidden config, in CVSROOT
address@hidden CVSROOT/config
+
+Usually, the @file{config} file is found at @file{$CVSROOT/CVSROOT/config},
+but this may be overridden on the @code{pserver} and @code{server} command
+lines (@pxref{server & pserver}).
+
+The administrative file @file{config} contains various
+miscellaneous settings which affect the behavior of
address@hidden The syntax is slightly different from the
+other administrative files.
+
+Leading white space on any line is ignored, though the syntax is very strict
+and will reject spaces and tabs almost anywhere else.
+
+Empty lines, lines containing nothing but white space, and lines which start
+with @samp{#} (discounting any leading white space) are ignored.
+
address@hidden FIXME: where do we define comments for the other
address@hidden administrative files.
+Other lines consist of the optional leading white space, a keyword, @samp{=},
+and a value. Please note again that this syntax is very strict.
+Extraneous spaces or tabs, other than the leading white space, are not
+permitted on these lines.
address@hidden See comments in parseinfo.c:parse_config for more
address@hidden discussion of this strictness.
+
+As of CVS 1.12.13, lines of the form @address@hidden mark the subsequent
+section of the config file as applying only to certain repositories. Multiple
address@hidden@var{CVSROOT}]} lines without intervening
address@hidden@address@hidden pairs cause processing to fall through,
+processing subsequent keywords for any root in the list. Finally, keywords
+and values which appear before any @address@hidden lines are defaults,
+and may to apply to any repository. For example, consider the following file:
+
address@hidden
+# Defaults
+LogHistory=TMAR
+
+[/cvsroots/team1]
+ LockDir=/locks/team1
+
+[/cvsroots/team2]
+ LockDir=/locks/team2
+
+[/cvsroots/team3]
+ LockDir=/locks/team3
+
+[/cvsroots/team4]
+ LockDir=/locks/team4
+
+[/cvsroots/team3]
+[/cvsroots/team4]
+ # Override logged commands for teams 3 & 4.
+ LogHistory=all
address@hidden example
+
+This example file sets up separate lock directories for each project, as well
+as a default set of logged commands overridden for the example's team 3 &
+team 4. This syntax could be useful, for instance, if you wished to share a
+single config file, for instance @file{/etc/cvs.conf}, among several
+repositories.
+
+Currently defined keywords are:
+
address@hidden @code
address@hidden HistoryLogPath, in CVSROOT/config
address@hidden address@hidden
+Request that @sc{cvs} look for its history information in files matching
address@hidden, which is a standard UNIX file glob. If @var{pattern} matches
+multiple files, all will be searched in lexicographically sorted order.
address@hidden, and @ref{history file}, for more.
+
+If no value is supplied for this option, it defaults to
address@hidden/CVSROOT/history}.
+
address@hidden HistorySearchPath, in CVSROOT/config
address@hidden address@hidden
+Control where @sc{cvs} logs its history. If the file does not exist, @sc{cvs}
+will attempt to create it. Format strings, as available to the GNU C
address@hidden function and often the UNIX date command, and the string
address@hidden will be substituted in this path. For example, consider the
+line:
+
address@hidden
+HistoryLogPath=$CVSROOT/CVSROOT/history/%Y-%m-%d
address@hidden example
+
+This line would cause @sc{cvs} to attempt to create its history file in a
+subdirectory (@file{history}) of the configuration directory (@file{CVSROOT})
+with a name equal to the current date representation in the ISO8601 format (for
+example, on May 11, 2005, @sc{cvs} would attempt to log its history under the
+repository root directory in a file named @file{CVSROOT/history/2005-05-11}).
address@hidden, and @ref{history file}, for more.
+
+If no value is supplied for this option, it defaults to
address@hidden/CVSROOT/history}.
+
address@hidden ImportNewFilesToVendorBranchOnly, in CVSROOT/config
address@hidden import, config admin file
address@hidden config (admin file), import
address@hidden address@hidden
+Specify whether @code{cvs import} should always behave as if the
address@hidden flag was specified on the command line.
address@hidden may be either @samp{yes} or @samp{no}. If set to @samp{yes},
+all uses of @code{cvs import} on the repository will behave as if the
address@hidden flag was set. The default value is @samp{no}.
+
address@hidden KeywordExpand, in CVSROOT/config
address@hidden address@hidden
+Specify @samp{i} followed by a list of keywords to be expanded
+(for example, @samp{KeywordExpand=iMYCVS,Name,Date}),
+or @samp{e} followed by a list of keywords not to be expanded
+(for example, @samp{KeywordExpand=eCVSHeader}).
+For more on keyword expansion, see @ref{Configuring keyword expansion}.
+
address@hidden LocalKeyword, in CVSROOT/config
address@hidden address@hidden
+Specify a local alias for a standard keyword.
+For example, @samp{LocalKeyword=MYCVS=CVSHeader}.
+For more on local keywords, see @ref{Keyword substitution}.
+
address@hidden LockDir, in CVSROOT/config
address@hidden address@hidden
+Put @sc{cvs} lock files in @var{directory} rather than
+directly in the repository. This is useful if you want
+to let users read from the repository while giving them
+write access only to @var{directory}, not to the
+repository.
+It can also be used to put the locks on a very fast
+in-memory file system to speed up locking and unlocking
+the repository.
+You need to create @var{directory}, but
address@hidden will create subdirectories of @var{directory} as it
+needs them. For information on @sc{cvs} locks, see
address@hidden
+
address@hidden Mention this in Compatibility section?
+Before enabling the LockDir option, make sure that you
+have tracked down and removed any copies of @sc{cvs} 1.9 or
+older. Such versions neither support LockDir, nor will
+give an error indicating that they don't support it.
+The result, if this is allowed to happen, is that some
address@hidden users will put the locks one place, and others will
+put them another place, and therefore the repository
+could become corrupted. @sc{cvs} 1.10 does not support
+LockDir but it will print a warning if run on a
+repository with LockDir enabled.
+
address@hidden LogHistory, in CVSROOT/config
address@hidden address@hidden
+Control what is logged to the @file{CVSROOT/history} file (@pxref{history}).
+Default of @samp{TOEFWUPCGMAR} (or simply @samp{all}) will log
+all transactions. Any subset of the default is
+legal. (For example, to only log transactions that modify the
address@hidden,v} files, use @samp{LogHistory=TMAR}.) To disable history
logging
+completely, use @samp{LogHistory=}.
+
address@hidden MaxCommentLeaderLength, in CVSROOT/config
address@hidden Log keyword, configuring substitution behavior
address@hidden address@hidden
+Set to some length, in bytes, where a trailing @samp{k}, @samp{M}, @samp{G},
+or @samp{T} causes the preceding nubmer to be interpreted as kilobytes,
+megabytes, gigabytes, or terrabytes, respectively, will cause
address@hidden@splitrcskeyword{Log}$} keywords (@pxref{Keyword substitution}),
with
+more than @var{length} bytes preceding it on a line to be ignored (or to fall
+back on the comment leader set in the RCS archive file - see
address@hidden below). Defaults to 20 bytes to allow checkouts
+to proceed normally when they include binary files containing
address@hidden@splitrcskeyword{Log}$} keywords and which users have neglected
to mark
+as binary.
+
address@hidden MinCompressionLevel, in CVSROOT/config
address@hidden MaxCompressionLevel, in CVSROOT/config
address@hidden Compression levels, restricting on server
address@hidden address@hidden
address@hidden address@hidden
+Restricts the level of compression used by the @sc{cvs} server to a @var{value}
+between 0 and 9. @var{value}s 1 through 9 are the same @sc{zlib} compression
+levels accepted by the @samp{-z} option (@pxref{Global options}), and 0 means
+no compression. When one or both of these keys are set and a client requests a
+level outside the specified range, the server will simply use the closest
+permissable level. Clients will continue compressing at the level requested by
+the user.
+
+The exception is when level 0 (no compression) is not available and the client
+fails to request any compression. The @sc{cvs} server will then exit with an
+error message when it becomes apparent that the client is not going to request
+compression. This will not happen with clients version 1.12.13 and later since
+these client versions allow the server to notify them that they must request
+some level of compression.
+
address@hidden
address@hidden PreservePermissions, in CVSROOT/config
address@hidden address@hidden
+Enable support for saving special device files,
+symbolic links, file permissions and ownerships in the
+repository. The default value is @samp{no}.
address@hidden Files}, for the full implications of using
+this keyword.
address@hidden ignore
+
address@hidden PrimaryServer, in CVSROOT/config
address@hidden Primary server
address@hidden Secondary server
address@hidden proxy, write
address@hidden write proxy
address@hidden address@hidden
+When specified, and the repository specified by @var{CVSROOT} is not the one
+currently being accessed, then the server will turn itself into a transparent
+proxy to @var{CVSROOT} for write requests. The @var{hostname} configured as
+part of @var{CVSROOT} must resolve to the same string returned by the
address@hidden command on the primary server for this to work. Host name
+resolution is performed via some combination of @command{named}, a broken out
+line from @file{/etc/hosts}, and the Network Information Service (NIS or YP),
+depending on the configuration of the particular system.
+
+Only the @samp{:ext:} method is
+currently supported for primaries (actually, @samp{:fork:} is supported as
+well, but only for testing - if you find another use for accessing a primary
+via the @samp{:fork:} method, please send a note to @email{bug-cvs@@nongnu.org}
+about it). See @ref{Write proxies} for more on configuring and using write
+proxies.
+
address@hidden RCSBIN, in CVSROOT/config
address@hidden address@hidden
+For @sc{cvs} 1.9.12 through 1.9.18, this setting told
address@hidden to look for @sc{rcs} programs in the
address@hidden directory. Current versions of @sc{cvs}
+do not run @sc{rcs} programs; for compatibility this
+setting is accepted, but it does nothing.
+
address@hidden RereadLogAfterVerify, in CVSROOT/config
address@hidden @file{verifymsg}, changing the log message
address@hidden address@hidden
+Modify the @samp{commit} command such that CVS will reread the
+log message after running the program specified by @file{verifymsg}.
address@hidden may be one of @samp{yes} or @samp{always}, indicating that
+the log message should always be reread; @samp{no}
+or @samp{never}, indicating that it should never be
+reread; or @var{value} may be @samp{stat}, indicating
+that the file should be checked with the file system
address@hidden()} function to see if it has changed (see warning below)
+before rereading. The default value is @samp{always}.
+
address@hidden `stat' mode can cause CVS to pause for up to
+one extra second per directory committed. This can be less IO and
+CPU intensive but is not recommended for use with large repositories}
+
address@hidden, for more information on how verifymsg
+may be used.
+
address@hidden SystemAuth, in CVSROOT/config
address@hidden address@hidden
+If @var{value} is @samp{yes}, then pserver should check
+for users in the system's user database if not found in
address@hidden/passwd}. If it is @samp{no}, then all
+pserver users must exist in @file{CVSROOT/passwd}.
+The default is @samp{yes}. For more on pserver, see
address@hidden authenticated}.
+
address@hidden TmpDir, in config
address@hidden temporary files, location of
address@hidden temporary directory, set in config
address@hidden address@hidden
+Specify @var{path} as the directory to create temporary files in.
address@hidden options}, for more on setting the path to the temporary
+directory. This option first appeared with @sc{cvs} release 1.12.13.
+
address@hidden TopLevelAdmin, in CVSROOT/config
address@hidden address@hidden
+Modify the @samp{checkout} command to create a
address@hidden directory at the top level of the new
+working directory, in addition to @samp{CVS}
+directories created within checked-out directories.
+The default value is @samp{no}.
+
+This option is useful if you find yourself performing
+many commands at the top level of your working
+directory, rather than in one of the checked out
+subdirectories. The @file{CVS} directory created there
+will mean you don't have to specify @code{CVSROOT} for
+each command. It also provides a place for the
address@hidden/Template} file (@pxref{Working directory
+storage}).
+
address@hidden UseArchiveCommentLeader, in CVSROOT/config
address@hidden Log keyword, configuring substitution behavior
address@hidden address@hidden
+Set to @code{true}, if the text preceding a @address@hidden
+keyword is found to exceed @code{MaxCommentLeaderLength} (above) bytes, then
+the comment leader set in the RCS archive file (@pxref{admin}), if any, will
+be used instead. If there is no comment leader set in the archive file or
address@hidden is set to @samp{false}, then the keyword will not be expanded
+(@pxref{Keyword list}). To force the comment leader in the RCS archive file to
+be used exclusively (and @address@hidden expansion skipped in
+files where the comment leader has not been set in the archive file), set
address@hidden and set @code{MaxCommentLeaderLength} to @code{0}.
+
address@hidden UseNewInfoFmtStrings, in CVSROOT/config
address@hidden format strings, config admin file
address@hidden config (admin file), updating legacy repositories
address@hidden compatibility notes, config admin file
address@hidden address@hidden
+Specify whether @sc{cvs} should support the new or old command line
+template model for the commit support files (@pxref{commit files}).
+This configuration variable began life in deprecation and is only here
+in order to give people time to update legacy repositories to use the new
+format string syntax before support for the old syntax is removed. For
+information on updating your repository to support the new model,
+please see @ref{Updating Commit Files}.
+
address@hidden that new repositories (created with the @code{cvs init} command)
+will have this value set to @samp{yes}, but the default value is @samp{no}.}
+
address@hidden UserAdminOptions, in CVSROOT/config
address@hidden address@hidden
+Control what options will be allowed with the @code{cvs admin}
+command (@pxref{admin}) for users not in the @code{cvsadmin} group.
+The @var{value} string is a list of single character options
+which should be allowed. If a user who is not a member of the
address@hidden group tries to execute any @code{cvs admin}
+option which is not listed they will will receive an error message
+reporting that the option is restricted.
+
+If no @code{cvsadmin} group exists on the server, @sc{cvs} will
+ignore the @code{UserAdminOptions} keyword (@pxref{admin}).
+
+When not specified, @code{UserAdminOptions} defaults to
address@hidden In other words, it defaults to allowing
+users outside of the @code{cvsadmin} group to use the
address@hidden admin} command only to change the default keyword
+expansion mode for files.
+
+As an example, to restrict users not in the @code{cvsadmin}
+group to using @code{cvs admin} to change the default keyword
+substitution mode, lock revisions, unlock revisions, and
+replace the log message, use @samp{UserAdminOptions=klum}.
address@hidden table
+
+
+
address@hidden
---------------------------------------------------------------------
address@hidden Environment variables
address@hidden All environment variables which affect CVS
address@hidden Environment variables
address@hidden Reference manual for variables
+
+This is a complete list of all environment variables
+that affect @sc{cvs} (Windows users, please bear with this list;
+$VAR is equivalent to %VAR% at the Windows command prompt).
+
address@hidden @code
address@hidden CVSIGNORE, environment variable
address@hidden $CVSIGNORE
+A whitespace-separated list of file name patterns that
address@hidden should ignore. @xref{cvsignore}.
+
address@hidden CVSWRAPPERS, environment variable
address@hidden $CVSWRAPPERS
+A whitespace-separated list of file name patterns that
address@hidden should treat as wrappers. @xref{Wrappers}.
+
address@hidden CVSREAD, environment variable
address@hidden Read-only files, and CVSREAD
address@hidden $CVSREAD
+If this is set, @code{checkout} and @code{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.
+
address@hidden CVSREADONLYFS, environment variable
address@hidden $CVSREADONLYFS
+Turns on read-only repository mode. This allows one to
+check out from a read-only repository, such as within
+an anoncvs server, or from a @sc{cd-rom} repository.
+
+It has the same effect as if the @samp{-R} command-line
+option is used. This can also allow the use of
+read-only NFS repositories.
+
address@hidden $CVSUMASK
+Controls permissions of files in the repository. See
address@hidden permissions}.
+
address@hidden $CVSROOT
+Should contain the full pathname to the root of the @sc{cvs}
+source repository (where the @sc{rcs} files are
+kept). This information must be available to @sc{cvs} for
+most commands to execute; if @code{$CVSROOT} 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
address@hidden Once you have checked out a working
+directory, @sc{cvs} stores the appropriate root (in
+the file @file{CVS/Root}), so normally you only need to
+worry about this when initially checking out a working
+directory.
+
address@hidden $CVSEDITOR
address@hidden CVSEDITOR, environment variable
address@hidden $EDITOR
address@hidden EDITOR, environment variable
address@hidden $VISUAL
address@hidden VISUAL, environment variable
+Specifies the program to use for recording log messages
+during commit. @code{$CVSEDITOR} overrides
address@hidden, which overrides @code{$VISUAL}.
+See @ref{Committing your changes} for more or
address@hidden options} for alternative ways of specifying a
+log editor.
+
address@hidden PATH, environment variable
address@hidden $PATH
+If @code{$RCSBIN} is not set, and no path is compiled
+into @sc{cvs}, it will use @code{$PATH} to try to find all
+programs it uses.
+
address@hidden HOME, environment variable
address@hidden $HOME
address@hidden HOMEPATH, environment variable
address@hidden $HOMEPATH
address@hidden HOMEDRIVE, environment variable
address@hidden $HOMEDRIVE
+Used to locate the directory where the @file{.cvsrc}
+file, and other such files, are searched. On Unix, @sc{cvs}
+just checks for @code{HOME}. On Windows NT, the system will
+set @code{HOMEDRIVE}, for example to @samp{d:} and @code{HOMEPATH},
+for example to @file{\joe}. On Windows 95, you'll
+probably need to set @code{HOMEDRIVE} and @code{HOMEPATH} yourself.
address@hidden We are being vague about whether HOME works on
address@hidden Windows; see long comment in windows-NT/filesubr.c.
+
address@hidden CVS_RSH, environment variable
address@hidden $CVS_RSH
+Specifies the external program which @sc{cvs} connects with,
+when @code{:ext:} access method is specified.
address@hidden via rsh}.
+
address@hidden $CVS_SERVER
+Used in client-server mode when accessing a remote
+repository using @sc{rsh}. It specifies the name of
+the program to start on the server side (and any
+necessary arguments) when accessing a remote repository
+using the @code{:ext:}, @code{:fork:}, or @code{:server:} access methods.
+The default value for @code{:ext:} and @code{:server:} is @code{cvs};
+the default value for @code{:fork:} is the name used to run the client.
address@hidden via rsh}
+
address@hidden $CVS_PASSFILE
+Used in client-server mode when accessing the @code{cvs
+login server}. Default value is @file{$HOME/.cvspass}.
address@hidden authentication client}
+
address@hidden CVS_CLIENT_PORT
address@hidden $CVS_CLIENT_PORT
+Used in client-server mode to set the port to use when accessing the server
+via Kerberos, GSSAPI, or @sc{cvs}'s password authentication protocol
+if the port is not specified in the CVSROOT.
address@hidden repositories}
+
address@hidden CVS_PROXY_PORT
address@hidden $CVS_PROXY_PORT
+Used in client-server mode to set the port to use when accessing a server
+via a web proxy, if the port is not specified in the CVSROOT. Works with
+GSSAPI, and the password authentication protocol.
address@hidden repositories}
+
address@hidden CVS_RCMD_PORT, environment variable
address@hidden $CVS_RCMD_PORT
+Used in client-server mode. If set, specifies the port
+number to be used when accessing the @sc{rcmd} demon on
+the server side. (Currently not used for Unix clients).
+
address@hidden CVS_CLIENT_LOG, environment variable
address@hidden $CVS_CLIENT_LOG
+Used for debugging only in client-server
+mode. If set, everything sent to the server is logged
+into @address@hidden and everything
+sent from the server is logged into
address@hidden@code{$CVS_CLIENT_LOG}.out}.
+
address@hidden CVS_SERVER_SLEEP, environment variable
address@hidden $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 specified amount of
+seconds so that you can attach to it with a debugger.
+
address@hidden CVS_IGNORE_REMOTE_ROOT, environment variable
address@hidden $CVS_IGNORE_REMOTE_ROOT
+For @sc{cvs} 1.10 and older, setting this variable
+prevents @sc{cvs} from overwriting the @file{CVS/Root}
+file when the @samp{-d} global option is specified.
+Later versions of @sc{cvs} do not rewrite
address@hidden/Root}, so @code{CVS_IGNORE_REMOTE_ROOT} has no
+effect.
+
address@hidden CVS_LOCAL_BRANCH_NUM, environment variable
address@hidden $CVS_LOCAL_BRANCH_NUM
+Setting this variable allows some control over the
+branch number that is assigned. This is specifically to
+support the local commit feature of CVSup. If one sets
address@hidden to (say) 1000 then branches
+the local repository, the revision numbers will look
+like 1.66.1000.xx. There is almost a dead-set certainty
+that there will be no conflicts with version numbers.
+
address@hidden COMSPEC, environment variable
address@hidden $COMSPEC
+Used under OS/2 only. It specifies the name of the
+command interpreter and defaults to @sc{cmd.exe}.
+
address@hidden TMPDIR, environment variable
address@hidden temporary file directory, set via environment variable
address@hidden temporary files, location of
address@hidden $TMPDIR
+Directory in which temporary files are located.
address@hidden options}, for more on setting the temporary directory.
+
address@hidden CVS_PID, environment variable
address@hidden $CVS_PID
+This is the process identification (aka pid) number of
+the @sc{cvs} process. It is often useful in the
+programs and/or scripts specified by the
address@hidden, @file{verifymsg}, @file{loginfo}
+files.
address@hidden table
+
address@hidden Compatibility
address@hidden Compatibility between CVS Versions
+
address@hidden CVS, versions of
address@hidden Versions, of CVS
address@hidden Compatibility, between CVS versions
address@hidden We don't mention versions older than CVS 1.3
address@hidden on the theory that it would clutter it up for the vast
address@hidden majority of people, who don't have anything that old.
address@hidden
+The repository format is compatible going back to
address@hidden 1.3. But see @ref{Watches Compatibility}, if
+you have copies of @sc{cvs} 1.6 or older and you want
+to use the optional developer communication features.
address@hidden If you "cvs rm" and commit using 1.3, then you'll
address@hidden want to run "rcs -sdead <file,v>" on each of the
address@hidden files in the Attic if you then want 1.5 and
address@hidden later to recognize those files as dead (I think the
address@hidden symptom if this is not done is that files reappear
address@hidden in joins). (Wait: the above will work but really to
address@hidden be strictly correct we should suggest checking
address@hidden in a new revision rather than just changing the
address@hidden state of the head revision, shouldn't we?).
address@hidden The old convert.sh script was for this, but it never
address@hidden did get updated to reflect use of the RCS "dead"
address@hidden state.
address@hidden Note: this is tricky to document without confusing
address@hidden people--need to carefully say what CVS version we
address@hidden are talking about and keep in mind the distinction
address@hidden between a
address@hidden repository created with 1.3 and on which one now
address@hidden uses 1.5+, and a repository on which one wants to
address@hidden use both versions side by side (e.g. during a
address@hidden transition period).
address@hidden Wait, can't CVS just detect the case in which a file
address@hidden is in the Attic but the head revision is not dead?
address@hidden Not sure whether this should produce a warning or
address@hidden something, and probably needs further thought, but
address@hidden it would appear that the situation can be detected.
address@hidden
address@hidden We might want to separate out the 1.3 compatibility
address@hidden section (for repository & working directory) from the
address@hidden rest--that might help avoid confusing people who
address@hidden are upgrading (for example) from 1.6 to 1.8.
address@hidden
address@hidden A minor incompatibility is if a current version of CVS
address@hidden puts "Nfoo" into CVS/Tag, then CVS 1.9 or older will
address@hidden see this as if there is no tag. Seems to me this is
address@hidden too obscure to mention.
+
+The working directory format is compatible going back
+to @sc{cvs} 1.5. It did change between @sc{cvs} 1.3
+and @sc{cvs} 1.5. If you run @sc{cvs} 1.5 or newer on
+a working directory checked out with @sc{cvs} 1.3,
address@hidden will convert it, but to go back to @sc{cvs}
+1.3 you need to check out a new working directory with
address@hidden 1.3.
+
+The remote protocol is interoperable going back to @sc{cvs} 1.5, but no
+further (1.5 was the first official release with the remote protocol,
+but some older versions might still be floating around). In many
+cases you need to upgrade both the client and the server to take
+advantage of new features and bug fixes, however.
+
address@hidden Perhaps should be saying something here about the
address@hidden "D" lines in Entries (written by CVS 1.9; 1.8 and
address@hidden older don't use them). These are supposed to be
address@hidden compatible in both directions, but I'm not sure
address@hidden they quite are 100%. One common gripe is if you
address@hidden "rm -r" a directory and 1.9 gets confused, as it
address@hidden still sees it in Entries. That one is fixed in
address@hidden (say) 1.9.6. Someone else reported problems with
address@hidden starting with a directory which was checked out with
address@hidden an old version, and then using a new version, and
address@hidden some "D" lines appeared, but not for every
address@hidden directory, causing some directories to be skipped.
address@hidden They weren't sure how to reproduce this, though.
+
address@hidden
---------------------------------------------------------------------
address@hidden Troubleshooting
address@hidden Troubleshooting
+
+If you are having trouble with @sc{cvs}, this appendix
+may help. If there is a particular error message which
+you are seeing, then you can look up the message
+alphabetically. If not, you can look through the
+section on other problems to see if your problem is
+mentioned there.
+
address@hidden
+* Error messages:: Partial list of CVS errors
+* Connection:: Trouble making a connection to a CVS server
+* Other problems:: Problems not readily listed by error message
address@hidden menu
+
address@hidden
address@hidden - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
address@hidden @node Bad administrative files
address@hidden Bad administrative files
+
address@hidden -- Give hints on how to fix them
address@hidden ignore
+
address@hidden Error messages
address@hidden Partial list of error messages
+
+Here is a partial list of error messages that you may
+see from @sc{cvs}. It is not a complete address@hidden
+is capable of printing many, many error messages, often
+with parts of them supplied by the operating system,
+but the intention is to list the common and/or
+potentially confusing error messages.
+
+The messages are alphabetical, but introductory text
+such as @samp{cvs update: } is not considered in
+ordering them.
+
+In some cases the list includes messages printed by old
+versions of @sc{cvs} (partly because users may not be
+sure which version of @sc{cvs} they are using at any
+particular moment).
address@hidden If we want to start retiring messages, perhaps we
address@hidden should pick a cutoff version (for example, no more
address@hidden messages which are specific to versions before 1.9)
address@hidden and then move the old messages to an "old messages"
address@hidden node rather than deleting them completely.
+
address@hidden @code
address@hidden FIXME: What is the correct way to format a multiline
address@hidden error message here? Maybe @table is the wrong
address@hidden choice? Texinfo gurus?
address@hidden @var{file}:@var{line}: Assertion '@var{text}' failed
+The exact format of this message may vary depending on
+your system. It indicates a bug in @sc{cvs}, which can
+be handled as described in @ref{BUGS}.
+
address@hidden cvs @var{command}: authorization failed: server @var{host}
rejected access
+This is a generic response when trying to connect to a
+pserver server which chooses not to provide a
+specific reason for denying authorization. Check that
+the username and password specified are correct and
+that the @code{CVSROOT} specified is allowed by @samp{--allow-root}
+in @file{inetd.conf}. See @ref{Password authenticated}.
+
address@hidden cvs @var{command}: Bad root @var{directory}
+This message indicates that there were one or more
+explicit @samp{--allow-root} arguments on the cvs
+server command line which did not match the directory
+passed by the client to the server.
+
address@hidden cvs @var{command}: conflict: removed @var{file} was modified by
second party
+This message indicates that you removed a file, and
+someone else modified it. To resolve the conflict,
+first run @samp{cvs add @var{file}}. If desired, look
+at the other party's modification to decide whether you
+still want to remove it. If you don't want to remove
+it, stop here. If you do want to remove it, proceed
+with @samp{cvs remove @var{file}} and commit your
+removal.
address@hidden Tests conflicts2-142b* in sanity.sh test for this.
+
address@hidden cannot change permissions on temporary directory
address@hidden
+Operation not permitted
address@hidden example
+This message has been happening in a non-reproducible,
+occasional way when we run the client/server testsuite,
+both on Red Hat Linux 3.0.3 and 4.1. We haven't been
+able to figure out what causes it, nor is it known
+whether it is specific to Linux (or even to this
+particular machine!). If the problem does occur on
+other unices, @samp{Operation not permitted} would be
+likely to read @samp{Not owner} or whatever the system
+in question uses for the unix @code{EPERM} error. If
+you have any information to add, please let us know as
+described in @ref{BUGS}. If you experience this error
+while using @sc{cvs}, retrying the operation which
+produced it should work fine.
address@hidden This has been seen in a variety of tests, including
address@hidden multibranch-2, multibranch-5, and basic1-24-rm-rm,
address@hidden so it doesn't seem particularly specific to any one
address@hidden test.
+
address@hidden cvs [server aborted]: Cannot check out files into the repository
itself
+The obvious cause for this message (especially for
+non-client/server @sc{cvs}) is that the @sc{cvs} root
+is, for example, @file{/usr/local/cvsroot} and you try
+to check out files when you are in a subdirectory, such
+as @file{/usr/local/cvsroot/test}. However, there is a
+more subtle cause, which is that the temporary
+directory on the server is set to a subdirectory of the
+root (which is also not allowed). If this is the
+problem, set the temporary directory to somewhere else,
+for example @file{/var/tmp}; see @code{TMPDIR} in
address@hidden variables}, for how to set the
+temporary directory.
+
address@hidden cannot commit files as 'root'
+See @samp{'root' is not allowed to commit files}.
+
address@hidden For one example see basica-1a10 in the testsuite
address@hidden For another example, "cvs co ." on NT; see comment
address@hidden at windows-NT/filesubr.c (expand_wild).
address@hidden For another example, "cvs co foo/bar" where foo exists.
address@hidden cannot open CVS/Entries for reading: No such file or directory
+This generally indicates a @sc{cvs} internal error, and
+can be handled as with other @sc{cvs} bugs
+(@pxref{BUGS}). Usually there is a workaround---the
+exact nature of which would depend on the situation but
+which hopefully could be figured out.
+
address@hidden This is more obscure than it might sound; it only
address@hidden happens if you run "cvs init" from a directory which
address@hidden contains a CVS/Root file at the start.
address@hidden cvs [init aborted]: cannot open CVS/Root: No such file or
directory
+This message is harmless. Provided it is not
+accompanied by other errors, the operation has
+completed successfully. This message should not occur
+with current versions of @sc{cvs}, but it is documented
+here for the benefit of @sc{cvs} 1.9 and older.
+
address@hidden cvs server: cannot open /root/.cvsignore: Permission denied
address@hidden cvs [server aborted]: can't chdir(/root): Permission denied
+See @ref{Connection}.
+
address@hidden cvs [checkout aborted]: cannot rename file @var{file} to
CVS/,,@var{file}: Invalid argument
+This message has been reported as intermittently
+happening with @sc{cvs} 1.9 on Solaris 2.5. The cause is
+unknown; if you know more about what causes it, let us
+know as described in @ref{BUGS}.
+
address@hidden cvs address@hidden aborted]: cannot start server via rcmd
+This, unfortunately, is a rather nonspecific error
+message which @sc{cvs} 1.9 will print if you are
+running the @sc{cvs} client and it is having trouble
+connecting to the server. Current versions of @sc{cvs}
+should print a much more specific error message. If
+you get this message when you didn't mean to run the
+client at all, you probably forgot to specify
address@hidden:local:}, as described in @ref{Repository}.
+
address@hidden ci: @var{file},v: bad diff output line: Binary files - and
/tmp/T2a22651 differ
address@hidden 1.9 and older will print this message
+when trying to check in a binary file if
address@hidden is not correctly installed. Re-read the
+instructions that came with your @sc{rcs} distribution
+and the @sc{install} file in the @sc{cvs}
+distribution. Alternately, upgrade to a current
+version of @sc{cvs}, which checks in files itself
+rather than via @sc{rcs}.
+
address@hidden cvs checkout: could not check out @var{file}
+With @sc{cvs} 1.9, this can mean that the @code{co} program
+(part of @sc{rcs}) returned a failure. It should be
+preceded by another error message, however it has been
+observed without another error message and the cause is
+not well-understood. With the current version of @sc{cvs},
+which does not run @code{co}, if this message occurs
+without another error message, it is definitely a @sc{cvs}
+bug (@pxref{BUGS}).
address@hidden My current suspicion is that the RCS in the rcs (not
address@hidden cvs/winnt/rcs57nt.zip) directory on the _Practical_
address@hidden CD is bad (remains to be confirmed).
address@hidden There is also a report of something which looks
address@hidden very similar on SGI, Irix 5.2, so I dunno.
+
address@hidden cvs [login aborted]: could not find out home directory
+This means that you need to set the environment
+variables that @sc{cvs} uses to locate your home directory.
+See the discussion of @code{HOME}, @code{HOMEDRIVE}, and @code{HOMEPATH} in
address@hidden variables}.
+
address@hidden cvs update: could not merge revision @var{rev} of @var{file}: No
such file or directory
address@hidden 1.9 and older will print this message if there was
+a problem finding the @code{rcsmerge} program. Make
+sure that it is in your @code{PATH}, or upgrade to a
+current version of @sc{cvs}, which does not require
+an external @code{rcsmerge} program.
+
address@hidden cvs [update aborted]: could not patch @var{file}: No such file
or directory
+This means that there was a problem finding the
address@hidden program. Make sure that it is in your
address@hidden Note that despite appearances the message
+is @emph{not} referring to whether it can find @var{file}.
+If both the client and the server are running a current
+version of @sc{cvs}, then there is no need for an
+external patch program and you should not see this
+message. But if either client or server is running
address@hidden 1.9, then you need @code{patch}.
+
address@hidden cvs update: could not patch @var{file}; will refetch
+This means that for whatever reason the client was
+unable to apply a patch that the server sent. The
+message is nothing to be concerned about, because
+inability to apply the patch only slows things down and
+has no effect on what @sc{cvs} does.
address@hidden xref to update output. Or File status?
address@hidden Or some place else that
address@hidden explains this whole "patch"/P/Needs Patch thing?
+
address@hidden dying gasps from @var{server} unexpected
+There is a known bug in the server for @sc{cvs} 1.9.18
+and older which can cause this. For me, this was
+reproducible if I used the @samp{-t} global option. It
+was fixed by Andy Piper's 14 Nov 1997 change to
+src/filesubr.c, if anyone is curious.
+If you see the message,
+you probably can just retry the operation which failed,
+or if you have discovered information concerning its
+cause, please let us know as described in @ref{BUGS}.
+
address@hidden end of file from server (consult above messages if any)
+The most common cause for this message is if you are
+using an external @code{rsh} program and it exited with
+an error. In this case the @code{rsh} program should
+have printed a message, which will appear before the
+above message. For more information on setting up a
address@hidden client and server, see @ref{Remote repositories}.
+
address@hidden cvs [update aborted]: EOF in key in RCS file @var{file},v
address@hidden cvs [checkout aborted]: EOF while looking for end of string in
RCS file @var{file},v
+This means that there is a syntax error in the given
address@hidden file. Note that this might be true even if @sc{rcs} can
+read the file OK; @sc{cvs} does more error checking of
+errors in the RCS file. That is why you may see this
+message when upgrading from @sc{cvs} 1.9 to @sc{cvs}
+1.10. The likely cause for the original corruption is
+hardware, the operating system, or the like. Of
+course, if you find a case in which @sc{cvs} seems to
+corrupting the file, by all means report it,
+(@pxref{BUGS}).
+There are quite a few variations of this error message,
+depending on exactly where in the @sc{rcs} file @sc{cvs}
+finds the syntax error.
+
address@hidden mkmodules
address@hidden cvs commit: Executing 'mkmodules'
+This means that your repository is set up for a version
+of @sc{cvs} prior to @sc{cvs} 1.8. When using @sc{cvs}
+1.8 or later, the above message will be preceded by
+
address@hidden
+cvs commit: Rebuilding administrative file database
address@hidden example
+
+If you see both messages, the database is being rebuilt
+twice, which is unnecessary but harmless. If you wish
+to avoid the duplication, and you have no versions of
address@hidden 1.7 or earlier in use, remove @code{-i mkmodules}
+every place it appears in your @code{modules}
+file. For more information on the @code{modules} file,
+see @ref{modules}.
+
address@hidden This message comes from "co", and I believe is
address@hidden possible only with older versions of CVS which call
address@hidden co. The problem with being able to create the bogus
address@hidden RCS file still exists, though (and I think maybe
address@hidden there is a different symptom(s) now).
address@hidden FIXME: Would be nice to have a more exact wording
address@hidden for this message.
address@hidden missing author
+Typically this can happen if you created an RCS file
+with your username set to empty. @sc{cvs} will, bogusly,
+create an illegal RCS file with no value for the author
+field. The solution is to make sure your username is
+set to a non-empty value and re-create the RCS file.
address@hidden "make sure your username is set" is complicated in
address@hidden and of itself, as there are the environment
address@hidden variables the system login name, &c, and it depends
address@hidden on the version of CVS.
+
address@hidden cvs [checkout aborted]: no such tag @var{tag}
+This message means that @sc{cvs} isn't familiar with
+the tag @var{tag}. Usually the root cause is that you have
+mistyped a tag name. Ocassionally this can also occur because the
+users creating tags do not have permissions to write to the
address@hidden/val-tags} file (@pxref{File permissions}, for more).
+
+Prior to @sc{cvs} version 1.12.10, there were a few relatively
+obscure cases where a given tag could be created in an archive
+file in the repository but @sc{cvs} would require the user to
address@hidden Search sanity.sh for "no such tag" to see some of
address@hidden the relatively obscure cases.
+try a few other @sc{cvs} commands involving that tag
+until one was found whch caused @sc{cvs} to update
address@hidden CVSROOT/val-tags file, forcing tags into
address@hidden val-tags file, forcing tags into
+the @file{val-tags} file, at which point the originally failing command
+would begin to work. This same method can be used to repair a @file{val-tags}
+file that becomes out of date due to the permissions problem mentioned above.
+This updating is only required once per tag - once a tag is listed in
address@hidden, it stays there.
+
+Note that using @samp{tag -f} to not require tag matches did not and
+does not override this check (@pxref{Common options}).
+
address@hidden *PANIC* administration files missing
+This typically means that there is a directory named
address@hidden but it does not contain the administrative files
+which @sc{cvs} puts in a CVS directory. If the problem is
+that you created a CVS directory via some mechanism
+other than @sc{cvs}, then the answer is simple, use a name
+other than @sc{cvs}. If not, it indicates a @sc{cvs} bug
+(@pxref{BUGS}).
+
address@hidden rcs error: Unknown option: -x,v/
+This message will be followed by a usage message for
address@hidden It means that you have an old version of
address@hidden (probably supplied with your operating
+system), as well as an old version of @sc{cvs}.
address@hidden 1.9.18 and earlier only work with @sc{rcs} version 5 and
+later; current versions of @sc{cvs} do not run @sc{rcs} programs.
address@hidden For more information on installing @sc{cvs}, see
address@hidden (FIXME: where? it depends on whether you are
address@hidden getting binaries or sources or what).
address@hidden The message can also say "ci error" or something
address@hidden instead of "rcs error", I suspect.
+
address@hidden cvs [server aborted]: received broken pipe signal
+This message can be caused by a loginfo program that fails to
+read all of the log information from its standard input.
+If you find it happening in any other circumstances,
+please let us know as described in @ref{BUGS}.
+
address@hidden 'root' is not allowed to commit files
+When committing a permanent change, @sc{cvs} makes a log entry of
+who committed the change. If you are committing the change logged
+in as "root" (not under "su" or other root-priv giving program),
address@hidden cannot determine who is actually making the change.
+As such, by default, @sc{cvs} disallows changes to be committed by users
+logged in as "root". (You can disable this option by passing the
address@hidden option to @file{configure} and recompiling @sc{cvs}.
+On some systems this means editing the appropriate @file{config.h} file
+before building @sc{cvs}.)
+
address@hidden cvs [server aborted]: Secondary out of sync with primary!
+
+This usually means that the version of @sc{cvs} running on a secondary
+server is incompatible with the version running on the primary server
+(@pxref{Write proxies}).
+This will not occur if the client supports redirection.
+
+It is not the version number that is significant here, but the list of
+supported requests that the servers provide to the client.
+For example, even if both servers were the same version,
+if the secondary was compiled with GSSAPI support and the primary was not,
+the list of supported requests provided by the two servers
+would be different and the secondary would not work as a transparent
+proxy to the primary.
+Conversely, even if the two servers were radically different versions
+but both provided the same list of valid requests to the client,
+the transparent proxy would succeed.
+
address@hidden Terminated with fatal signal 11
+This message usually indicates that @sc{cvs} (the server, if you're
+using client/server mode) has run out of (virtual) memory.
+Although @sc{cvs} tries to catch the error and issue a more meaningful
+message, there are many circumstances where that is not possible.
+If you appear to have lots of memory available to the system,
+the problem is most likely that you're running into a system-wide
+limit on the amount of memory a single process can use or a
+similar process-specific limit.
+The mechanisms for displaying and setting such limits vary from
+system to system, so you'll have to consult an expert for your
+particular system if you don't know how to do that.
+
address@hidden Too many arguments!
+This message is typically printed by the @file{log.pl}
+script which is in the @file{contrib} directory in the
address@hidden source distribution. In some versions of
address@hidden, @file{log.pl} has been part of the default
address@hidden installation. The @file{log.pl} script gets
+called from the @file{loginfo} administrative file.
+Check that the arguments passed in @file{loginfo} match
+what your version of @file{log.pl} expects. In
+particular, the @file{log.pl} from @sc{cvs} 1.3 and
+older expects the log file as an argument whereas the
address@hidden from @sc{cvs} 1.5 and newer expects the
+log file to be specified with a @samp{-f} option. Of
+course, if you don't need @file{log.pl} you can just
+comment it out of @file{loginfo}.
+
address@hidden cvs [update aborted]: unexpected EOF reading @var{file},v
+See @samp{EOF in key in RCS file}.
+
address@hidden cvs [login aborted]: unrecognized auth response from @var{server}
+This message typically means that the server is not set
+up properly. For example, if @file{inetd.conf} points
+to a nonexistent cvs executable. To debug it further,
+find the log file which inetd writes
+(@file{/var/log/messages} or whatever inetd uses on
+your system). For details, see @ref{Connection}, and
address@hidden authentication server}.
+
address@hidden cvs commit: Up-to-date check failed for address@hidden'
+This means that someone else has committed a change to
+that file since the last time that you did a @code{cvs
+update}. So before proceeding with your @code{cvs
+commit} you need to @code{cvs update}. @sc{cvs} will merge
+the changes that you made and the changes that the
+other person made. If it does not detect any conflicts
+it will report @samp{M @var{file}} and you are ready
+to @code{cvs commit}. If it detects conflicts it will
+print a message saying so, will report @samp{C @var{file}},
+and you need to manually resolve the
+conflict. For more details on this process see
address@hidden example}.
+
address@hidden Usage: diff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1
file2 file3
address@hidden
+Only one of [exEX3] allowed
address@hidden example
+This indicates a problem with the installation of
address@hidden and @code{rcsmerge}. Specifically
address@hidden was compiled to look for GNU diff3, but
+it is finding unix diff3 instead. The exact text of
+the message will vary depending on the system. The
+simplest solution is to upgrade to a current version of
address@hidden, which does not rely on external
address@hidden or @code{diff3} programs.
+
address@hidden warning: unrecognized response address@hidden' from cvs server
+If @var{text} contains a valid response (such as
address@hidden) followed by an extra carriage return
+character (on many systems this will cause the second
+part of the message to overwrite the first part), then
+it probably means that you are using the @samp{:ext:}
+access method with a version of rsh, such as most
+non-unix rsh versions, which does not by default
+provide a transparent data stream. In such cases you
+probably want to try @samp{:server:} instead of
address@hidden:ext:}. If @var{text} is something else, this
+may signify a problem with your @sc{cvs} server.
+Double-check your installation against the instructions
+for setting up the @sc{cvs} server.
address@hidden FIXCVS: should be printing CR as \r or \015 or some
address@hidden such, probably.
+
address@hidden cvs commit: address@hidden waiting for @var{user}'s lock in
@var{directory}
+This is a normal message, not an error. See
address@hidden, for more details.
+
address@hidden cvs commit: warning: editor session failed
address@hidden Exit status, of editor
+This means that the editor which @sc{cvs} is using exits with a nonzero
+exit status. Some versions of vi will do this even when there was not
+a problem editing the file. If so, point the
address@hidden environment variable to a small script
+such as:
+
address@hidden
+#!/bin/sh
+vi $*
+exit 0
address@hidden example
+
address@hidden cvs update: warning: @var{file} was lost
+This means that the working copy of @var{file} has been deleted
+but it has not been removed from @sc{cvs}.
+This is nothing to be concerned about,
+the update will just recreate the local file from the repository.
+(This is a convenient way to discard local changes to a file:
+just delete it and then run @code{cvs update}.)
+
address@hidden cvs update: warning: @var{file} is not (any longer) pertinent
+This means that the working copy of @var{file} has been deleted,
+it has not been removed from @sc{cvs} in the current working directory,
+but it has been removed from @sc{cvs} in some other working directory.
+This is nothing to be concerned about,
+the update would have removed the local file anyway.
+
address@hidden table
+
address@hidden Connection
address@hidden Trouble making a connection to a CVS server
+
+This section concerns what to do if you are having
+trouble making a connection to a @sc{cvs} server. If
+you are running the @sc{cvs} command line client
+running on Windows, first upgrade the client to
address@hidden 1.9.12 or later. The error reporting in
+earlier versions provided much less information about
+what the problem was. If the client is non-Windows,
address@hidden 1.9 should be fine.
+
+If the error messages are not sufficient to track down
+the problem, the next steps depend largely on which
+access method you are using.
+
address@hidden @code
address@hidden :ext:, troubleshooting
address@hidden :ext:
+Try running the rsh program from the command line. For
+example: "rsh servername cvs -v" should print @sc{cvs}
+version information. If this doesn't work, you need to
+fix it before you can worry about @sc{cvs} problems.
+
address@hidden :server:, troubleshooting
address@hidden :server:
+You don't need a command line rsh program to use this
+access method, but if you have an rsh program around,
+it may be useful as a debugging tool. Follow the
+directions given for :ext:.
+
address@hidden :pserver:, troubleshooting
address@hidden :pserver:
+Errors along the lines of "connection refused" typically indicate
+that inetd isn't even listening for connections on port 2401
+whereas errors like "connection reset by peer",
+"received broken pipe signal", "recv() from server: EOF",
+or "end of file from server"
+typically indicate that inetd is listening for
+connections but is unable to start @sc{cvs} (this is frequently
+caused by having an incorrect path in @file{inetd.conf}
+or by firewall software rejecting the connection).
+"unrecognized auth response" errors are caused by a bad command
+line in @file{inetd.conf}, typically an invalid option or forgetting
+to put the @samp{pserver} command at the end of the line.
+Another less common problem is invisible control characters that
+your editor "helpfully" added without you noticing.
+
+One good debugging tool is to "telnet servername
+2401". After connecting, send any text (for example
+"foo" followed by return). If @sc{cvs} is working
+correctly, it will respond with
+
address@hidden
+cvs [pserver aborted]: bad auth protocol start: foo
address@hidden example
+
+If instead you get:
+
address@hidden
+Usage: cvs [cvs-options] command [command-options-and-arguments]
+...
address@hidden example
+
address@hidden
+then you're missing the @samp{pserver} command at the end of the
+line in @file{inetd.conf}; check to make sure that the entire command
+is on one line and that it's complete.
+
+Likewise, if you get something like:
+
address@hidden
+Unknown command: `pserved'
+
+CVS commands are:
+ add Add a new file/directory to the repository
+...
address@hidden example
+
address@hidden
+then you've misspelled @samp{pserver} in some way. If it isn't
+obvious, check for invisible control characters (particularly
+carriage returns) in @file{inetd.conf}.
+
+If it fails to work at all, then make sure inetd is working
+right. Change the invocation in @file{inetd.conf} to run the
+echo program instead of cvs. For example:
+
address@hidden
+2401 stream tcp nowait root /bin/echo echo hello
address@hidden example
+
+After making that change and instructing inetd to
+re-read its configuration file, "telnet servername
+2401" should show you the text hello and then the
+server should close the connection. If this doesn't
+work, you need to fix it before you can worry about
address@hidden problems.
+
+On AIX systems, the system will often have its own
+program trying to use port 2401. This is AIX's problem
+in the sense that port 2401 is registered for use with
address@hidden I hear that there is an AIX patch available
+to address this problem.
+
+Another good debugging tool is the @samp{-d}
+(debugging) option to inetd. Consult your system
+documentation for more information.
+
+If you seem to be connecting but get errors like:
+
address@hidden
+cvs server: cannot open /root/.cvsignore: Permission denied
+cvs [server aborted]: can't chdir(/root): Permission denied
address@hidden example
+
address@hidden
+then you probably haven't specified @samp{-f} in @file{inetd.conf}.
+(In releases prior to @sc{cvs} 1.11.1, this problem can be caused by
+your system setting the @code{$HOME} environment variable
+for programs being run by inetd. In this case, you can either
+have inetd run a shell script that unsets @code{$HOME} and then runs
address@hidden, or you can use @code{env} to run @sc{cvs} with a pristine
+environment.)
+
+If you can connect successfully for a while but then can't,
+you've probably hit inetd's rate limit.
+(If inetd receives too many requests for the same service
+in a short period of time, it assumes that something is wrong
+and temporarily disables the service.)
+Check your inetd documentation to find out how to adjust the
+rate limit (some versions of inetd have a single rate limit,
+others allow you to set the limit for each service separately.)
address@hidden table
+
address@hidden Other problems
address@hidden Other common problems
+
+Here is a list of problems which do not fit into the
+above categories. They are in no particular order.
+
address@hidden @bullet
address@hidden
+On Windows, if there is a 30 second or so delay when
+you run a @sc{cvs} command, it may mean that you have
+your home directory set to @file{C:/}, for example (see
address@hidden and @code{HOMEPATH} in
address@hidden variables}). @sc{cvs} expects the home
+directory to not end in a slash, for example @file{C:}
+or @file{C:\cvs}.
address@hidden FIXCVS: CVS should at least detect this and print an
address@hidden error, presumably.
+
address@hidden
+If you are running @sc{cvs} 1.9.18 or older, and
address@hidden update} finds a conflict and tries to
+merge, as described in @ref{Conflicts example}, but
+doesn't tell you there were conflicts, then you may
+have an old version of @sc{rcs}. The easiest solution
+probably is to upgrade to a current version of
address@hidden, which does not rely on external @sc{rcs}
+programs.
address@hidden itemize
+
address@hidden
---------------------------------------------------------------------
address@hidden Credits
address@hidden Credits
+
address@hidden Contributors (manual)
address@hidden Credits (manual)
+Roland Pesch, then of Cygnus Support <@t{roland@@wrs.com}>
+wrote the manual pages which were distributed with
address@hidden 1.3. Much of their text was copied into this
+manual. He also read an early draft
+of this manual and contributed many ideas and
+corrections.
+
+The mailing-list @code{info-cvs} is sometimes
+informative. I have included information from postings
+made by the following persons:
+David G. Grubbs <@t{dgg@@think.com}>.
+
+Some text has been extracted from the man pages for
address@hidden
+
+The @sc{cvs} @sc{faq} by David G. Grubbs has provided
+useful material. The @sc{faq} is no longer maintained,
+however, and this manual is about the closest thing there
+is to a successor (with respect to documenting how to
+use @sc{cvs}, at least).
+
+In addition, the following persons have helped by
+telling me about mistakes I've made:
+
address@hidden
+Roxanne Brunskill <@t{rbrunski@@datap.ca}>,
+Kathy Dyer <@t{dyer@@phoenix.ocf.llnl.gov}>,
+Karl Pingle <@t{pingle@@acuson.com}>,
+Thomas A Peterson <@t{tap@@src.honeywell.com}>,
+Inge Wallin <@t{ingwa@@signum.se}>,
+Dirk Koschuetzki <@t{koschuet@@fmi.uni-passau.de}>
+and Michael Brown <@t{brown@@wi.extrel.com}>.
address@hidden display
+
+The list of contributors here is not comprehensive; for a more
+complete list of who has contributed to this manual see
+the file @file{doc/ChangeLog} in the @sc{cvs} source
+distribution.
+
address@hidden
---------------------------------------------------------------------
address@hidden BUGS
address@hidden Dealing with bugs in CVS or this manual
+
address@hidden Bugs in this manual or CVS
+Neither @sc{cvs} nor this manual is perfect, and they
+probably never will be. If you are having trouble
+using @sc{cvs}, or think you have found a bug, there
+are a number of things you can do about it. Note that
+if the manual is unclear, that can be considered a bug
+in the manual, so these problems are often worth doing
+something about as well as problems with @sc{cvs} itself.
+
address@hidden Reporting bugs
address@hidden Bugs, reporting
address@hidden Errors, reporting
address@hidden @bullet
address@hidden
+If you want someone to help you and fix bugs that you
+report, there are companies which will do that for a
+fee. One such company is:
+
address@hidden Ximbiot
address@hidden Support, getting CVS support
address@hidden
+Ximbiot
+319 S. River St.
+Harrisburg, PA 17104-1657
+USA
+Email: info@@ximbiot.com
+Phone: (717) 579-6168
+Fax: (717) 234-3125
address@hidden://ximbiot.com/}
+
address@hidden example
+
address@hidden
+If you got @sc{cvs} through a distributor, such as an
+operating system vendor or a vendor of freeware
address@hidden, you may wish to see whether the
+distributor provides support. Often, they will provide
+no support or minimal support, but this may vary from
+distributor to distributor.
+
address@hidden
+If you have the skills and time to do so, you may wish
+to fix the bug yourself. If you wish to submit your
+fix for inclusion in future releases of @sc{cvs}, see
+the file @sc{hacking} in the @sc{cvs} source
+distribution. It contains much more information on the
+process of submitting fixes.
+
address@hidden
+There may be resources on the net which can help. A
+good place to start is:
+
address@hidden
address@hidden://cvs.nongnu.org/}
address@hidden example
+
+If you are so inspired, increasing the information
+available on the net is likely to be appreciated. For
+example, before the standard @sc{cvs} distribution
+worked on Windows 95, there was a web page with some
+explanation and patches for running @sc{cvs} on Windows
+95, and various people helped out by mentioning this
+page on mailing lists or newsgroups when the subject
+came up.
+
address@hidden
+It is also possible to report bugs to @email{bug-cvs@@nongnu.org}.
+Note that someone may or may not want to do anything
+with your bug report---if you need a solution consider
+one of the options mentioned above. People probably do
+want to hear about bugs which are particularly severe
+in consequences and/or easy to fix, however. You can
+also increase your odds by being as clear as possible
+about the exact nature of the bug and any other
+relevant information. The way to report bugs is to
+send email to @email{bug-cvs@@nongnu.org}. Note
+that submissions to @email{bug-cvs@@nongnu.org} may be distributed
+under the terms of the @sc{gnu} Public License, so if
+you don't like this, don't submit them. There is
+usually no justification for sending mail directly to
+one of the @sc{cvs} maintainers rather than to
address@hidden@@nongnu.org}; those maintainers who want to hear
+about such bug reports read @email{bug-cvs@@nongnu.org}. Also note
+that sending a bug report to other mailing lists or
+newsgroups is @emph{not} a substitute for sending it to
address@hidden@@nongnu.org}. It is fine to discuss @sc{cvs} bugs on
+whatever forum you prefer, but there are not
+necessarily any maintainers reading bug reports sent
+anywhere except @email{bug-cvs@@nongnu.org}.
address@hidden itemize
+
address@hidden Known bugs in this manual or CVS
+People often ask if there is a list of known bugs or
+whether a particular bug is a known one. The file
address@hidden in the @sc{cvs} source distribution is one
+list of known bugs, but it doesn't necessarily try to
+be comprehensive. Perhaps there will never be a
+comprehensive, detailed list of known bugs.
+
address@hidden
---------------------------------------------------------------------
address@hidden Index
address@hidden Index
address@hidden Index
+
address@hidden cp
+
address@hidden
+
+Local Variables:
+fill-column: 55
+End:
Index: ccvs/doc/stamp-1
diff -u /dev/null ccvs/doc/stamp-1:1.77.2.1
--- /dev/null Tue Jan 17 15:42:47 2006
+++ ccvs/doc/stamp-1 Tue Jan 17 15:42:47 2006
@@ -0,0 +1,4 @@
address@hidden UPDATED 17 January 2006
address@hidden UPDATED-MONTH January 2006
address@hidden EDITION 1.12.13.1
address@hidden VERSION 1.12.13.1
Index: ccvs/doc/stamp-vti
diff -u /dev/null ccvs/doc/stamp-vti:1.171.2.1
--- /dev/null Tue Jan 17 15:42:47 2006
+++ ccvs/doc/stamp-vti Tue Jan 17 15:42:47 2006
@@ -0,0 +1,4 @@
address@hidden UPDATED 17 January 2006
address@hidden UPDATED-MONTH January 2006
address@hidden EDITION 1.12.13.1
address@hidden VERSION 1.12.13.1
Index: ccvs/doc/version-client.texi
diff -u /dev/null ccvs/doc/version-client.texi:1.77.2.1
--- /dev/null Tue Jan 17 15:42:47 2006
+++ ccvs/doc/version-client.texi Tue Jan 17 15:42:47 2006
@@ -0,0 +1,4 @@
address@hidden UPDATED 17 January 2006
address@hidden UPDATED-MONTH January 2006
address@hidden EDITION 1.12.13.1
address@hidden VERSION 1.12.13.1
Index: ccvs/doc/version.texi
diff -u /dev/null ccvs/doc/version.texi:1.172.2.1
--- /dev/null Tue Jan 17 15:42:47 2006
+++ ccvs/doc/version.texi Tue Jan 17 15:42:47 2006
@@ -0,0 +1,4 @@
address@hidden UPDATED 17 January 2006
address@hidden UPDATED-MONTH January 2006
address@hidden EDITION 1.12.13.1
address@hidden VERSION 1.12.13.1
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Cvs-cvs] ccvs/doc ChangeLog cvs.texinfo stamp-1 stamp-vt... [newtags2],
Derek Robert Price <=