This patch is a (bad) attempt to allow deleting unknown files from the
disk via the *bzr-status* buffer (started with dvc-status).
=== modified file 'lisp/bzr.el'
--- lisp/bzr.el 2007-03-31 19:02:19 +0000
+++ lisp/bzr.el 2007-04-08 01:23:49 +0000
@@ -1,6 +1,6 @@
;;; bzr.el --- Support for Bazaar 2 in DVC
-;; Copyright (C) 2005-2006 by all contributors
+;; Copyright (C) 2005-2007 by all contributors
;; Author: Matthieu Moy <[EMAIL PROTECTED]>
;; Contributions from:
@@ -493,7 +493,20 @@
(dvc-run-dvc-sync 'bzr (append '("remove") files)
:finished (dvc-capturing-lambda
(output error status arguments)
- (message "bzr remove finished"))))
+ (message "bzr remove finished"))
+ :error
+ (lambda (output error status arguments)
+ (let* ((file (nth 1 arguments))
+ (msg "is not versioned")
+ (unknown (with-current-buffer error
(search-forward msg (point-at-eol) t))))
+ (if unknown
+ (delete-file file))))))
(defun bzr-is-bound (&optional path)
"True if branch containing PATH is bound"
-----------
There are (at least) three problems with this approach:
1) It's inefficient; it runs bzr against files that dcv knows to be
unknown to bzr.
2) It doesn't work on file lists, because the error buffer only
contains the last file in the list (perhaps that is the first file
processed by bzr, and it gives up immediately; I'm not sure).
3) It's unreliable; when 'files' is a single file, it is an absolute
path name, which does not match the relative file name in the error
message.
One way to address all three problems is to pass to the backend the
ewoc cookie elements for the files, rather than just the file names.
It would allow bzr-remove-files to check for 'unknown', and not call
bzr.
Alternately, dvc could handle 'unknown' at the top level, before
dispatching to bzr-remove-files. That would have the advantage of
providing this behavior uniformly to all backends.
Passing the ewoc cookies to the backend functions may be useful for
other operations, but is clearly a large change. On the other hand,
deleting 'unknown' files is probably the only operation that dvc can
handle without the backend, and it doesn't seem reasonable to have
such an exception. So I'm not clear which is the better way to go.
If the ewoc cookies are passed to the backend, there need to be access
functions for the fields, to allow the cookie structure to change.
Thoughts?
--
-- Stephe
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
