Stephen Leake <[EMAIL PROTECTED]> writes:
> however, dvc-diff does not include unknown files in the
> summary; is that actually desired, or just what tla happens to do?
dvc-diff just provides an interface to what the underlying tool does.
Most of the time, "$backend diff" shows the difference between the
last revision and what would be the current revision if you commited
now. This does not include unknown files.
OTOH, "$backend status" is usually really working-tree oriented. That
is : show me, in the current working tree, the relevant files, and
in particular what would happen to them if I commited now. It does
include unknown files.
Now, you can very well imagine a command that does both. Indeed,
"git status -v", or "git status -a -v" is exactly that (See at the
bottom for an example for the lazy).
> diff buffers are _also_ useful for other things, like reviewing
> diffs between arbitrary revisions. We don't want to make that
> harder or more confusing.
In particular, I still expect a diff summary in this case.
> The dvc API to the backends should be a separate issue. Some of the
> current design is driven by what one backend happens to do (dvc-diff
> is essentially the output of 'tla changes --diff'), but that is not
> optimal across all backends (or even for tla :).
I'd even say that tla support shouldn't be our priority.
That said, there were a few good ideas in tla. The summary at the top
of the diff buffer comes from there, and I believe this was a good
idea.
One thing also : after a few years trying other VCS, I can say that
tla was a really bad VCS compared to what we have now, but Xtla *was*
a good interface for it. I heard about several persons that started
using tla *because of* Xtla (while it's usually the other way around).
> Ideally, the front end would call a backend function that says "please
> put a status summary in this ewoc", and another one that says "please
> put a diff in this buffer (or ewoc)". The front end should handle
> everything else.
What DVC does is not so far from this, but the problem is more complex
than what you say. DVC actually says "please put the diff between
revision X and Y in this buffer". Then, you have to say what X and Y
are, which is back-end dependant. And then, you want to compute the
diff summary, and for that, you call a parser for the diff you just
obtained, and that is again back-end dependant. So, there are layers
of front-end/back-end/front-end/...
We could factor a little bit more, but we already have much more code
in the back-end than we have in the front-end.
> There are four pieces of the current API we are talking about here:
>
> the functions dvc-status, dvc-diff
> the ewoc structure for the status summary
> the ewoc structure for the diffs
Regarding the diff, the ewoc structure is used for the summary at the
top of the buffer, not for the diff hunk themselves. The summary at
the top "looks like" the output of "status", but it's actually
obtained by parsing the diff (in particular, this avoids running the
tool twice for "status" and "diff").
> xmtn-dvc-diff currently does _not_ put the summary in the diff buffer.
> To add that, we would simply add calls to the appropriate parts of
> xmtn-dvc-status; not hard.
That's not the DVC way. The summary at the top is not "status". You
seem to be using "status" and "summary" indifferently, but you really
have two things :
* The summary at the top of the buffer, which is a kind of table of
contents of the buffer, helps you to get a quick view of it, to
navigate in it, ...
* The status buffer, which shows the output of "status" for the tool.
They use the same ewoc structure, they indeed use the same mode, but
they are different. "status" would be meaningless when you compare two
already commited revisions, while I still want a summary when I'm
seeing any diff, because it might be long.
So, if you wanted to add a summary of the diff, that would be by
parsing the output of diff ("parse" seems to imply a lot of work, but
that's really about re-search-forward-ing "+++ \\(filename\\)" and
such things).
> bzr also has separate code for dvc-diff and dvc-status. The command
> line "bzr diff" does not output a status; I don't see how bzr-diff
> gets the status into the diff-buffer, but I haven't looked very hard.
C-h f bzr-parse-diff RET
> I am working on changing the status summary ewoc structure; when I'm
> fully done, it will be shared between dvc-diff and dvc-status, since
> that does affect the backends.
Hmm, I'm starting to understand something, which I like.
If you manage to make two /modes/, in the sense `define-derived-mode',
keymap, ... but if they actually share all the code regarding the ewoc
structure, how to print it, ... the modes themselves can be small.
I'm still not sure you'll really get any difference between the two
modes if you still allow commiting from the diff buffer (which I want
to have). For example, which mode would you use for "git status -v"?
Will you allow commiting from that buffer?
By trying to make a strong separation between diff and status, you'll
end up adding limitations because some commands will need different
features that are not in the intersection.
> It might be useful to use a real ewoc for the diffs, but that can
> come later if at all.
I had thought of that also. It would be cleaner conceptually, but I'm
not sure it's really interesting in practice.
> I'm also adding features to the UI that I miss in dvc-diff, like
> automatically updating the ewoc to show the results of commands, but
> without calling the backend again, since that's slow.
Year, PCL-CVS does this, and this has been on my todolist for
years ;-).
> This will provide time for people to comment on the new ewoc
> structure, and the new UI features, without breaking a lot of current
> code.
Just to repeat myself, but on another topic: that new ewoc is a great
thing. Another that we had on the todolist for years!
--
Matthieu
[1] An example of "git status -v" :
$ git commit -m foo
Created initial commit 715550e: foo
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ echo bar >> foo
$ git status -a -v
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo
#
diff --git a/foo b/foo
index 257cc56..3bd1f0e 100644
--- a/foo
+++ b/foo
@@ -1 +1,2 @@
foo
+bar
$
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
