Matthieu Moy <[EMAIL PROTECTED]> writes:

> The _point_ of `define-dvc-unified-command' is to create a dvc-*
> function that only calls <back-end>-*.

Well, ok.

But we've been moving away from that; see dvc-add-files,
dvc-revert-files, dvc-remove-files, and now dvc-log-edit. 

These all have moved some of the user interface code out of the
back-end into the front-end, with the idea of making the DVC UI more
consistent across back-ends.

> _If_ we decide to implement dvc-status another way, with some DVC code
> before doing the dispatching, then we have at least two options:
>
> * stop using `define-dvc-unified-command', and do it the other way
>   around: implement dvc-status, and use `dvc-back-end-wrappers' for
>   that.
>
> * have dvc-status call bzr-dvc-status, which in turn would call
>   dvc-status-internal, which itself is the implementation.

Or, as above, refactor what is done in the front- and back-end
functions with the same name.

If we want to keep functions defined by define-dvc-unified-command as
very thin dispatchers, then we need another convention for the common
DVC front-end UI functions.

>> The names get confusing; some dvc dispatching functions are named
>> <back-end>-dvc-foo, while others are named <back-end>-foo. So it looks
>> like <back-end>-log-edit is supposed to be back-end for the
>> dispatching dvc-log-edit, when in fact it is not. I'm not sure what to
>> do about this.
>
> I'm not 100% clear about the best method either, but what we have now
> is roughly:
>
> * <back-end>-something is a user-callable function.
>
> * dvc-something is a DVC-unified function that acheieve the same goal.
>
> * <back-end>-dvc-something is the target for a dispatching function
>   (dvc-apply, dvc-function), and in most cases, it's an alias for
>   <back-end>-something (without the -dvc-).

That's not quite right. We also have <back-end>-something that are
dispatching targets; grep for 'dvc-function' for a first approximation to
this list. It includes "revision-get-file-revision", "diff-mode",
"tree-root", etc.

-- 
-- Stephe

_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev

Reply via email to