Stephen Leake <[EMAIL PROTECTED]> writes: > But then what should dvc-log-edit do when called from a source buffer? I'm > tempted to say "abort with a nice message", but I'm not clear what you prefer. > > Ah; you should be able to use dvc-log-edit in the way I'm using > dvc-add-log-entry.
Yes, that's what I've been trying to say for some time. dvc-log-edit and dvc-add-log-entry are basically the same, with dvc-add-log-entry inserting something after having switched to the log-edit buffer. >> M-x bzr-status RET >> M-x xmtn-status RET > > Almost; it would have to be: > > (bzr-status "/Gnu/dvc-fileinfo/") > (xmtn-status "/Gnu/dvc-fileinfo/") Yes, but that's orthogonal to the issue of choosing the back-end. > But I'd rather not, because at some point more functionality might be > moved into the dvc front-end, and then I'd lose that. No, you wouldn't. The _point_ of `define-dvc-unified-command' is to create a dvc-* function that only calls <back-end>-*. bzr-status, xmtn-status are declared as interactive, have a user-friendly-name (I mean, not bzr-run-status-internal or so), they are here to be called. _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. The second one has always been available, the first has only been implemented a few days ago. > Right. dvc-current-active-dvc now does this, if the user option > dvc-prompt-active-dvc is non-nil. I'll look at your patch when it's available. >> The one difference I can see between log-edit and status now is that >> there are no <back-end>-log-edit functions that you can call by >> yourself. > > Actually, baz, tla, xgit, xhg, and xmtn provide them. They're not exactly <back-end>-log-edit, but <back-end>-dvc-log-edit. And indeed, that's wrong, these functions are not needed. I'm committing something to just remove them (except for xmtn-dvc-log-edit, which needs longer care to be generic-ized). > I removed these functions; dvc-dvc-log-edit will be used by default. Oops, I should read more carefully before hacking ;-). >> Then, the normal flow would be to call M-x dvc-log-edit RET (or >> keybinding), and users with specific needs can call M-x >> <back-end>-log-edit RET explicitely. >> >> I can try to write a patch doing that ~tonight. > > That would work, and avoid the "lose new features" problem I described > above. > > But I still like the prompt in dvc-current-active-dvc; lots of current > keybindings call dvc-*, I don't want to have to create a parallel set > for <back-end>-*. As I said, I have no problem having this feature, but that would disturb people having independant nested trees, so it really has to be customizable (AAUI, it is in your patch, and if soo, "cool ! :-)"). > 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-). I was disliking it, but I'm starting to like it. That allows us to have <back-end>-something be either the target of a dispatch (with an alias), or a wrapper setting the back-end with `let' and calling the DVC function (with `dvc-back-end-wrappers'). As you said, we can either continue relying on naming conventions, or enforce it in dvc-function. > However, I am trying to use it exclusively thru the DVC front-end, and > it's doing almost all of what I need. I'm working towards reducing the > cases where it doesn't (getting a list of heads is next on the list > :). AFAIK, only mtn and hg have the notion of "multiple heads" (which are roughly temporary unnamed branches AAUI, i.e. a commit which hasn't been merged in the tip yet). There could probably be a M-x dvc-heads RET, that would fail, or fall-back to something listing named branches for back-ends for which it isn't relevant. > PS. I'm on vacation at the moment, with intermittent email access. Ah, I was afraid to be "knock-out winner" ;-). -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
