| blob | 0f7a3557544547754ec8ee4e8d13e5a77a4fab90 |
1 ;;; vc.el --- drive a version-control system from within Emacs
3 ;; Copyright (C) 1992 Free Software Foundation, Inc.
5 ;; Author: Eric S. Raymond <esr@snark.thyrsus.com>
6 ;; Version: 5.4
8 ;; This file is part of GNU Emacs.
10 ;; GNU Emacs is free software; you can redistribute it and/or modify
11 ;; it under the terms of the GNU General Public License as published by
12 ;; the Free Software Foundation; either version 2, or (at your option)
13 ;; any later version.
15 ;; GNU Emacs is distributed in the hope that it will be useful,
16 ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
17 ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
18 ;; GNU General Public License for more details.
20 ;; You should have received a copy of the GNU General Public License
21 ;; along with GNU Emacs; see the file COPYING. If not, write to
22 ;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
24 ;;; Commentary:
26 ;; This mode is fully documented in the Emacs user's manual.
27 ;;
28 ;; This was designed and implemented by Eric Raymond <esr@snark.thyrsus.com>.
29 ;; Paul Eggert <eggert@twinsun.com>, Sebastian Kremer <sk@thp.uni-koeln.de>,
30 ;; and Richard Stallman contributed valuable criticism, support, and testing.
31 ;;
32 ;; Supported version-control systems presently include SCCS and RCS;
33 ;; your RCS version should be 5.6.2 or later for proper operation of
34 ;; the lock-breaking code.
35 ;;
36 ;; The RCS code assumes strict locking. You can support the RCS -x option
37 ;; by adding pairs to the vc-master-templates list.
38 ;;
39 ;; Proper function of the SCCS diff commands requires the shellscript vcdiff
40 ;; to be installed somewhere on Emacs's path for executables.
41 ;;
42 ;; If your site uses the ChangeLog convention supported by Emacs, the
43 ;; function vc-comment-to-change-log should prove a useful checkin hook.
44 ;;
45 ;; This code depends on call-process passing back the subprocess exit
46 ;; status. Thus, you need Emacs 18.58 or later to run it. For the
47 ;; vc-directory command to work properly, you need 19
48 ;;
49 ;; The vc code maintains some internal state in order to reduce expensive
50 ;; version-control operations to a minimum. Some names are only computed
51 ;; once. If you perform version control operations with RCS/SCCS/CVS while
52 ;; vc's back is turned, or move/rename master files while vc is running,
53 ;; vc may get seriously confused. Don't do these things!
54 ;;
55 ;; Developer's notes on some concurrency issues are included at the end of
56 ;; the file.
58 ;;; Code:
69 minor-mode-alist)))
71 ;; General customization
74 "*Back-end actually used by this interface; may be SCCS or RCS.
94 ;;;###autoload
98 ;; Header-insertion hair
106 "*Associate static header string templates with file types. A \%s in the
107 template is replaced with the first string associated with the file's
112 "*Special comment delimiters to be used in generating vc headers only.
113 Add an entry in this list if you need to override the normal comment-start
114 and comment-end variables. This will only be necessary if the mode language
117 ;; Variables the user doesn't need to know about.
137 ;; File property caching
140 ;; clear all properties of a given file
144 "Clear all cached file properties and the comment ring."
147 ;; Note: there is potential for minor lossage here if there is an open
148 ;; log buffer with a nonzero local value of vc-comment-ring-index.
151 ;; Random helper functions
154 "Return the master name of a file, nil if it is not registered"
163 "Look for a command anywhere on the subprocess-command search path."
171 exec-path))
174 full)))
177 "Execute a version-control command, notifying user and checking for errors.
178 The command is successful if its exit status does not exceed OKSTATUS.
179 Output from COMMAND goes to buffer *vc*. The last argument of the command is
180 the master name of FILE; this is appended to an optional list of FLAGS."
187 status)
195 ;; This is so that command arguments typed in the *vc* buffer will
196 ;; have reasonable defaults.
201 flags)
219 status))
220 )
223 )
225 status)
226 )
228 ;;; Save a bit of the text around POSN in the current buffer, to help
229 ;;; us find the corresponding position again later. This works even
230 ;;; if all markers are destroyed or corrupted.
237 ;;; Return the position of CONTEXT in the current buffer, or nil if we
238 ;;; couldn't find it.
248 ;; Can't use search-backward since the match may continue
249 ;; after point.
251 ;; goto-char doesn't signal an error at
252 ;; beginning of buffer like backward-char would
254 ;; to beginning of OSTRING
258 ;; Most of this was shamelessly lifted from Sebastian Kremer's rcs.el mode.
259 ;; Revert buffer, try to keep point and mark where user expects them in spite
260 ;; of changes because of expanded version-control key words.
261 ;; This is quite important since otherwise typeahead won't work as expected.
265 ;; Use mark-marker to avoid confusion in transient-mark-mode.
268 ;; Make the right thing happen in transient-mark-mode.
270 ;; We may want to reparse the compilation buffer after revert
273 ;; Construct a list; each elt is nil or a buffer
274 ;; iff that buffer is a compilation output buffer
275 ;; that contains markers into the current buffer.
280 compilation-old-error-list
281 compilation-error-list))
293 ;; the actual revisit
296 ;; Reparse affected compilation buffers.
302 ;; Record the position in the compilation buffer of
303 ;; the last error next-error went to.
306 ;; Reparse the error messages as far as they were parsed before.
308 ;; Move the pointer up to find the error we were at before
309 ;; reparsing. Now next-error should properly go to the next one.
315 ;; Restore point and mark
324 ;; Make sure the current buffer and its working file are in sync
327 vc-suppress-confirm
333 ;; Has the given workfile changed since last checkout?
341 t)
344 nil
345 ))
346 )))
349 ;;; If comment is specified, it will be used as an admin or checkin comment.
353 ;; if there is no master file corresponding, create one
361 ;; if there is no lock on the file, assert one and get it
365 ;; a checked-out version exists, but the user may not own the lock
370 file
372 owner))
374 ;; OK, user owns the lock on the file
378 ;; give luser a chance to save before checking in.
381 ;; Revert if file is unchanged and buffer is too.
382 ;; If buffer is modified, that means the user just said no
383 ;; to saving it; in that case, don't revert,
384 ;; because the user might intend to save
385 ;; after finishing the log entry.
390 ;; DO NOT revert the file without asking the user!
393 ;; user may want to set nonstandard parameters
397 ;; OK, let's do the checkin
399 )))))
402 ;; We've accepted a log comment, now do a vc-next-action using it on all
403 ;; marked files.
411 nil t)
412 )
414 ;; Here's the major entry point.
416 ;;;###autoload
418 "Do the next logical checkin or checkout operation on the current file.
419 If the file is not already registered, this registers it for version
420 control and then retrieves a writeable, locked copy for editing.
421 If the file is registered and not locked by anyone, this checks out
422 a writeable and locked file ready for editing.
423 If the file is checked out and locked by the calling user, this
424 first checks to see if the file has changed since checkout. If not,
425 it performs a revert.
426 If the file has been changed, this pops up a buffer for entry
427 of a log message; when the message has been entered, it checks in the
428 resulting changes along with the log message as change commentary. If
429 the variable vc-keep-workfiles is non-nil (which is its default), a
430 read-only copy of the changed file is left in place afterwards.
431 If the file is registered and locked by someone else, you are given
432 the option to steal the lock.
433 If you call this from within a VC dired buffer with no files marked,
434 it will operate on the file in the current line.
435 If you call this from within a VC dired buffer, and one or more
436 files are marked, it will accept a log message and then operate on
437 each one. The log message will be used as a comment for any register
438 or checkin operations, but ignored when doing checkouts. Attempted
439 lock steals will raise an error."
447 "Enter a change comment for the marked files."
456 ;;; These functions help the vc-next-action entry point
459 "Retrieve a writeable copy of the latest version of the current buffer's file."
461 )
463 ;;;###autoload
465 "Register the current file into your version-control system."
469 ;; Watch out for new buffers of size 0: the corresponding file
470 ;; does not exist yet, even though buffer-modified-p is nil.
477 buffer-file-name
481 )
484 ;; If the given file is in the current buffer,
485 ;; either revert on it so we see expanded keyworks,
486 ;; or unvisit it (depending on vc-keep-workfiles)
487 ;; NOQUERY if non-nil inhibits confirmation for reverting.
488 ;; NOQUERY should be t *only* if it is known the only difference
489 ;; between the buffer and the file is due to RCS rather than user editing!
500 ;; Accept a comment for an operation on FILE revision REV. If COMMENT
501 ;; is nil, pop up a VC-log buffer, emit MSG, and set the
502 ;; action on close to ACTION; otherwise, do action immediately.
503 ;; Remember the file's buffer in parent-buffer (current one if no file).
526 "Check a file into your version-control system.
527 FILE is the unmodified name of the file. REV should be the base version
528 level to check it in under. COMMENT, if specified, is the checkin comment."
534 "Retrieve a copy of the latest version of the given file."
535 ;; If ftp is on this system and the name matches the ange-ftp format
536 ;; for a remote file, the user is trying something that won't work.
542 )
545 "Steal the lock on the current workfile."
565 ;; This is called when the notification has been sent.
571 "Check in the file specified by FILE.
572 The optional argument REV may be a string specifying the new version level
573 \(if nil increment the current level). The file is either retained with write
574 permissions zeroed, or deleted (according to the value of vc-keep-workfiles).
575 COMMENT is a comment string; if omitted, a buffer is
576 popped up to accept a comment."
580 ;;; Here is a checkin hook that may prove useful to sites using the
581 ;;; ChangeLog facility supported by Emacs.
583 "Update change log from VC change comments entered for the current file.
584 Optional FILE specifies the change log file name; see `find-change-log'.
585 See `vc-update-change-log'."
590 default-directory)))
595 "Complete the operation implied by the current log entry."
597 ;; Check and record the comment, if any.
603 ;; Comment too long?
605 ;; Record the comment in the comment ring
609 ))
610 ;; OK, do it to it
614 vc-log-file
615 vc-log-version
618 ;; Return to "parent" buffer of this checkin and remove checkin window
623 ;; Now make sure we see the expanded headers
628 ;; Code for access to the comment ring
631 "Cycle backwards through comment history."
639 ;; Initialize the index on the first use of this command
640 ;; so that the first M-p gets index 0, and the first M-n gets
641 ;; index -1.
652 "Cycle forwards through comment history."
657 "Searches backwards through comment history for substring match."
674 "Searches forwards through comment history for substring match."
690 ;; Additional entry points for examining version histories
692 ;;;###autoload
694 "Display diffs between file versions."
705 unchanged)
711 ;; Ideally, we'd like at this point to parse the diff so that
712 ;; the buffer effectively goes into compilation mode and we
713 ;; can visit the old and new change locations via next-error.
714 ;; Unfortunately, this is just too painful to do. The basic
715 ;; problem is that the `old' file doesn't exist to be
716 ;; visited. This plays hell with numerous assumptions in
717 ;; the diff.el and compile.el machinery.
721 )
723 )
724 )
725 )
728 "For FILE, report diffs between two stored versions REL1 and REL2 of it.
729 If FILE is a directory, generate diffs between versions for all registered
730 files in or below it."
743 " and "
756 )))
761 )
769 )
770 )
771 )
772 )
774 ;; Header-insertion code
776 ;;;###autoload
778 "Insert headers in a file for use with your version-control system.
779 Headers desired are inserted at the start of the buffer, and are pulled from
780 the variable vc-header-alist"
799 hdstrings)
804 vc-static-header-alist))
805 )
806 )))))
808 ;; The VC directory submode. Coopt Dired for this.
809 ;; All VC commands get mapped into logical equivalents.
816 "The augmented Dired minor mode used in VC directory buffers.
817 All Dired commands operate normally. Users currently locking listed files
818 are listed at the left-hand side of the buffer, following the Dired mark area.
819 Keystrokes bound to VC commands will execute as though they had been called
820 on a buffer attached to the file named in the current Dired buffer line."
825 ;; Hack a directory-listing line, plugging in locking-user info in
826 ;; place of the user and group info. Should have the beneficial
827 ;; side-effect of shortening the listing line. Each call starts with
828 ;; point immediately following the dired mark area on the line to be
829 ;; hacked.
830 ;;
831 ;; Simplest possible one:
832 ;; (insert (concat x "\t")))
833 ;;
834 ;; This code, like dired, assumes UNIX -l format.
840 )
842 ;;;###autoload
844 "Show version-control status of all files under the current directory."
849 dired-buf
850 dired-buf-mod-count)
859 ;; This uses a semi-documented featre of dired; giving a switch
860 ;; argument forces the buffer to refresh each time.
863 dired-listing-switches)
881 )
884 ))
886 ;; Named-configuration support for SCCS
895 ))
904 ))
907 ;; Return the numeric version corresponding to a named snapshot of file
908 ;; If name is nil or a version number string it's just passed through
912 name)
917 )))
919 ;; Named-configuration entry points
922 ;; Is the current directory ready to be snapshot?
928 t))
930 ;;;###autoload
932 "Make a snapshot called NAME.
933 The snapshot is made from all registered files at or below the current
934 directory. For each file, the version level of its latest
935 version becomes part of the named configuration."
943 ))
945 ;;;###autoload
947 "Retrieve the snapshot called NAME.
948 This function fails if any files are locked at or below the current directory
949 Otherwise, all registered files are checked out (unlocked) at their version
950 levels in the snapshot."
958 ))
960 ;; Miscellaneous other entry points
962 ;;;###autoload
964 "List the change log of the current buffer in a window."
976 )
978 )
979 )
981 ;;;###autoload
983 "Revert the current buffer's file back to the latest checked-in version.
984 This asks for confirmation if the buffer contents are not identical
985 to that version."
1003 )
1004 )
1006 ;;;###autoload
1008 "Undo your latest checkin."
1017 "Remove your version %s from master?"
1020 nil
1025 ))
1028 "Rename a file, taking its master files with it."
1040 ;; This had FILE, I changed it to OLD. -- rms.
1046 ; ?? Renaming a file might change its contents due to keyword expansion.
1047 ; We should really check out a new copy if the old copy was precisely equal
1048 ; to some checked in version. However, testing for this is tricky....
1054 ;; This had FILE, I changed it to OLD. -- rms.
1057 nil)
1058 )
1060 ;;;###autoload
1062 "Find change log file and add entries from recent RCS logs.
1063 The mark is left at the end of the text prepended to the change log.
1064 With prefix arg of C-u, only find log entries for the current buffer's file.
1065 With any numeric prefix arg, find log entries for all files currently visited.
1066 From a program, any arguments are passed to the `rcs2log' script."
1073 file)
1079 files))))
1091 ;; Functions for querying the master and lock files.
1097 ;; Use PATTERNS to parse information out of the current buffer
1098 ;; by matching each regular expression in the list and returning \\1.
1099 ;; If a regexp has two tag brackets, assume the second is a date
1100 ;; field and we want the most recent entry matching the template.
1101 ;; If FILE and PROPERTIES are given, the latter must be a list of
1102 ;; properties of the same length as PATTERNS; each property is assigned
1103 ;; the corresponding value.
1115 latest-val))
1121 value))
1123 patterns)
1124 )
1127 ;; Search for information in a master file.
1140 )
1144 properties))
1145 )
1146 )
1149 ;; Search for information in log program output
1160 )
1161 )
1165 properties))
1166 )
1167 )
1170 "Return the name of the person currently holding a lock on FILE.
1171 Return nil if there is no such person."
1178 ;; This implementation assumes that any file which is under version
1179 ;; control and has -rw-r--r-- is locked by its owner. This is true
1180 ;; for both RCS and SCCS, which keep unlocked files at -r--r--r--.
1181 ;; We have to be careful not to exclude files with execute bits on;
1182 ;; scripts can be under version control too. The advantage of this
1183 ;; hack is that calls to the very expensive vc-fetch-properties
1184 ;; function only have to be made if (a) the file is locked by someone
1185 ;; other than the current user, or (b) some untoward manipulation
1186 ;; behind vc's back has changed the owner or the `group' or `other'
1187 ;; write bits.
1190 nil)
1198 ;; The slow but reliable version
1203 ;; Return version level of the latest version of FILE
1208 ;; Return version level of the latest version of FILE checked in by you
1212 ;; Collect back-end-dependent stuff here
1213 ;;
1214 ;; Everything eventually funnels through these functions. To implement
1215 ;; support for a new version-control system, add another branch to the
1216 ;; vc-backend-dispatch macro and fill it in in each call. The variable
1217 ;; vc-master-templates in vc-hooks.el will also have to change.
1220 "Execute FORM1 or FORM2 depending on whether we're using SCCS or RCS."
1225 )))
1228 ;; Generate lock file name corresponding to FILE
1231 master
1235 "p."
1240 ;; Re-fetch all properties associated with the given file.
1241 ;; Currently these properties are:
1242 ;; vc-locking-user
1243 ;; vc-locked-version
1244 ;; vc-latest-version
1245 ;; vc-your-latest-version
1247 file
1248 ;; SCCS
1254 file
1261 )
1262 file
1264 )
1265 ;; RCS
1276 vc-latest-version vc-your-latest-version))
1277 ))
1280 ;; Where the master and lock files for the current directory are kept
1284 vc-default-back-end
1288 ;; Register a file into the version-control system
1289 ;; Automatically retrieves a read-only version of the file with
1290 ;; keywords expanded if vc-keep-workfiles is non-nil, otherwise
1291 ;; it deletes the workfile.
1305 "-fb"
1319 file)
1320 )))
1322 )
1325 ;; Retrieve a copy of a saved version into a workfile
1332 )
1336 )
1339 )
1348 nil)
1349 )
1352 ;; Register changes to FILE as level REV with explanatory COMMENT.
1353 ;; Automatically retrieves a read-only version of the file with
1354 ;; keywords expanded if vc-keep-workfiles is non-nil, otherwise
1355 ;; it deletes the workfile.
1358 ;; Change buffers to get local value of vc-checkin-switches.
1365 vc-checkin-switches)
1368 )
1372 vc-checkin-switches)
1373 ))
1376 )
1379 ;; Revert file to latest checked-in version.
1382 file
1391 )
1394 ;; Steal the lock on the current workfile. Needs RCS 5.6.2 or later for -M.
1399 )
1404 )
1407 )
1410 ;; Undo the latest checkin. Note: this code will have to get a lot
1411 ;; smarter when we support multiple branches.
1416 )
1418 )
1421 ;; Print change log associated with FILE to buffer *vc*.
1424 file)
1425 )
1428 ;; Assign to a FILE's latest version a given NAME.
1432 )
1433 )
1436 ;; Get a difference report between two versions
1443 file
1446 vc-diff-options
1447 ))
1450 "Check if the current file has any headers in it."
1456 (re-search-forward "\\$[A-Za-z\300-\326\330-\366\370-\377]+\\(: [\t -#%-\176\240-\377]*\\)?\\$" nil t) ;; RCS
1457 )
1458 ))
1460 ;; Back-end-dependent stuff ends here.
1462 ;; Set up key bindings for use while editing log messages
1465 "Minor mode for driving version-control tools.
1466 These bindings are added to the global keymap when you enter this mode:
1478 While you are entering a change log message for a version, the following
1479 additional bindings will be in effect.
1483 Whenever you do a checkin, your log comment is added to a ring of
1484 saved comments. These can be recalled as follows:
1491 Entry to the change-log submode calls the value of text-mode-hook, then
1492 the value of vc-log-mode-hook.
1494 Global user options:
1495 vc-initial-comment If non-nil, require user to enter a change
1496 comment upon first checkin of the file.
1498 vc-keep-workfiles Non-nil value prevents workfiles from being
1499 deleted when changes are checked in
1501 vc-suppress-confirm Suppresses some confirmation prompts,
1502 notably for reversions.
1504 vc-diff-options A list consisting of the flags
1505 to be used for generating context diffs.
1507 vc-header-alist Which keywords to insert when adding headers
1511 vc-static-header-alist By default, version headers inserted in C files
1512 get stuffed in a static string area so that
1513 ident(RCS) or what(SCCS) can see them in the
1514 compiled object code. You can override this
1515 by setting this variable to nil, or change
1516 the header template by changing it.
1518 vc-command-messages if non-nil, display run messages from the
1519 actual version-control utilities (this is
1520 intended primarily for people hacking vc
1521 itself).
1522 "
1535 )
1537 ;; Initialization code, to be done just once at load-time
1539 nil
1546 )
1548 ;;; These things should probably be generally available
1551 "Shrink a window vertically until it's just large enough to contain its text"
1558 "Walk recursively through default directory,
1559 invoking FUNC f ARGS on all non-directory files f underneath it."
1581 ;;; DEVELOPER'S NOTES ON CONCURRENCY PROBLEMS IN THIS CODE
1582 ;;;
1583 ;;; These may be useful to anyone who has to debug or extend the package.
1584 ;;;
1585 ;;; A fundamental problem in VC is that there are time windows between
1586 ;;; vc-next-action's computations of the file's version-control state and
1587 ;;; the actions that change it. This is a window open to lossage in a
1588 ;;; multi-user environment; someone else could nip in and change the state
1589 ;;; of the master during it.
1590 ;;;
1591 ;;; The performance problem is that rlog/prs calls are very expensive; we want
1592 ;;; to avoid them as much as possible.
1593 ;;;
1594 ;;; ANALYSIS:
1595 ;;;
1596 ;;; The performance problem, it turns out, simplifies in practice to the
1597 ;;; problem of making vc-locking-user fast. The two other functions that call
1598 ;;; prs/rlog will not be so commonly used that the slowdown is a problem; one
1599 ;;; makes snapshots, the other deletes the calling user's last change in the
1600 ;;; master.
1601 ;;;
1602 ;;; The race condition implies that we have to either (a) lock the master
1603 ;;; during the entire execution of vc-next-action, or (b) detect and
1604 ;;; recover from errors resulting from dispatch on an out-of-date state.
1605 ;;;
1606 ;;; Alternative (a) appears to be unfeasible. The problem is that we can't
1607 ;;; guarantee that the lock will ever be removed. Suppose a user starts a
1608 ;;; checkin, the change message buffer pops up, and the user, having wandered
1609 ;;; off to do something else, simply forgets about it?
1610 ;;;
1611 ;;; Alternative (b), on the other hand, works well with a cheap way to speed up
1612 ;;; vc-locking-user. Usually, if a file is registered, we can read its locked/
1613 ;;; unlocked state and its current owner from its permissions.
1614 ;;;
1615 ;;; This shortcut will fail if someone has manually changed the workfile's
1616 ;;; permissions; also if developers are munging the workfile in several
1617 ;;; directories, with symlinks to a master (in this latter case, the
1618 ;;; permissions shortcut will fail to detect a lock asserted from another
1619 ;;; directory).
1620 ;;;
1621 ;;; Note that these cases correspond exactly to the errors which could happen
1622 ;;; because of a competing checkin/checkout race in between two instances of
1623 ;;; vc-next-action.
1624 ;;;
1625 ;;; For VC's purposes, a workfile/master pair may have the following states:
1626 ;;;
1627 ;;; A. Unregistered. There is a workfile, there is no master.
1628 ;;;
1629 ;;; B. Registered and not locked by anyone.
1630 ;;;
1631 ;;; C. Locked by calling user and unchanged.
1632 ;;;
1633 ;;; D. Locked by the calling user and changed.
1634 ;;;
1635 ;;; E. Locked by someone other than the calling user.
1636 ;;;
1637 ;;; This makes for 25 states and 20 error conditions. Here's the matrix:
1638 ;;;
1639 ;;; VC's idea of state
1640 ;;; |
1641 ;;; V Actual state RCS action SCCS action Effect
1642 ;;; A B C D E
1643 ;;; A . 1 2 3 4 ci -u -t- admin -fb -i<file> initial admin
1644 ;;; B 5 . 6 7 8 co -l get -e checkout
1645 ;;; C 9 10 . 11 12 co -u unget; get revert
1646 ;;; D 13 14 15 . 16 ci -u -m<comment> delta -y<comment>; get checkin
1647 ;;; E 17 18 19 20 . rcs -u -M ; rcs -l unget -n ; get -g steal lock
1648 ;;;
1649 ;;; All commands take the master file name as a last argument (not shown).
1650 ;;;
1651 ;;; In the discussion below, a "self-race" is a pathological situation in
1652 ;;; which VC operations are being attempted simultaneously by two or more
1653 ;;; Emacsen running under the same username.
1654 ;;;
1655 ;;; The vc-next-action code has the following windows:
1656 ;;;
1657 ;;; Window P:
1658 ;;; Between the check for existence of a master file and the call to
1659 ;;; admin/checkin in vc-buffer-admin (apparent state A). This window may
1660 ;;; never close if the initial-comment feature is on.
1661 ;;;
1662 ;;; Window Q:
1663 ;;; Between the call to vc-workfile-unchanged-p in and the immediately
1664 ;;; following revert (apparent state C).
1665 ;;;
1666 ;;; Window R:
1667 ;;; Between the call to vc-workfile-unchanged-p in and the following
1668 ;;; checkin (apparent state D). This window may never close.
1669 ;;;
1670 ;;; Window S:
1671 ;;; Between the unlock and the immediately following checkout during a
1672 ;;; revert operation (apparent state C). Included in window Q.
1673 ;;;
1674 ;;; Window T:
1675 ;;; Between vc-locking-user and the following checkout (apparent state B).
1676 ;;;
1677 ;;; Window U:
1678 ;;; Between vc-locking-user and the following revert (apparent state C).
1679 ;;; Includes windows Q and S.
1680 ;;;
1681 ;;; Window V:
1682 ;;; Between vc-locking-user and the following checkin (apparent state
1683 ;;; D). This window may never be closed if the user fails to complete the
1684 ;;; checkin message. Includes window R.
1685 ;;;
1686 ;;; Window W:
1687 ;;; Between vc-locking-user and the following steal-lock (apparent
1688 ;;; state E). This window may never cloce if the user fails to complete
1689 ;;; the steal-lock message. Includes window X.
1690 ;;;
1691 ;;; Window X:
1692 ;;; Between the unlock and the immediately following re-lock during a
1693 ;;; steal-lock operation (apparent state E). This window may never cloce
1694 ;;; if the user fails to complete the steal-lock message.
1695 ;;;
1696 ;;; Errors:
1697 ;;;
1698 ;;; Apparent state A ---
1699 ;;;
1700 ;;; 1. File looked unregistered but is actually registered and not locked.
1701 ;;;
1702 ;;; Potential cause: someone else's admin during window P, with
1703 ;;; caller's admin happening before their checkout.
1704 ;;;
1705 ;;; RCS: ci will fail with a "no lock set by <user>" message.
1706 ;;; SCCS: admin will fail with error (ad19).
1707 ;;;
1708 ;;; We can let these errors be passed up to the user.
1709 ;;;
1710 ;;; 2. File looked unregistered but is actually locked by caller, unchanged.
1711 ;;;
1712 ;;; Potential cause: self-race during window P.
1713 ;;;
1714 ;;; RCS: will revert the file to the last saved version and unlock it.
1715 ;;; SCCS: will fail with error (ad19).
1716 ;;;
1717 ;;; Either of these consequences is acceptable.
1718 ;;;
1719 ;;; 3. File looked unregistered but is actually locked by caller, changed.
1720 ;;;
1721 ;;; Potential cause: self-race during window P.
1722 ;;;
1723 ;;; RCS: will register the caller's workfile as a delta with a
1724 ;;; null change comment (the -t- switch will be ignored).
1725 ;;; SCCS: will fail with error (ad19).
1726 ;;;
1727 ;;; 4. File looked unregistered but is locked by someone else.
1728 ;;;
1729 ;;; Potential cause: someone else's admin during window P, with
1730 ;;; caller's admin happening *after* their checkout.
1731 ;;;
1732 ;;; RCS: will fail with a "no lock set by <user>" message.
1733 ;;; SCCS: will fail with error (ad19).
1734 ;;;
1735 ;;; We can let these errors be passed up to the user.
1736 ;;;
1737 ;;; Apparent state B ---
1738 ;;;
1739 ;;; 5. File looked registered and not locked, but is actually unregistered.
1740 ;;;
1741 ;;; Potential cause: master file got nuked during window P.
1742 ;;;
1743 ;;; RCS: will fail with "RCS/<file>: No such file or directory"
1744 ;;; SCCS: will fail with error ut4.
1745 ;;;
1746 ;;; We can let these errors be passed up to the user.
1747 ;;;
1748 ;;; 6. File looked registered and not locked, but is actually locked by the
1749 ;;; calling user and unchanged.
1750 ;;;
1751 ;;; Potential cause: self-race during window T.
1752 ;;;
1753 ;;; RCS: in the same directory as the previous workfile, co -l will fail
1754 ;;; with "co error: writable foo exists; checkout aborted". In any other
1755 ;;; directory, checkout will succeed.
1756 ;;; SCCS: will fail with ge17.
1757 ;;;
1758 ;;; Either of these consequences is acceptable.
1759 ;;;
1760 ;;; 7. File looked registered and not locked, but is actually locked by the
1761 ;;; calling user and changed.
1762 ;;;
1763 ;;; As case 6.
1764 ;;;
1765 ;;; 8. File looked registered and not locked, but is actually locked by another
1766 ;;; user.
1767 ;;;
1768 ;;; Potential cause: someone else checks it out during window T.
1769 ;;;
1770 ;;; RCS: co error: revision 1.3 already locked by <user>
1771 ;;; SCCS: fails with ge4 (in directory) or ut7 (outside it).
1772 ;;;
1773 ;;; We can let these errors be passed up to the user.
1774 ;;;
1775 ;;; Apparent state C ---
1776 ;;;
1777 ;;; 9. File looks locked by calling user and unchanged, but is unregistered.
1778 ;;;
1779 ;;; As case 5.
1780 ;;;
1781 ;;; 10. File looks locked by calling user and unchanged, but is actually not
1782 ;;; locked.
1783 ;;;
1784 ;;; Potential cause: a self-race in window U, or by the revert's
1785 ;;; landing during window X of some other user's steal-lock or window S
1786 ;;; of another user's revert.
1787 ;;;
1788 ;;; RCS: succeeds, refreshing the file from the identical version in
1789 ;;; the master.
1790 ;;; SCCS: fails with error ut4 (p file nonexistent).
1791 ;;;
1792 ;;; Either of these consequences is acceptable.
1793 ;;;
1794 ;;; 11. File is locked by calling user. It looks unchanged, but is actually
1795 ;;; changed.
1796 ;;;
1797 ;;; Potential cause: the file would have to be touched by a self-race
1798 ;;; during window Q.
1799 ;;;
1800 ;;; The revert will succeed, removing whatever changes came with
1801 ;;; the touch. It is theoretically possible that work could be lost.
1802 ;;;
1803 ;;; 12. File looks like it's locked by the calling user and unchanged, but
1804 ;;; it's actually locked by someone else.
1805 ;;;
1806 ;;; Potential cause: a steal-lock in window V.
1807 ;;;
1808 ;;; RCS: co error: revision <rev> locked by <user>; use co -r or rcs -u
1809 ;;; SCCS: fails with error un2
1810 ;;;
1811 ;;; We can pass these errors up to the user.
1812 ;;;
1813 ;;; Apparent state D ---
1814 ;;;
1815 ;;; 13. File looks like it's locked by the calling user and changed, but it's
1816 ;;; actually unregistered.
1817 ;;;
1818 ;;; Potential cause: master file got nuked during window P.
1819 ;;;
1820 ;;; RCS: Checks in the user's version as an initial delta.
1821 ;;; SCCS: will fail with error ut4.
1822 ;;;
1823 ;;; This case is kind of nasty. It means VC may fail to detect the
1824 ;;; loss of previous version information.
1825 ;;;
1826 ;;; 14. File looks like it's locked by the calling user and changed, but it's
1827 ;;; actually unlocked.
1828 ;;;
1829 ;;; Potential cause: self-race in window V, or the checkin happening
1830 ;;; during the window X of someone else's steal-lock or window S of
1831 ;;; someone else's revert.
1832 ;;;
1833 ;;; RCS: ci will fail with "no lock set by <user>".
1834 ;;; SCCS: delta will fail with error ut4.
1835 ;;;
1836 ;;; 15. File looks like it's locked by the calling user and changed, but it's
1837 ;;; actually locked by the calling user and unchanged.
1838 ;;;
1839 ;;; Potential cause: another self-race --- a whole checkin/checkout
1840 ;;; sequence by the calling user would have to land in window R.
1841 ;;;
1842 ;;; SCCS: checks in a redundant delta and leaves the file unlocked as usual.
1843 ;;; RCS: reverts to the file state as of the second user's checkin, leaving
1844 ;;; the file unlocked.
1845 ;;;
1846 ;;; It is theoretically possible that work could be lost under RCS.
1847 ;;;
1848 ;;; 16. File looks like it's locked by the calling user and changed, but it's
1849 ;;; actually locked by a different user.
1850 ;;;
1851 ;;; RCS: ci error: no lock set by <user>
1852 ;;; SCCS: unget will fail with error un2
1853 ;;;
1854 ;;; We can pass these errors up to the user.
1855 ;;;
1856 ;;; Apparent state E ---
1857 ;;;
1858 ;;; 17. File looks like it's locked by some other user, but it's actually
1859 ;;; unregistered.
1860 ;;;
1861 ;;; As case 13.
1862 ;;;
1863 ;;; 18. File looks like it's locked by some other user, but it's actually
1864 ;;; unlocked.
1865 ;;;
1866 ;;; Potential cause: someone released a lock during window W.
1867 ;;;
1868 ;;; RCS: The calling user will get the lock on the file.
1869 ;;; SCCS: unget -n will fail with cm4.
1870 ;;;
1871 ;;; Either of these consequences will be OK.
1872 ;;;
1873 ;;; 19. File looks like it's locked by some other user, but it's actually
1874 ;;; locked by the calling user and unchanged.
1875 ;;;
1876 ;;; Potential cause: the other user relinquishing a lock followed by
1877 ;;; a self-race, both in window W.
1878 ;;;
1879 ;;; Under both RCS and SCCS, both unlock and lock will succeed, making
1880 ;;; the sequence a no-op.
1881 ;;;
1882 ;;; 20. File looks like it's locked by some other user, but it's actually
1883 ;;; locked by the calling user and changed.
1884 ;;;
1885 ;;; As case 19.
1886 ;;;
1887 ;;; PROBLEM CASES:
1888 ;;;
1889 ;;; In order of decreasing severity:
1890 ;;;
1891 ;;; Cases 11 and 15 under RCS are the only one that potentially lose work.
1892 ;;; They would require a self-race for this to happen.
1893 ;;;
1894 ;;; Case 13 in RCS loses information about previous deltas, retaining
1895 ;;; only the information in the current workfile. This can only happen
1896 ;;; if the master file gets nuked in window P.
1897 ;;;
1898 ;;; Case 3 in RCS and case 15 under SCCS insert a redundant delta with
1899 ;;; no change comment in the master. This would require a self-race in
1900 ;;; window P or R respectively.
1901 ;;;
1902 ;;; Cases 2, 10, 19 and 20 do extra work, but make no changes.
1903 ;;;
1904 ;;; Unfortunately, it appears to me that no recovery is possible in these
1905 ;;; cases. They don't yield error messages, so there's no way to tell that
1906 ;;; a race condition has occurred.
1907 ;;;
1908 ;;; All other cases don't change either the workfile or the master, and
1909 ;;; trigger command errors which the user will see.
1910 ;;;
1911 ;;; Thus, there is no explicit recovery code.
1913 ;;; vc.el ends here