bug#1046: 23.0.60; vc-dir with Subversion

[Nick Roberts <nickrob@snap.net.nz>]

 > >> In the past I've remarked that with CVS vc-dir ignores vc-stay-local (and
 > >> vc-cvs-stay-local) and consults the repository, in any case.
 > >
 > > Can you file a separate bug for that please, if it still applies?
 > 
 > Never mind. For a limited time only, your initial bug report entitles
 > you to one complimentary patch for a second issue.

I've glanced over it and tried it out and it looks good to me.

Thanks,
Nick

 > 
 > *** vc-cvs.el	7 Sep 2008 20:24:27 -0000	1.148
 > --- vc-cvs.el	1 Oct 2008 23:02:15 -0000
 > ***************
 > *** 905,912 ****
 > --- 905,943 ----
 >     ;;   (funcall update-function result)))
 >     )
 >   
 > + ;; Based on vc-cvs-dir-state-heuristic.

Perhaps mention that this function is only in pre Emacs 23.  I'm not sure that
I understand the current naming convention.  Some functions now use 'status':
vc-cvs-dir-status, while others still use 'state': vc-cvs-state-heuristic.

 > + (defun vc-cvs-dir-status-heuristic (dir update-function &optional basedir)
 > +   "Find the CVS state of all files in DIR, using only local information."
 > +   (let (file basename status result dirlist)

(let (result dirlist)

 > +     (with-temp-buffer
 > +       (vc-cvs-get-entries dir)
 > +       (goto-char (point-min))
 > +       (while (not (eobp))
 > +         (if (looking-at "D/\\([^/]*\\)////")
 > +             (push (expand-file-name (match-string 1) dir) dirlist)
 > +           ;; CVS-removed files are not taken under VC control.
 > +           (when (looking-at "/\\([^/]*\\)/[^/-]")
 > +             (setq basename (match-string 1)
 > +                   file (expand-file-name basename dir)
 > +                   status (or (vc-file-getprop file 'vc-state)
 > +                              (vc-cvs-parse-entry file t)))

(let ((basename (match-string 1))
      (file (expand-file-name basename dir))
      (status (or (vc-file-getprop file 'vc-state)
                  (vc-cvs-parse-entry file t))))

No big deal.  Perhaps a bit clearer.

...

-- 
Nick                                           http://www.inet.net.nz/~nickrob