Matthieu Moy <[EMAIL PROTECTED]> writes:
> Stephen Leake <[EMAIL PROTECTED]> writes:
>
>> Thus it would seem reasonable that _all_ dispatching functions that
>> are interactive should be in dvc-back-end-wrappers.
>
> A function which is defined with `define-dvc-unified-command' doesn't
> need that, since by definition, there is already a <back-end>-whatever
> command for each back-end.
Well, no; the back-end commands defined by define-dvc-unified-command
all have "dvc" in the name; the wrappers generated by
dvc-back-end-wrappers do not.
For example, bzr has both bzr-dvc-log-edit-done and bzr-lot-edit-done
(aliased to each other), but xmtn has only xmtn-dvc-log-edit-done.
So that is confusing.
In addition, calling the back-end function directly is _not_ the same
as calling the unified function; in many cases the defaults for the
interactive arguments are different. So using wrappers generated via
dvc-back-end-wrappers gives more consistent behavior.
> `dvc-back-end-wrappers' is only needed when an interactive function is
> defined with (defun dvc-<command> ...), with dvc-<command> actually
> doing some dispatching later on.
And only when the corresponding function is _not_ already defined by
the back-end.
> I've put the ones I found in the current definition, can you point out
> the missing ones you're thinking of?
Well, this was instructive. First I found a list of all dispatching
functions; I grep'd for 'dvc-function', 'dvc-apply', and
'define-dvc-unified-command'. Here's that list:
interactive
dvc-function
"tree-root" - called from dvc-tree-root
dvc-apply
"dvc-add-files" - from dvc-add-files
"dvc-revert-files" - from dvc-revert-files
"dvc-remove-files" - from dvc-remove-files
"dvc-diff" - from dvc-diff
"dvc-status" - dvc-status
"dvc-log" - dvc-log
"dvc-command-version" - dvc-command-version
define-dvc-unified-command
dvc-file-diff
dvc-changelog
dvc-add
dvc-resolved
dvc-rename
dvc-log-edit-done
dvc-edit-ignore-files
dvc-ignore-files
dvc-missing
dvc-inventory
dvc-save-diff
dvc-update
dvc-pull
dvc-merge
dvc-submit-patch
dvc-send-commit-notification
non-interactive
dvc-function
"default-global-argument" - from dvc-run-dvc-async, dvc-run-dvc-sync
"prepare-environment" - ""
"revision-get-file-revision" - from dvc-revision-get-file-in-buffer
"revision-get-previous-revision" - ""
"revision-get-last-revision" - ""
"diff-mode" - from dvc-prepare-changes-buffer,
dvc-show-changes-buffer
"dvc-search-file-in-diff" - defined in
dvc-prepare-changes-buffer, called from dvc-diff-diff-or-list
"insinuate-gnus" - from dvc-insinuate-gnus
"dvc-files-to-commit" - from dvc-log-insert-commit-file-list
"tree-root" - from dvc-current-active-dvc
"revision-list-entry-patch-printer" - from dvc-revlist-printer
"revision-refresh-maybe" - from dvc-revision-refresh-maybe
"revlog-mode" - from dvc-revlog-show-revision
"dvc-revlog-get-revision" - from dvc-revlog-revision-in-buffer
dvc-apply
"dvc-log-edit-file-name-func" - from dvc-log-edit-file-name
"revision-st-message" - from
dvc-revision-log-message-at-point
"dvc-file-has-conflict-p" - from dvc-find-file-hook
"dvc-last-revision" - from dvc-diff
"dvc-log-edit" - dvc-log-edit
"dvc-backend-ignore-file-extensions" - dvc-ignore-file-extensions
"dvc-backend-ignore-file-extensions-in-dir" - ""
define-dvc-unified-command
dvc-delta
dvc-name-construct
dvc-revision-direct-ancestor
dvc-revision-nth-ancestor
Of these, the ones in the categories interactive/dvc-function,
interactive/dvc-apply, and interactive/define-dvc-unified-command are
candidates for dvc-back-end-wrappers.
Here are the details of what functions are defined by what backends
for that set, excluding define-dvc-unified-commands to keep it short.
Note that this may be wrong; there are so many ways to define
functions! I grep'd for "(def.*-<foo>" to generate this list.
not in dvc-back-end-wrappers:
"tree-root" - from dvc-tree-root
<back-end>-dvc- defined in baz, bzr, tla, xdarcs, xgit, xhg
<back-end>- defined in baz, bzr, tla, xdarcs, xgit, xhg, xmtn
note that <back-end>-dvc-tree-root is not needed; we should delete
these.
"dvc-diff" - from dvc-diff
<back-end>-dvc- defined in baz, bzr, tla, xdarcs, xgit, xhg, xmtn
<back-end>- defined in baz, bzr, xdarcs, xgit, xhg
"dvc-status" - dvc-status
<back-end>-dvc- defined in baz, bzr, tla, xdarcs, xgit, xhg, xmtn
<back-end>- defined in bzr, xdarcs, xgit, xhg
"dvc-log" - dvc-log
<back-end>-dvc- defined in baz, bzr, tla, xgit, xhg, xmtn
<back-end>- defined in bzr, xgit, xhg
"dvc-command-version" - dvc-command-version
<back-end>-dvc- defined in baz, bzr, tla, xdarcs, xgit, xhg, xmtn
<back-end>- defined in baz, bzr, tla, xdarcs, xgit, xhg
The gaps in the above table indicate missing back-end-specific
functions; for example, the user cannot call baz-log, tla-log,
xmtn-log; they have to call baz-dvc-log etc. They cannot tell which to
call except by experimenting.
in dvc-back-end-wrappers:
"dvc-add-files" - from dvc-add-files
<back-end>-dvc- defined in bzr, tla, xgit, xhg, xmtn
<back-end>- defined in bzr, tla, xdarcs, xgit, xhg
"dvc-revert-files" - from dvc-revert-files
<back-end>-dvc- defined in bzr, tla, xdarcs, xgit, xhg, xmtn
<back-end>- defined in bzr, xdarcs, xgit, xhg
"dvc-remove-files" - from dvc-remove-files
<back-end>-dvc- defined in bzr, tla, xdarcs, xgit, xhg, xmtn
<back-end>- defined in bzr, xdarcs, xgit, xhg
These "<back-end>-" definitions are hidden by the wrappers generated
by dvc-register-dvc, because the wrappers are always defined after the
back-end functions, at least for the back-ends I've checked.
You posted a fix for this in rev 277, which I haven't gotten yet. It
removes the "<back-end>-" definitions, leaving only the wrappers. But
it seems very fragile (as you discovered on your first attempt :);
lots of other similar functions are defined by aliases that define
"<back-end>-dvc-<foo>" as "<back-end>-<foo>", and if anyone introduces
a new interactive function, it is not clear what pattern they should
follow. I guess that can be covered by documentation in DVC-API.
In addition, dvc-back-end-wrappers contains these two entries:
("ignore-file-extensions" (file-list))
("ignore-file-extensions-in-dir" (file-list)))
There is a function dvc-ignore-file-extensions, which does some
front-end stuff and then dispatches to the back-end function
<backend>-dvc-backend-ignore-file-extensions. And similarly for
"-in-dir". So these wrappers make sense, but don't follow the "normal"
dvc naming conventions (I added them before I was really familiar with
the naming conventions). On the other hand, if this alternate naming
convention was used uniformly, there would be no possibility of
dvc-back-end-wrappers breaking something.
So back to the original question of "what is the policy on putting
functions in dvc-back-end-wrappers". If the intent is to have
back-end-specific functions named "<back-end>-foo" (_without_ "dvc")
for all interactive dispatching functions, then the missing functions
are :
dvc-diff dvc-status dvc-log dvc-command-version
dvc-file-diff dvc-changelog dvc-add dvc-resolved dvc-rename
dvc-log-edit-done dvc-edit-ignore-files dvc-ignore-files
dvc-missing dvc-inventory dvc-save-diff dvc-update dvc-pull
dvc-merge dvc-submit-patch dvc-send-commit-notification
Some of these will need back-end aliases removed, or other fixes.
If the intent is only to have _some_ back-end specific function,
without a clear naming convention, then there are no missing functions
now, but it's not clear how to ensure that new functions are added
consistently.
--
-- Stephe
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
