Stephen Leake <[EMAIL PROTECTED]> writes: > So having dvc-diff call dvc-delta which calls tla-delta is an > acceptable solution?
>>> We need to merge code in the bzr and xmtn back-ends, and decide what >>> to do about tla. I suggest we just have dvc-delta (and thus >>> dvc-diff) > > My proposal is that dvc-diff does _not_ call dvc-apply, it just calls > dvc-delta. So the back-ends only need to implement dvc-delta. I was not sure to understand your proposal, but that's clear now. This sounds OK to me. 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. >> 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. > 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. -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
