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

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

[Tim Van Holder]

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).

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

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

[Dan Nicolaescu]

"Tim Van Holder" <tim.vanholder@gmail.com> 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.

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

  > 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). 

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 <dann@ics.uci.edu> wrote:
> "Tim Van Holder" <tim.vanholder@gmail.com> 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).

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

[Dan Nicolaescu]

"Tim Van Holder" <tim.vanholder@gmail.com> writes:

  > On Fri, Apr 11, 2008 at 6:13 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > > "Tim Van Holder" <tim.vanholder@gmail.com> writes:
  > >   > 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).

Thanks, that sound like a good idea.  Now the update process is killed
when the VC status buffer is killed.