Re: vc-update for bzr etc.

[Dan Nicolaescu]

Chong Yidong <address@hidden> writes:

> Dan Nicolaescu <address@hidden> writes:
>
>> I have an implementation of `pull' that also takes a `revision' argument.
>> And in the *vc-incoming* buffer there's a binding for vc-pull to pull
>> up to the revision at point (use  pull --revision=ARG).
>
> Good.

BTW, I have no plans to merge that.

>
>>> Also, do I need to do anything special to update VC-dir buffers after
>>> merging or pulling?
>>
>> Not only VC-dir buffers, but all buffers containing files in the
>> target directory.  See for example the vc-resynch-buffer in the
>> vc-retrieve-tag (which could use a better name).
>
> OK, I've got some code working that makes vc-bzr-merge/update call or
> refresh VC-dir after finishing, e.g. it shows "updated" files after a
> bzr update.  But the interface feels flimsy, somehow.

It seems that you are putting too much code in the vc-bzr, not in vc
itself.  Better pass the buffer to the command, instead of creating it
locally in each VC backend.

>
> The VC-dir buffer displays no indication while the merge/pull is
> running.  Afterwards, there is no sign that the operation has completed,
> other than an echo area message (easily overwritten by other Emacs
> commands) and some changes in file status (easily overlooked).
>
> For example, if you do an update operation that completes without doing
> anything, it's easy to miss when the update finishes.  In contrast, when
> the VCS messages are put into a compilation-like buffer, it's always
> clear what has taken place.
>
> So it seems like there needs to be some kind of status message display
> in the VC-dir buffer, showing (at least) the most recent VCS operation
> and its status.  WDYT?

In the buffer?  The way pcl-cvs does it is a bad idea, I am completely against 
it.
Putting something in the modeline, like the rest of the vc
asynchronous commands do would be better.