Matthieu Moy <[EMAIL PROTECTED]> writes:
> 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.
The question is "how thick should that interface be?".
At the moment, it is very thin; each backend does whatever it wants.
So the results vary. In particular, xmtn does not provide a summary.
> 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.
Yes, that is the current state.
Is that desired? We can fix it; should we?
> 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).
Yes. And we can _define_ DVC diff to have both. Or not. Which do we want?
Personally, I think it is worth having both dvc-status and dvc-diff,
roughly as they are now. But we should _define_ what dvc expects from
the backend for each, and fix the ones that currently don't.
>> 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.
Ok. I agree that the diff summary is useful. So we should add it to
the xmtn backend dvc-diff implementation.
>> 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/...
Yes, it does get complicated.
> 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.
Part of my point is to move code out of the back-end into the
front-end, where it is shared. Looking thru the back-ends for
dvc-diff, and dvc-status, there is quite a bit of UI stuff that is
common, and could easily be shared.
>> 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.
Right.
> 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").
Ok, that makes sense.
>> 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.
Ok, that does clear up a confusion. Since they were using the same
ewoc structure, I assumed they were generated similarly; but as you
point out, that was an invalid conclusion.
> 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).
Right. In fact, DVC should supply parsers for the standard Gnu diff
formats.
>> 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.
Yes, exactly.
> 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"?
The example you give has a summary at the top, and a standard gnu diff
below. So I don't see how this is different from what bzr does.
I don't have git installed at the moment (I could easily add it; there
is a Cygwin package), and the online manual
http://www.kernel.org/pub/software/scm/git/docs/git-status.html
doesn't describe the output. So I can't speculate further.
However, I think you've asked the question backwards; it should not be
"what should DVC do with this backend feature", but "How do we get
this backend to do what DVC wants". My goal (as I've said before :) is
to have DVC provide a common UI to several back-ends.
On the gripping hand, if there is a good idea in there, we should
consider using it in DVC, and getting the other backends to do it as
well.
> Will you allow commiting from that buffer?
Commiting should be allowed/supported from any buffer that shows
user-edited files and a well-defined place to commit them, that is
supported by the current back-end.
> 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.
I can't parse that. It is precisely _because_ there are commands that
are not in the intersection that we need different modes for diff and
status.
I guess I'm not sure what you mean by "strong" here.
It may be that we should have a common "diff-status-mode", and derive
diff-mode and status-mode from that. I'm not very clear on the
semantics of derived modes in emacs.
If we clearly define what DVC expects from back-ends for diff and
status, then yes, we are adding limitations, because there will be
back-ends that do something more for their "diff-like" and
"status-like" commands. That is the price we pay for a uniform
interface.
It may be that we end up with two DVC interfaces; one uniform across
back-ends, and one much thinner that lets the back-end do whatever it
wants. Or maybe we'll find a happy compromise.
>> 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 ;-).
Ok, good.
One of my primary goals is to make switching to DVC/monotone from
pcvs/cvs as easy as possible, so I don't have to spend a lot of time
hand-holding when I tell my team at work to switch.
>> 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!
Ok, good.
--
-- Stephe
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
