I was recently bit by the fact that vc-bzr uses sha1sum, and external program
to compute the state of a file in vc-bzr-state-heuristic.

This depedency is suprising and buried rather deep. I looked at the code in question
and discovered that vc-bzr is picking apart an internal bzr file to find the state
of a file, bypassing the now expensive call to bzr status.

When the sha1sum program is not found a signal is thrown in a vc find-file hook.
This interruption produces a error message, but also causes the buffer to not appear.

The buffer has been created actually, but the switch to the buffer is not reached due
to the signal. Even worse if you do find the buffer then the vc mode line updates
produce regular errors, and even saving a file was difficult.

On digging a bit further I also realized that the [backend]-state-heuristic is a part
of the vc API, and it looks to me like it is scoped to implement work-arounds for
"stay local" like functionality for revision control systems that do not support
offline as well.

I wrote a quick fix for vc-bzr, and I have included that patch.  It is
however a band-aid solution. It creates a new vc-bzr-state-heuristic function
that switches between the "fast"/heuristic and "slow"/status paths.

After some more thought this sort of a fix might belong in the middle
layer: vc-hooks.  If the error trap and code path switch is
implemented there the backend heuristic functions would have a
real error path, which is needed assuming that they are assumed brittle by
their design role.

Another and possibly parallel solution is to merge a C implementation of sha1
into Emacs itself, which is probably a good idea as well.

Your thoughts are appreciated, and I am willing to reform the patch as necessary,
inclusive of the feedback from the list.



-- 
GnuPG Key: B9012279 is available from HKP server pgp.mit.edu