Re: Further VC tuning is blocked

[Tom Tromey]

>>>>> "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