Matthieu Moy <[EMAIL PROTECTED]> writes: > What I'm suggesting is to keep the list of files to commit and to pass > it to the commit hook. > > Commit does not just take "the list of marked files". It takes "the > list of marked files /in the buffer you're comming from/". The status > buffer doesn't know which buffer to take the list from. > > 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. 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. >> I don't see why you would have both a diff buffer and a status buffer >> view of the same information. But if you did, they should both be >> cleaned up together. > > 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. 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. Although in this case the xmtn approach would work; there is a separate variable, local to the log-edit-buffer, holding the list of committed files. So perhaps we should keep that approach, but create the list in dvc-log-edit-done, not dvc-log-edit. 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. 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. It is useful to have a "read-only" diff view in parallel with a status view, since that is a good way to review lots of small changes. Here "read-only" means at least "can't commit from here"; it may need to mean more than that (ie, "can't revert from here"). We've talked about that before in another thread. Although even then, it would be best to apply the commit and revert cleanups, and probably some others, to both views. More work :(. In particular, this would probably require getting the diff hunks into individual ewoc entries. I'm less clear what this means for subtree diff views. Should they be "read-only"? 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. 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 (because processing power could grow with workspace size). But I doubt it :). Can you imagine populating an ewoc from parallel threads? That would be a reason to switch to Eclipse; at least the Java language has a notion of concurrency :). To be truly responsive on very large workspaces, DVC must do whatever local actions it can, without running the long back-end operations unless absolutely necessary (and only when explicitly requested by the user). That is one of the most attractive features of pcvs. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
