Stefan Reichör <[EMAIL PROTECTED]> writes: > 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?
bzr: delete (defalias 'bzr-dvc-missing 'bzr-missing) rename current bzr-missing to bzr-dvc-missing tla: rename current tla-missing to tla-missing-1 or something. xdarcs: delete (defalias 'xdarcs-dvc-missing 'xdarcs-missing) rename current xdarcs-missing to xdarcs-dvc-missing xhg: rename current xhg-missing to xhg-missing-1 or something. Similarly for <back-end>-pull > What is the benefit for the developers? Mostly for new front-ends; no need to define both <back-end>-dvc-foo and <back-end>-foo. Also less maintenance of current code, as dvc-foo is changed/improved. > What is the benefit for the users? If they have a workspace that is controlled by two back-ends, they can specify the back-end explicitly by using <back-end>-foo instead of dvc-foo. Also, a more uniform set of commands. I just went thru this process for dvc-status, since I wanted to be able to do bzr-status or xmtn-status explicitly. I discovered a feature (prompting for the tree directory, with mode options) in the baz-status back-end that is now in the dvc-status front-end, and therefore shared by all back-ends. I suspect there are similar features scattered around; the process of cleaning things up for the rest of the dvc-unified commands may uncover them. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
