|
From: | Dmitry Gutov |
Subject: | bug#24082: [PATCH] Use ‘cvs update’ instead ‘cvs status’ for CVS *vc-dir* buffers |
Date: | Fri, 7 Oct 2016 02:25:24 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Thunderbird/49.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |