-\1f
-File: xemacs.info, Node: Variables for Check-in/out, Next: Log Entries, Prev: Editing with VC, Up: Version Control
-
-Variables Affecting Check-in and Check-out
-------------------------------------------
-
- If `vc-suppress-confirm' is non-`nil', then `C-x C-q' and `C-x v i'
-can save the current buffer without asking, and `C-x v u' also operates
-without asking for confirmation. (This variable does not affect `C-x v
-c'; that is so drastic that it should always ask for confirmation.)
-
- VC mode does much of its work by running the shell commands for RCS
-and SCCS. If `vc-command-messages' is non-`nil', VC displays messages
-to indicate which shell commands it runs, and additional messages when
-the commands finish.
-
- Normally, VC assumes that it can deduce the locked/unlocked state of
-files by looking at the file permissions of the work file; this is
-fast. However, if the `RCS' or `SCCS' subdirectory is actually a
-symbolic link, then VC does not trust the file permissions to reflect
-this status.
-
- You can specify the criterion for whether to trust the file
-permissions by setting the variable `vc-mistrust-permissions'. Its
-value may be `t' (always mistrust the file permissions and check the
-master file), `nil' (always trust the file permissions), or a function
-of one argument which makes the decision. The argument is the directory
-name of the `RCS' or `SCCS' subdirectory. A non-`nil' value from the
-function says to mistrust the file permissions.
-
- If you find that the file permissions of work files are changed
-erroneously, set `vc-mistrust-permissions' to `t'. Then VC always
-checks the master file to determine the file's status.
-
- You can specify additional directories to search for version control
-programs by setting the variable `vc-path'. These directories are
-searched before the usual search path. The proper result usually
-happens automatically.
-
-\1f
-File: xemacs.info, Node: Log Entries, Next: Change Logs and VC, Prev: Variables for Check-in/out, Up: Version Control
-
-Log Entries
------------
-
- When you're editing an initial comment or log entry for inclusion in
-a master file, finish your entry by typing `C-c C-c'.
-
-`C-c C-c'
- Finish the comment edit normally (`vc-finish-logentry'). This
- finishes check-in.
-
- To abort check-in, just don't type `C-c C-c' in that buffer. You
-can switch buffers and do other editing. As long as you don't try to
-check in another file, the entry you were editing remains in its
-buffer, and you can go back to that buffer at any time to complete the
-check-in.
-
- If you change several source files for the same reason, it is often
-convenient to specify the same log entry for many of the files. To do
-this, use the history of previous log entries. The commands `M-n',
-`M-p', `M-s' and `M-r' for doing this work just like the minibuffer
-history commands (except that these versions are used outside the
-minibuffer).
-
- Each time you check in a file, the log entry buffer is put into VC
-Log mode, which involves running two hooks: `text-mode-hook' and
-`vc-log-mode-hook'.
-
-\1f
-File: xemacs.info, Node: Change Logs and VC, Next: Old Versions, Prev: Log Entries, Up: Version Control
-
-Change Logs and VC
-------------------
-
- If you use RCS for a program and also maintain a change log file for
-it (*note Change Log::), you can generate change log entries
-automatically from the version control log entries:
-
-`C-x v a'
- Visit the current directory's change log file and create new
- entries for versions checked in since the most recent entry in the
- change log file (`vc-update-change-log').
-
- This command works with RCS only; it does not work with SCCS.
-
- For example, suppose the first line of `ChangeLog' is dated 10 April
-1992, and that the only check-in since then was by Nathaniel Bowditch
-to `rcs2log' on 8 May 1992 with log text `Ignore log messages that
-start with `#'.'. Then `C-x v a' visits `ChangeLog' and inserts text
-like this:
-
- Fri May 8 21:45:00 1992 Nathaniel Bowditch (nat@apn.org)
-
- * rcs2log: Ignore log messages that start with `#'.
-
-You can then edit the new change log entry further as you wish.
-
- Normally, the log entry for file `foo' is displayed as `* foo: TEXT
-OF LOG ENTRY'. The `:' after `foo' is omitted if the text of the log
-entry starts with `(FUNCTIONNAME): '. For example, if the log entry
-for `vc.el' is `(vc-do-command): Check call-process status.', then the
-text in `ChangeLog' looks like this:
-
- Wed May 6 10:53:00 1992 Nathaniel Bowditch (nat@apn.org)
-
- * vc.el (vc-do-command): Check call-process status.
-
- When `C-x v a' adds several change log entries at once, it groups
-related log entries together if they all are checked in by the same
-author at nearly the same time. If the log entries for several such
-files all have the same text, it coalesces them into a single entry.
-For example, suppose the most recent checkins have the following log
-entries:
-
-For `vc.texinfo':
- Fix expansion typos.
-For `vc.el':
- Don't call expand-file-name.
-For `vc-hooks.el':
- Don't call expand-file-name.
-
- They appear like this in `ChangeLog':
-
- Wed Apr 1 08:57:59 1992 Nathaniel Bowditch (nat@apn.org)
-
- * vc.texinfo: Fix expansion typos.
-
- * vc.el, vc-hooks.el: Don't call expand-file-name.
-
- Normally, `C-x v a' separates log entries by a blank line, but you
-can mark several related log entries to be clumped together (without an
-intervening blank line) by starting the text of each related log entry
-with a label of the form `{CLUMPNAME} '. The label itself is not
-copied to `ChangeLog'. For example, suppose the log entries are:
-
-For `vc.texinfo':
- {expand} Fix expansion typos.
-For `vc.el':
- {expand} Don't call expand-file-name.
-For `vc-hooks.el':
- {expand} Don't call expand-file-name.
-
-Then the text in `ChangeLog' looks like this:
-
- Wed Apr 1 08:57:59 1992 Nathaniel Bowditch (nat@apn.org)
-
- * vc.texinfo: Fix expansion typos.
- * vc.el, vc-hooks.el: Don't call expand-file-name.
-
- A log entry whose text begins with `#' is not copied to `ChangeLog'.
-For example, if you merely fix some misspellings in comments, you can
-log the change with an entry beginning with `#' to avoid putting such
-trivia into `ChangeLog'.
-