Stephen Leake <[EMAIL PROTECTED]> writes:
> Matthieu Moy <[EMAIL PROTECTED]> writes:
>
>> So, instead of
>>
>> status-buffer ---[list]---> commit
>>
>> status-buffer ---[list]---> cleanup
>>
>> I'm suggesting
>>
>> status-buffer ---[list]---> commit ----[list]---> cleanup.
>> diff-buffer ----[list]-----/
>>
>> (that's not much difference anyway).
>
> Exactly. The "[list]" is the ewoc list of marked files in the
> appropriate buffer; the dvc-partner-buffer of the dvc-log-edit buffer.
> That is the list I was refering to.
What I mean by "list" on the right hand side is the list of files to
commit.
If you mark files "foo" and "bar" in the status buffer, and then
commit from there, commit will get that list from the buffer, and then
should pass _that list_ to the function doing the cleanup.
That is: it should call
(dvc-whatever-refresh-function-name '("foo" "bar")).
The refresh function doesn't have to take the list from any kind of
ewoc, buffer local variable or so. It's very simple to pass them as
argument, and _that_ is robust to anything. The same function tells
the tool "commit with files "foo" and "bar"" (i.e.
(dvc-run-dvc-async ... "foo" "bar" ...)), and call the cleanup with
the very same list.
> However, I looked at bzr and xmtn, and they do this slightly differently.
>
> bzr uses dvc-current-file-list from the dvc-partner-buffer in
> bzr-dvc-log-edit-done.
>
> xmtn uses the same list, but caches the result in a new buffer-local
> variable in xmtn-dvc-log-edit instead.
>
> Actually, I don't like that; I typically call dvc-log-edit first, then
> review all the diffs, accumulating comments in the log edit buffer.
> That means no files are marked when I call dvc-log-edit, so all files
> are cached. But sometimes I decide to do a partial commit, and start
> marking files. Then the cached list is wrong, and the only way to
> refresh it is to call dvc-log-edit again. I've put a fixme on this.
Yes, that's a problem. We had a discussion about the best way to do
that a very long time ago (for Xtla). IIRC, the idea was suggested by
a user, and we're just doing more or less the same as PCL-CVS.
The list should be obtained from the buffer at commit time, since you
may well go back to the status/diff buffer after opening the log
buffer, and decide to select/unselect files from there, and go back to
the log buffer by any way (C-x b, C-x o for example). But the buffer
you're comming from is memorized at the time you run log-edit (C-x V
c, or 'c' in most DVC buffers).
>> Yes, but both should be cleaned-up according to the same list. You can
>> mark files in the diff buffer, then commit, and you want the status
>> buffer to be cleaned-up according to the list in diff buffer.
>
> Ah. That would be a problem.
It isn't if you apply my suggestion. Just don't grab the list from the
buffer, but take it from the function doing the commit.
> You can also have the same problem with two diff buffers on the same
> workspace. DVC avoids having two diff buffers with the same root, but
> you can have a root view and several subtree views that would
> conflict.
Most (all?) back-ends have only full-tree diff at the moment, but it
could definitely change.
> I prefer to fall back on "don't do that"; ie, don't have a diff buffer
> and status buffer open on the same workspace at the same time. That is
> an example of a user-induced race condition. There are other "cleanup"
> actions that should be applied to both (ie, revert), which is a lot of
> work.
Not really. Anyway, you have to find the buffer to cleanup. Once you
have the code that finds *one* buffer (all DVC buffers are in
`dvc-buffers-tree'), you have it to find a list of buffer. One
(dolist ...) later, you've got it.
> Perhaps DVC should simply refuse to open a diff view if a status
> view is already open, and vice versa. But that's too strong right
> now.
I *usually* have either one or the other, but it's quite common to
start with status, to get an overview, and then to open a diff buffer
to view the details. I find this natural, and I see no reason to drop
this feature.
In any case, that doesn't remove the "subtree diff" problem mentionned
above. Better be more general.
> It is tempting here to say "don't bother with the cleanups, just
> refresh". But for my main workspace, on my 3-month-old laptop, DVC
> status refresh with monotone takes 15 seconds; too long to do
> casually. And that will only get longer as the workspace gets bigger.
> Even for a faster back-end, eventually workspaces will be large enough
> that refreshing will be too slow.
Yes, and some back-ends can rely on the network for some operations,
which can be slow sometimes.
It can be interesting to have an option to fall-back to the "rerun the
back-end to refresh" behavior, but that must definitely remain
optional (that can be interesting with hg and git for not-too-large
projects. On a modern machine, git can diff the Linux kernel tree
in around 0.3 seconds for example. If ran asynchronously, you don't
even notice).
> Hmm. I suppose it's possible that some back-ends, and Emacs, will
> start taking advantage of parallel processing, and then this statement
> might be false
I've seen people saying "with the increased computation power, X, Y
and Z won't be a problem anymore in 2 to 3 years" for around 15 years
now, and ... ;-)
--
Matthieu
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
