Christian Ohler <[EMAIL PROTECTED]> writes:
> Matthieu Moy, 2007-07-07:
>
>> Christian Ohler <[EMAIL PROTECTED]> writes:
>>
>>> After disallowing workspace operations from the diff buffer,
>>
>> Do you really, really, really mean that you want to remove the
>> selective-files commit feature from the diff buffer?
>
> It seems like the least painful alternative. Workspace operations from
> the diff buffer look very nice at first but turn out to be confusing and
> dangerous in general. Yes, we need to fix this somehow. The simplest
> solution is to remove them entirely.
>
> Stephen mentioned the alternative of allowing them (and presumably the
> marking/unmarking) only if the diff shown is between the workspace and
> its base revision. But this adds even more logic, and DVC is complex
> enough as it is. I don't think committing from the diff buffer is
> useful enough to justify the added complexity.
I've thought about this some more, and I think there are three mostly
orthogonal issues that we are talking about, and getting confused:
primary UI style for commits and updates
dvc API to backend
emacs major mode to implement UI
For the primary UI style, some of us prefer the current dvc-diff, some
dvc-status, but I think we all agree there is room for improvement.
Some of the features we agree on:
everyone wants a 'status summary' always
however, dvc-diff does not include unknown files in the
summary; is that actually desired, or just what tla happens to do?
everyone sometimes wants a 'one buffer diff list' for reviewing
all changes in a changeset
dvc-diff provides this, dvc-status does not
It does not necessarily have to be in the same buffer as the
status summary. It should be one buffer showing all diffs in
the changeset, not one buffer per file.
everyone wants the ability to commit from the summary
everyone wants the ability to ediff from the summary or the diff list
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.
Note that I am not recommending anything yet on this issue; I'm just
trying to summarize.
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 :).
However, currently, the backends determine entirely what gets shown
in the buffers. xmtn does not show the status summary in diff buffers,
and the front end has no control over that. We might want to redesign
to change that.
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.
That would make it easy to build different UIs to suit different
needs, without affecting the backends.
Note that I am _not_ proposing to change this at this time; I'm just
daydreaming :).
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
For the functions, tla has:
(defun tla-dvc-status (&optional path)
(tla-changes t nil))
(defun tla-dvc-diff (against path dont-switch)
(tla-changes nil against))
The tla parsers for diff and status are separate
It would not be a big change for tla-dvc-diff to just throw away
the summary information. Or perhaps it could be cached in some
way, anticipating a later dvc-status call.
Apparently 'tla changes --diffs' implies 'no unknown'?
xmtn has significantly different code for dvc-status and dvc-diff;
they share very little above the basic ability to run monotone.
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.
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.
For the ewoc structures, dvc-diff and dvc-status use the same
structure for the status summary. The diff is put in the ewoc footer,
unstructured.
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. It might be useful to use a real ewoc
for the diffs, but that can come later if at all.
Finally, there is the choice of Emacs major mode to implement the UI.
The major mode determines the keymap, the menu, and what functions are
run when the mode is entered. Note that this is orthogonal to the
choices above; entries in the keymap can be any code, not just code
that the major mode defines. Currently, dvc-status creates a buffer in
dvc-diff-mode, and so does dvc-diff. But it is very little work in the
front-end to use different major modes, and with some care it should
be zero work in the backends. Well, we will have to replace
dvc-prepare-changes-buffer with dvc-prepare-status-buffer and
dvc-prepare-diff-buffer, but that should be all. If we redesign the
backend API along the lines I outlined above, even that would be gone.
Using different modes simplifies the choice of key bindings for the
two buffers; it is much easier to not have bindings for things that
don't make sense. Clearly, keys for similar functions should be the
same; that commonality is provided by dvc-ui.el.
It also simplifies other differences, like ediff using actual file
buffers instead of temp buffers.
So I will continue to implement dvc-status-mode. I will focus on
keeping it very small, and sharing as much as possible with
dvc-diff-mode (and the rest of dvc).
The primary work is the new ewoc structure. Since that will be shared
with dvc-diff eventually, I will use neutral names, and put it in it's
own file (that hasn't happened yet).
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.
After I get dvc-status-mode working with monotone, I'll make it work
with bzr. Then I can work on changing dvc-diff to use the new ewoc
structure.
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.
If I discover that it impacts the backends more than I
anticipate, or some other major issue arises, I'll reconsider.
--
-- Stephe
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
