[Message part 3 (text/plain, inline)]
On 17.07.2012 11:20, Michael Albinus wrote:
> (*): There seems to be at least one `call-process' call in vc-git.el,
> which I regard as an error. Maybe you could correct this in your patch,
> too.
Added to the patch, as well as the ChangeLog entries.
> I haven't prepared test cases yet. The basic idea is to have a (test)
> file under git, and to apply some default scenarios with it. Not just
> open, edit, save, commit (that might be the most simple scenario), but
> something which reflects the usual workflow better. Escpecially,
The above is my usual workflow, actually, when repeated several times.
> keeping the file opened in an Emacs buffer, during several workflow
> cycles - this would give cached values the possibility to show their
> power (or not).
Since I have a clear picture in my mind why this wouldn't make a
difference (for one, there's no time-based expiration), I'm having a
hard time choosing a meaningful longer scenario.
So I'm just doing one scenario now. If you write a different one, I can
do that next.
Scenario:
1. git init test (outside of Emacs)
2. find-file in this directory (creating the new file)
3. edit, save, `vc-next-action' (registering the new file)
4. repeat step 3 (makes first commit)
5. repeat step 4 (makes second commit)
6. `vc-rename-file'
7. `vc-next-action' (commit)
8. `vc-delete-file'
(This automatically closes the buffer and leaves the repo with 2 files
removed from the disk and staged for deletion.)
> As we both agree, calling processes is the most time consuming
> action. We might concentrate on counting the number of process calls,
> the other Lisp-based actions are negligible. I would trace all vc-*
> function calls, and `process-file' (*), like this:
>
> (require 'trace)
> (dolist (elt (all-completions "vc-" obarray 'functionp))
> (trace-function-background (intern elt)))
> (trace-function-background 'process-file)
>
> This returns also two different trace buffers, which could be compared
> by ediff easily, in order to see how vc behaves.
Done this twice, logs 1 and 3 - without the patch, 2 and 4 - with the
patch. 1 ~ 3 and 2 ~ 4, so you may just as well compare only one pair.
The difference: a few getprop/setprop calls, and one full uncached
`vc-git-registered' call in `vc-register' (after "git add" was called),
all in favor of the patched version (which doesn't make the above calls).
The last one is interesting, because it shows that `vc-register' doesn't
require `vc-git-registered' to return `t' before it assigns Git backend
to the buffer.
So at the same point where the unpatched code calls `vc-git-registered'
and it finally returns true, the patched code just assumes it's true,
and doesn't call the function. :) A bit risky, but not wrong, at least
in this case.
This would have been different if the file existed and was registered in
the repository before step 2, then the first call to `vc-git-registered'
would have returned `t' in both versions.
P.S. `ediff' says there are no differences after around 43% mark, but
there are. For example, line 1021 in trace-3.log shows a call to
`vc-git-registered', whereas the respective line 979 in trace-4.log
shows that the call is skipped.
Same with `diff' in the console, it ignores these changes, no idea why.
Maybe I just fail at diffing.
--Dmitry
[vc-git.diff (text/plain, attachment)]
[trace-1.log (text/plain, attachment)]
[trace-2.log (text/plain, attachment)]
[trace-3.log (text/plain, attachment)]
[trace-4.log (text/plain, attachment)]
This bug report was last modified 12 years and 362 days ago.