bug#24082: [PATCH] Use ‘cvs update’ instead ‘cvs status’ for CVS *vc-dir* buffers

[Dmitry Gutov]

Hi! Sorry for the long wait.

On 28.08.2016 23:17, Göktuğ Kayaalp wrote:
> Hi, attached is a patch that fixes bug#24082.

Could you help me reproduce the issue locally first?

Either by pointing to a publicly available CVS repo with submodules, or 
by providing a sequence of commands that would create such repo locally 
(we do something like that in vc-tests.el).

> The reason of the bug was that, in function ‘vc-cvs-after-dir-status’,
> the CVS status line ‘cvs status: Examining <dir>’ was excluded when the
> function narrows to match, and when it tries to set the local variable
> ‘subdir’, as it does not find this line, it skips setting it.  As
> ‘subdir’ defaults to ‘default-directory’, which is previously set to
> repo root (i.e. the argument to function ‘vc-dir’, when ‘subdir’ is used
> to construct the relative path to file, concatenating it with the
> already-known file base name, it returns the basename, i.e. in
> the form ‘name.ext’, with no directory path.  This because it constructs
> the relative path like ‘(file-relative-name basename subdir)’.

Could we just fix that, to address this specific bug?

> The patch uses ‘cvs update’ command instead.  The implementation was
> already there, commented out.  I enabled and corrected it.  The result
> is more correct than the ‘cvs status’ approach, i.e. includes
> unregistered and missing, and is faster compared to ‘cvs status’ way.

If that change is mostly unrelated to the reported bug, could you send 
it as two separate patches?

Further, do you have any inkling why the 'cvs update' implementation was 
commented out? Did it require a particular recent version of CVS, maybe?

We can ask Dan if you don't.