Re: 23.0.60; new vc-status interface: no more multi-file commits?

[Tim Van Holder]

On Fri, Apr 11, 2008 at 6:13 PM, Dan Nicolaescu <address@hidden> wrote:
> "Tim Van Holder" <address@hidden> writes:
>
>   > With todays CVS build, it looks like there is a new interface for C-x
>   > v d; in itself that is quite nice (especially since it also lists
>   > removed files, which the previous system never did, at least not for a
>   > CVS backend).
>   > However, it looks like one main functionality is omitted from this,
>   > namely the ability to commit files directly (i.e. the old v-v action
>   > in VC-under-dired; not that big a deal for a CVS backend, but with
>   > changeset-based systems like svn/git that would seem to be a serious
>   > lack, not to mention that it directly contradicts the information in
>   > NEWS).
>
>  C-x v v should work just fine.  If you mark multiple files it commits
>  all of them, if none are marked it commits the file on the current
>  line.  vc-dired did the same thing.
>  It does not have a shorter binding yet, or a menu entry.

Leave it to me not to try the full command. I'm too used to the v-v
shorthand from vc-dired.
Since neither v or v-v did it, and there was no menu entry, I
(incorrectly) assumed the feature simply was not there.

>   > As an aside, is there a way to cleanly abort a long-running background
>   > status update? I briefly checked the behaviour of vc-status on a tree
>   > with svn backend; it also seemed to lack the ability to commit changed
>   > files.
>
>  Can you please explain exactly what the problem was?

This was just to mention that the (apparent) lack of a Commit action
was not limited to the CVS backend.

>   > On top of that, the retrieving of the status info uses a
>   > background process; in the case of the tree I was using (a gcc
>   > checkout), that process is quite slow, and there did not seem to be an
>   > obvious way to cancel it. C-g did nothing (since it's a background
>   > process), and when it finished after I had killed the vc-status buffer
>   > I received a 'selecting deleted buffer' error.
>
>  C-c C-c kills the update process (second to last menu entry).

I didn't notice that.
Would be nice if the background task could check that its buffer was
still alive when updating it, so that it would silently abort if the
(overly impatient) user killed it (or, alternatively, kill the process
if the buffer is killed).