Stefan Reichör <[EMAIL PROTECTED]> writes: > Committed revision 277 to http://bzr.xsteve.at/dvc/ > > xdarcs: Implemented xdarcs-missing
and later: > Committed revision 278 to http://bzr.xsteve.at/dvc/ > > xdarcs: Added a simple implementation for xdarcs-pull: Just pull all > changes via "darcs pull -all" These added the following to xdarcs-dvc.el: ;;;###autoload (defalias 'xdarcs-dvc-missing 'xdarcs-missing) ;;;###autoload (defalias 'xdarcs-dvc-pull 'xdarcs-pull) This raises the issue of exactly what functions belong in dvc-back-end-wrappers, and whether to use aliases for back-end functions. See the thread at https://mail.gna.org/public/dvc-dev/2007-10/msg00050.html That thread did not arrive at a clear policy. The intent is to make it easy for users to handle the case of a workspace that is controlled by more than one back-end. For example, I maintain the dvc-fileinfo branch in bzr (so I can merge from the main dvc branch), and in monotone (for distribution to my team). The user must have a simple way to specify which back-end to use for any interactive dvc dispatching function. The strategy is to always define a function <dvc>-foo that is equivalent to dvc-foo, but specifies the back-end. dvc-back-end-wrappers provides a simple way to do that. Not all back-ends provide `<dvc>-missing', and some provide a function with that name that is _not_ the same as `dvc-missing'. Similarly for dvc-pull: bzr: (defalias 'bzr-dvc-missing 'bzr-missing) (defalias 'bzr-dvc-pull 'bzr-pull) tla: (defun tla-dvc-missing ...) calls tla-missing with computed args (defun tla-missing ...) this takes different arguments than tla-dvc-missing doesn't define tla-dvc-pull xdarcs: (defalias 'xdarcs-dvc-missing 'xdarcs-missing) (defalias 'xdarcs-dvc-pull 'xdarcs-pull) xhg: (defun xhg-dvc-missing (&optional other) (defun xhg-missing ...) This is _not_ the same as xhg-dvc-missing (defun xhg-dvc-pull ... ) (defun xhg-pull ... ) _not_ the same as xhg-dvc-pull xmtn: (defun xmtn-dvc-missing ... ) does not define xmtn-missing (defun xmtn-dvc-pull ... ) does not define xmtn-pull So for consistency, dvc-missing should be in dvc-back-end-wrappers, the alias definitions should be removed, and the current back-end functions named <dvc>-missing should be renamed to either <dvc>-dvc-missing or something else. Similarly for dvc-pull. We need to do a similar review for the other functions defined by dvc-defined-unified-command (I did not review those before). We also need to document this policy. The logical place is in DVC-API. How about the following: To handle the case of a workspace that is controlled by more than one back-end, all dispatching interactive front-end functions dvc-foo should have a corresponding function <dvc>-foo, that specifies which back-end to use. A simple way to provide <dvc>-foo is to put dvc-foo in dvc-back-end-wrappers (in dvc-unified.el); then <dvc>-foo is automatically generated by dvc-register-dvc. This defines <dvc>-foo as (see dvc-register.el for the actual code): (defun <dvc>-foo (<args>) (interactive) (let ((dvc-temp-current-active-dvc <dvc>)) (call-interactively 'dvc-foo))) This means that back-ends may _not_ define a function <dvc>-foo. Note that functions defined by dvc-define-unified-command dispatch to <dvc>-dvc-foo. Calling <dvc>-dvc-foo is _not_ the same as calling <dvc>-foo, since dvc-temp-current-active-dvc is not bound, the interactive argument processing may be different, and <dvc>-dvc-foo may not even exist (if the default dvc-dvc-foo is sufficient). -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
