Matthieu Moy <[EMAIL PROTECTED]> writes: > Stephen Leake <[EMAIL PROTECTED]> writes: > >> So dvc-add-log-entry can't just call dvc-log-edit to reuse a buffer; >> it has to switch to it only. > > Probably it's better to have dvc-log-edit itself reuse the buffer > without setting the partner buffer, so that both log-edit and > add-log-entry benefit of the fix.
Yes. I've committed a change that does this. It needs another parameter to dvc-log-edit, indicating whether this invocation is expecting to fully initialize the buffer or not. >> And dvc-log-edit needs to set dvc-partner-buffer in a way that >> tells dvc-log-edit-done that it should commit the source buffer only. >> Setting dvc-partner-buffer to the source file in this case makes >> sense, but I don't think any of the current back-ends treat that as >> meaning "commit only this file". > > Not AFAIK, and that would be awfully bad to do this silently (one > would really think he's doing a full commit). Right. My change does not yet address this. > I'm not opposed to having a M-x > dvc-log-edit-to-commit-just-this-file RET (probably with a shorter > name ;-) ). 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. That makes it difficult to know whether to re-initialize the buffer or not. >> There is also a problem when there are multiple back-ends for a >> workspace. Currently, to select the back-end, I have the following in >> a text file: >> >> (let ((dvc-temp-current-active-dvc 'bzr)) (dvc-status "/Gnu/dvc-fileinfo/")) >> (let ((dvc-temp-current-active-dvc 'xmtn)) (dvc-status "/Gnu/dvc-fileinfo/")) > > 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/") 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. >> Perhaps dvc-log-edit could prompt the user if two back-ends are >> detected. I'm not sure if we want to put that into >> dvc-current-active-dvc. > > It can be a good idea to add it, if you keep it optional (and disabled > by default), and possibly customizable. Right. dvc-current-active-dvc now does this, if the user option dvc-prompt-active-dvc is non-nil. This prompting is not as annoying as I thought it might be; the cache mechanismin dvc-current-active-dvc resolves many cases that would otherwise need a prompt. I had to improve the caching a bit. > * t => prompt whenever there's a choice. This is done. > * list of strings => list of paths where the user should be > prompted. That looks reasonable. But I didn't implement it this time around; I'm not sure it's needed. > 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. Hmm. xhg has: (defun xhg-dvc-log-edit (&optional other-frame) (dvc-dvc-log-edit)) which is wrong; this won't use xhg if another back-end is present, and higher in dvc-select-priority. It also throws away the 'other-frame' parameter. xgit is the same. I removed these functions; dvc-dvc-log-edit will be used by default. > I think a good solution would be to add it. That can be done > automatically from DVC's core, adding a wrapper function like > > (defun <back-end>-log-edit () > (interactive) > (let ((dvc-temp-current-active-dvc '<back-end>)) (dvc-log-edit))) > > 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>-*. 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. One solution is to insist that all dispatching functions be named <back-end>-dvc-foo. dvc-funcall could be changed to prepend "<back-end>-dvc"; that would enforce it. That might be too big a change to do now. On the other hand, docs/DVC-API implies that this is the naming convention. > Your patch does something that DVC never do AFAIK, which is to have > interference between buffers belonging to one back-end and projects > managed by another back-end (as I pointed out, having a *bzr-log* > buffer for ~/some/bzr/project prevents me from using add-log-entry in > ~/another/project/managed/by/git), Right; the current code in dvc-add-log-entry was much too conservative. My latest commit fixes it; it just calls dvc-log-edit (as it used to). > and the rationale you gave was to solve your nested tree problem. It was a tactical mistake to introduce that nested tree; that was never the main problem. > I'm _precisely_ insisting on solving the add-log-entry problem without > interfering the nested-tree one. *If* you need a solution for > nested-trees, we should implement one. Right. >> Actually, xmtn-dvc-log-edit inserts the entire commit comment, which >> is also a problem for dvc-add-log-entry. > > I didn't really try monotone (yet ;-) ), but my feeling is that xmtn > does not use much DVC, and is mostly an independant interface, with a > few hooks into DVC. That's a pity IMO, since there seem to be a lot of > things in xmtn that could benefit to other back-ends. I have not thoroughly studied all of the xmtn code; my impression is that there are lot things that are not accessible via the current DVC front-end. 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 :). There is stuff in xmtn that could be moved into the dvc core, and be generally useful. > I have no time to dig further, but a quick look at `xmtn-dvc-log-edit' > doesn't show many monotone-specific stuff. It is hard to see. xmtn-dvc-log-edit calls xmtn--insert-log-edit-hints, which inserts the "commit comment". It does more than just the "files to commit", so it is not just an overriding of dvc-files-to-commit. That needs to be sorted out. -- -- Stephe PS. I'm on vacation at the moment, with intermittent email access. _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
