diff lisp/vc.el @ 14040:187735b53d52

Comment fixes.

--- a/lisp/vc.el	Fri Jan 05 21:57:54 1996 +0000
+++ b/lisp/vc.el	Fri Jan 05 22:21:28 1996 +0000
@@ -827,7 +827,7 @@
 
 (defun vc-resynch-window (file &optional keep noquery)
   ;; If the given file is in the current buffer,
-  ;; either revert on it so we see expanded keyworks,
+  ;; either revert on it so we see expanded keywords,
   ;; or unvisit it (depending on vc-keep-workfiles)
   ;; NOQUERY if non-nil inhibits confirmation for reverting.
   ;; NOQUERY should be t *only* if it is known the only difference
@@ -2006,7 +2006,7 @@
   ;; Automatically retrieves a read-only version of the file with
   ;; keywords expanded if vc-keep-workfiles is non-nil, otherwise
   ;; it deletes the workfile.
-  ;;   Adaption for RCS branch support: if this is an explicit checkin,
+  ;;   Adaptation for RCS branch support: if this is an explicit checkin,
   ;; or if the checkin creates a new branch, set the master file branch
   ;; accordingly.
   (message "Checking in %s..." file)
@@ -2418,7 +2418,7 @@
 ;;; during the entire execution of vc-next-action, or (b) detect and
 ;;; recover from errors resulting from dispatch on an out-of-date state.
 ;;; 
-;;; Alternative (a) appears to be unfeasible.  The problem is that we can't
+;;; Alternative (a) appears to be infeasible.  The problem is that we can't
 ;;; guarantee that the lock will ever be removed.  Suppose a user starts a
 ;;; checkin, the change message buffer pops up, and the user, having wandered
 ;;; off to do something else, simply forgets about it?