Stephen Leake <[EMAIL PROTECTED]> writes: > 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).
I tried to understand your message. Since I don't have much time at the moment for open source projects, I didn't follow the discussion you mentioned here. What should be changed for the dvc-missing functions? What is the benefit for the developers? What is the benefit for the users? Stefan. _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
