Matthieu Moy <[EMAIL PROTECTED]> writes: > [ side note: do we have an easy way to get the corresponding diff for > such notification messages? I'm bzr diff-ing manually, but it would > be nice to have it automatized, as we used to have for Xtla ].
Ah; a keystroke in Gnus that would bring up a dvc-diff buffer for the commit in the current email. It could prompt for the root directory. I do that by pulling, updating, and then diffing. > Let's be constructive, I'll stop arguing against the rational for this > patch, but some points need to be fixed: > > Stephen Leake <[EMAIL PROTECTED]> writes: > >> Committed revision 258 to http://stephe-leake.org/dvc > >> === modified file 'lisp/dvc-buffers.el' >> --- lisp/dvc-buffers.el 2007-09-20 18:49:38 +0000 >> +++ lisp/dvc-buffers.el 2007-09-26 11:21:32 +0000 >> @@ -183,6 +183,18 @@ >> return-buffer dvc default-directory) >> return-buffer))) >> >> +(defun dvc-type-buffers (type) >> + "Return the list of all buffers of type TYPE." >> + (let ((result nil) >> + (tree dvc-buffers-tree)) >> + (while tree >> + (let ((entries (cdr (assoc type (car tree))))) >> + (while entries >> + (setq result (cons (nth 1 (car entries)) result)) >> + (setq entries (cdr entries)))) >> + (setq tree (cdr tree))) >> + result)) >> + > > That's not a really interesting thing to do: what you want here is to > find all buffers of type TYPE, for a given back-end, and for a given > tree root. Yes, except we don't know the back-end. dvc-buffer-current-active-dvc is not set in source buffers, so we have to ignore back-end while searching, and get the back-end from the log-edit buffer. We also don't know the root precisely. Consider this use case: project_1_root _MTN .bzr project_1_dir_A project_1_dir_B lib_proj_root .bzr lib_proj_dir_A 'lib_proj_root' is a "library project", intended to be shared among "user projects". 'project_1_root' is a "user project". But this user just wants one mtn database containing everything, while keeping the bzr databases separate. I have actually done things like this, when I didn't like the bzr organization, but wanted to keep traceability. Logically, there can be three log-edit buffers; (xmtn project_1_root), (bzr project_1_root), (bzr lib_proj_root). We'd like to be able to pick the right one even if all three are present. We also have to reject log-edit buffers that are for other projects. The worst case is searching for a log-edit buffer from lib_proj_dir_A/foo/bar.el. My approach would be; 1) Get the list of _all_ log_edit buffers this is cheap 2) Keep only those where default_directory is under the root this is more expensive; comparing partial paths. Ah. We could combine steps 1 and 2 into a new variant of dvc-get-buffer, and do both checks in one pass thru dvc-buffers-tree. That's a good idea. We could call it "dvc-get-matching-buffers". It could also accept a dvc parameter, but ignore it if nil. I had been thinking we could avoid the path check, but as you point out below, we can't. 3) If there is only one, we're done. If none, create one (possibly prompting for the associated status or diff buffer). 5) If more than one for the same back-end, keep the closest root (lib_proj_dir_A is closer to lib_proj_root than project_1_root). This allows reviewing for both bzr databases in parallel. 6) There could still be two at this point; for mtn and bzr. Then we have to prompt, or have some global "prefer-this-back-end-now" variable. I don't like the global variable; it's too easy to forget to change it. Maybe there is a way to set such a variable intelligently from dvc-diff-ediff, but there are other use cases that would still get confused. The user will learn not to review for mtn and bzr in parallel :). > That's what dvc-get-buffer is meant for, except that it gets only one > buffer (but that's what we want here, since there cannot (shouldn't ?) > be multiple log-edit buffers for the same tree): Yes, there can, as above. >> (defun dvc-get-buffer (dvc type &optional path mode) >> "Get a buffer of type TYPE for the path PATH. I don't think this works if PATH is other than root; I haven't checked. Currently, the code typically gets PATH and DVC by calling dvc-current-active-dvc, which does the wrong thing in the case above, unless dvc-buffer-current-active-dvc is set properly (which it isn't in source buffers). > I played a bit with your patch, and using dvc-type-buffers makes it > far too restrictive: having a *bzr-log-edit* buffer lying somewhere > about a totally different tree prevented me from using the local > *xgit-log-edit*. Yes, solution 0 is only the first step. Solution 1 starts adding intelligent picking of the right log-edit buffer, as above. > Furthermore, ... > >> + (if log-edit-buffers >> + (if (= 1 (length log-edit-buffers)) >> + ;; There is only one log-edit buffer; use it >> + (dvc-log-edit) > > That can also fail, because log-edit-buffers can contain one buffer, > which isn't the one of the local tree. Yes. Nice catch. I've incorporated that in the above algorithm. >> -Inserts the entry in the arch log file instead of the ChangeLog." >> +Inserts the entry in the dvc log-edit buffer instead of the ChangeLog." > > Nice catch ;-) ! Thanks. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
