Matthieu Moy <[EMAIL PROTECTED]> writes: > One drawback though: when starting a new back-end, "diff" is easier to > start with than "delta" (you have to provide revision "ID" - which we > should have called "specifier", but ... - and "diff" can hardcode them > to "(last-revision ...)" and "(local-tree ...)", while "delta" has to > do some more work. > > So, if you rework dvc-diff and dvc-delta, make sure it's still easy to > prototype a new back-end by starting with the most obvious diff.
Right. Although this would make things simpler just by having one less back-end function to implement. <new>-dvc-delta could simply ignore the input revision-ids, and hard-code last-revision and local-tree. >>> or have dvc-diff call the back-end's XXX-dvc-diff, which itself is a >>> wrapper around XXX-dvc-delta. >> >> That's what we have now, except there is no guidance to the backends >> on what they _should_ do, and they do different things. > > doc/DVC-API is an important starting point. I agree it's incomplete, > though. I considered adding _all_ functions called via dvc-apply to that document. But the first list I came up with was long, and I was not sure how to find _all_ of them. So I decided the lisp code was the best/only place to document such things. I've been adding more/better comments on each dispatching function in dvc-unified as I work on them; I'm hoping that will be sufficient in the long run. I've now discovered that there are some dispatching functions defined elsewhere, which makes things more confusing. >> This relates to the issue of what commands are available in the diff >> buffer, and how the files are displayed; if one revision is the >> current working tree, then those files should be directly displayed, >> and commit commands should be available. This could also be done by >> checking the revision id. > > Absolutely. I think it would be best if most of this last paragraph was implemented in the front-end, so that the DVC UI is more consistent across back-ends. So maybe the two user-level functions should be 'dvc-diff' (which diffs any revision against local-tree) and 'dvc-diff-2' (which diffs two arbitrary revisions, neither of which should be local-tree), and they both do some UI setup, and then call a dispatching 'dvc-delta' to get the back-end information. But that's a second refactoring; I won't attempt to do both at once. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
