[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Further VC tuning is blocked
From: |
Tom Tromey |
Subject: |
Re: Further VC tuning is blocked |
Date: |
Fri, 04 Jan 2008 19:59:05 -0700 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.990 (gnu/linux) |
>>>>> "Eric" == Eric S Raymond <address@hidden> writes:
Eric> I think I've reached the limit of what I can do to speed-tune VC,
Eric> pending one of the following developments:
I found one more thing I don't understand here.
I tried this:
(defadvice vc-svn-command (before lala-reg
(buffer okstatus file-or-list &rest flags) activate)
(message "running svn %s %s" file-or-list (apply 'concat flags)))
Then I ran C-x v d on gcc.
I see 16 separate execs of 'svn':
running svn /home/tromey/gnu/Trunk/trunk/gcc/ status-v
running svn nil status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/cscope.in.out status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/cscope.out status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/cscope.po.out status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/REVISION status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/TAGS status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/TAGS.sub status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/cp/TAGS status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/cp/TAGS.sub status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/fortran/TAGS status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/fortran/TAGS.sub status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/java/TAGS status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/java/TAGS.sub status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/objc/TAGS status-v
running svn /home/tromey/gnu/Trunk/trunk/gcc/objc/TAGS.sub status-v
Many of these files are actually ignored. Maybe running 'svn status
-v --no-ignore' would be better. I hacked this in to
vc-svn-dir-state, but to my surprise it didn't help.
Second, note the second line of the trace. We are running 'svn status
-v' twice on the whole tree, once with the directory name as an
argument, and once with default-directory set (and no explicit
argument). (FWIW the --no-ignore hack affected this second line in a
subsequent test, but nothing else. So the other calls are not from
vc-svn-dir-state -- you probably know this.)
Anyway, I think there's still a bit of room for improvement here. I
think it should be possible to invoke svn a single time for this
particular scenario.
Tom