vc-update for bzr etc.

vc-update for bzr etc.

[Chong Yidong]

[I sent this yesterday, but the message didn't show up; resending.]

From vc.el:

;; - vc-update/vc-merge should deal with VC systems that don't
;;   update/merge on a file basis, but on a whole repository basis.
;;   vc-update and vc-merge assume the arguments are always files,
;;   they don't deal with directories.  Make sure the *vc-dir* buffer
;;   is updated after these operations.
;;   At least bzr, git and hg should benefit from this.

Here's a quick stab at this.  If a backend defines vc-BACK-merge-news
(svn and cvs), vc-update tries a per-file update unless a prefix
argument is supplied.  Otherwise, it tries vc-BACK-update-repository, a
new VC backend function.  Included is an implementation for bzr,
vc-bzr-update-repository, which runs asynchronously and outputs to a
*vc-update* buffer (currently Fundamental mode, but can be improved).

Thoughts?  Any subtleties here that I'm missing?


=== modified file 'lisp/vc/vc-bzr.el'
*** lisp/vc/vc-bzr.el	2010-11-09 20:07:10 +0000
--- lisp/vc/vc-bzr.el	2010-11-21 00:55:37 +0000
***************
*** 236,241 ****
--- 236,253 ----
      (when rootdir
           (file-relative-name filename* rootdir))))
  
+ (defun vc-bzr-update-repository ()
+   "Update the current Bzr repository."
+   (let ((buf (get-buffer-create "*vc-update*"))
+ 	(dir default-directory))
+     (display-buffer buf)
+     (with-current-buffer buf
+       (goto-char (point-max))
+       (unless (eq (point) (point-min))
+ 	(insert "\f\n"))
+       (insert "Running \"bzr update\" for \"" dir "\"...\n")
+       (vc-bzr-command "update" t 'async nil))))
+ 
  (defun vc-bzr-status (file)
    "Return FILE status according to Bzr.
  Return value is a cons (STATUS . WARNING), where WARNING is a

=== modified file 'lisp/vc/vc.el'
*** lisp/vc/vc.el	2010-11-12 13:44:46 +0000
--- lisp/vc/vc.el	2010-11-21 01:25:39 +0000
***************
*** 2274,2308 ****
  (define-obsolete-function-alias 'vc-revert-buffer 'vc-revert "23.1")
  
  ;;;###autoload
! (defun vc-update ()
!   "Update the current fileset's files to their tip revisions.
! For each one that contains no changes, and is not locked, then this simply
! replaces the work file with the latest revision on its branch.  If the file
! contains changes, and the backend supports merging news, then any recent
! changes from the current branch are merged into the working file."
!   (interactive)
!   (let* ((vc-fileset (vc-deduce-fileset))
  	 (backend (car vc-fileset))
  	 (files (cadr vc-fileset)))
!     (save-some-buffers          ; save buffers visiting files
!      nil (lambda ()
!            (and (buffer-modified-p)
!                 (let ((file (buffer-file-name)))
!                   (and file (member file files))))))
!     (dolist (file files)
!       (if (vc-up-to-date-p file)
! 	  (vc-checkout file nil t)
! 	(if (eq (vc-checkout-model backend (list file)) 'locking)
! 	    (if (eq (vc-state file) 'edited)
! 		(error "%s"
! 		       (substitute-command-keys
! 			"File is locked--type \\[vc-revert] to discard changes"))
! 	      (error "Unexpected file state (%s) -- type %s"
! 		     (vc-state file)
! 		     (substitute-command-keys
! 		      "\\[vc-next-action] to correct")))
!           (vc-maybe-resolve-conflicts
!            file (vc-call-backend backend 'merge-news file)))))))
  
  (defun vc-version-backup-file (file &optional rev)
    "Return name of backup file for revision REV of FILE.
--- 2274,2321 ----
  (define-obsolete-function-alias 'vc-revert-buffer 'vc-revert "23.1")
  
  ;;;###autoload
! (defun vc-update (&optional arg)
!   "Update the current fileset or repository.
! If the version control system supports only repository-wide
! updates, update the repository.
! 
! Otherwise, if prefix ARG is omitted or nil, update the files in
! the current fileset to their tip revisions.  For each file that
! contains no changes, and is not locked, then this simply replaces
! the work file with the latest revision on its branch.  If the
! file contains changes, and the backend supports merging news,
! then any recent changes from the current branch are merged into
! the working file.  If ARG is non-nil, update the entire
! repository instead."
!   (interactive "P")
!   (when buffer-file-name (vc-buffer-sync t))
!   (let* ((vc-fileset (vc-deduce-fileset t))
  	 (backend (car vc-fileset))
  	 (files (cadr vc-fileset)))
!     (cond
!      ;; If VCS has `merge-news' functionality (CVS and SVN), use it.
!      ((and (vc-find-backend-function backend 'merge-news)
! 	   (not arg))
!       (save-some-buffers ; save buffers visiting files
!        nil (lambda ()
! 	     (and (buffer-modified-p)
! 		  (let ((file (buffer-file-name)))
! 		    (and file (member file files))))))
!       (dolist (file files)
! 	(if (vc-up-to-date-p file)
! 	    (vc-checkout file nil t)
! 	  (vc-maybe-resolve-conflicts
! 	   file (vc-call-backend backend 'merge-news file)))))
!      ;; Otherwise, try updating the entire repository.
!      ((or arg (vc-find-backend-function backend 'update-repository))
!       (vc-call-backend backend 'update-repository))
!      ;; For a locking VCS, check out each file.
!      ((eq (vc-checkout-model backend files) 'locking)
!       (dolist (file files)
! 	(if (vc-up-to-date-p file)
! 	    (vc-checkout file nil t))))
!      (t
!       (error "VC update is unsupported for `%s'" backend)))))
  
  (defun vc-version-backup-file (file &optional rev)
    "Return name of backup file for revision REV of FILE.

Re: vc-update for bzr etc.

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

>   ;;;###autoload
> ! (defun vc-update (&optional arg)
> !   "Update the current fileset or repository.

What is "the repository", actually?  Is that the local repository or the
remote one?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: vc-update for bzr etc.

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

> [I sent this yesterday, but the message didn't show up; resending.]
>
> From vc.el:
>
> ;; - vc-update/vc-merge should deal with VC systems that don't
> ;;   update/merge on a file basis, but on a whole repository basis.
> ;;   vc-update and vc-merge assume the arguments are always files,
> ;;   they don't deal with directories.  Make sure the *vc-dir* buffer
> ;;   is updated after these operations.
> ;;   At least bzr, git and hg should benefit from this.
>
> Here's a quick stab at this.  If a backend defines vc-BACK-merge-news
> (svn and cvs), vc-update tries a per-file update unless a prefix
> argument is supplied.  Otherwise, it tries vc-BACK-update-repository, a
> new VC backend function.  Included is an implementation for bzr,
> vc-bzr-update-repository, which runs asynchronously and outputs to a
> *vc-update* buffer (currently Fundamental mode, but can be improved).
>
> Thoughts?  

IMHO there's a benefit from implementing vc-pull/push operations.
Then vc-update can use vc-pull after maybe asking a few questions.
The pull/push terminology is what people are currently used to, so
it's easier for end users.
[Incidentally merge-news used by VC probably means close to nothing to almost anyone].

> Any subtleties here that I'm missing?

Updating the all the files and buffers after this operation.

Re: vc-update for bzr etc.

[Chong Yidong]

Dan Nicolaescu <dann@gnu.org> writes:

> IMHO there's a benefit from implementing vc-pull/push operations.
> Then vc-update can use vc-pull after maybe asking a few questions.
> The pull/push terminology is what people are currently used to, so
> it's easier for end users.

It makes more sense to make vc-update do a pull operation for DVCS's,
and make vc-pull an alias for vc-update if necessary, instead of making
vc-pull a separate new VC operation and leaving vc-update an undefined
operation for those systems.

> [Incidentally merge-news used by VC probably means close to nothing to
> almost anyone].

Yeah, I was wondering about where the "merge-news" terminology came
from.  In CVS, it does "cvs up" on the marked files, so I assumed it
meant "an operation where you update individual files".  Since that
would be left undefined for DCVS's, that would allow vc-update a way to
distinguish between the two cases, no?

Re: vc-update for bzr etc.

[Stefan Monnier]

> Thoughts?  Any subtleties here that I'm missing?

Here are some thoughts:

> Here's a quick stab at this.  If a backend defines vc-BACK-merge-news
> (svn and cvs), vc-update tries a per-file update unless a prefix
> argument is supplied.  Otherwise, it tries vc-BACK-update-repository, a
> new VC backend function.  Included is an implementation for bzr,

Better to just use the new backend function if present and fallback (or
provide a default implementation that delegates) to the old
backend function.

> +   "Update the current Bzr repository."

I have no idea what "Update the current Bzr repository" means.

> +       (vc-bzr-command "update" t 'async nil))))

This will not do what it says in non-bound branches.


        Stefan

Re: vc-update for bzr etc.

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Better to just use the new backend function if present and fallback (or
> provide a default implementation that delegates) to the old
> backend function.

OK, sounds reasonable.

>> +   "Update the current Bzr repository."
>
> I have no idea what "Update the current Bzr repository" means.
>
>> +       (vc-bzr-command "update" t 'async nil))))
>
> This will not do what it says in non-bound branches.

So the full functionality for Bzr should be something like this:

 - If it's a bound branch, do bzr update.
 - Otherwise, if there is a default pull location, prompt for a location
   and do "bzr merge --pull".
 - Otherwise, just do "bzr merge --pull" to use the default location.

Does this sound right?

Re: vc-update for bzr etc.

[Stefan Monnier]

>> IMHO there's a benefit from implementing vc-pull/push operations.
>> Then vc-update can use vc-pull after maybe asking a few questions.
>> The pull/push terminology is what people are currently used to, so
>> it's easier for end users.
> It makes more sense to make vc-update do a pull operation for DVCS's,
> and make vc-pull an alias for vc-update if necessary, instead of making
> vc-pull a separate new VC operation and leaving vc-update an undefined
> operation for those systems.

Yes, vc-pull and vc-update should be basically the same command.
The terminology in new backend operations should be `pull', I think.

> So the full functionality for Bzr should be something like this:
>  - If it's a bound branch, do bzr update.
>  - Otherwise, if there is a default pull location, prompt for a location
>    and do "bzr merge --pull".
>  - Otherwise, just do "bzr merge --pull" to use the default location.
> Does this sound right?

If it's not bound, it should just use "bzr pull" without prompting
the user, IMO.


        Stefan

Re: vc-update for bzr etc.

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> So the full functionality for Bzr should be something like this:
>>  - If it's a bound branch, do bzr update.
>>  - Otherwise, if there is a default pull location, prompt for a location
>>    and do "bzr merge --pull".
>>  - Otherwise, just do "bzr merge --pull" to use the default location.
>> Does this sound right?
>
> If it's not bound, it should just use "bzr pull" without prompting
> the user, IMO.

The "bzr pull" operation only works if the branches have not diverged.
If the vc pull operation corresponds to "bzr pull", then what would it
do in git?  IIUC, git pulls perform merging automatically, so if vc-pull
does "bzr pull" in bzr and "git pull" in git, it would be doing two
different things.

That's why I thought the closest common denominator would be to use
bzr's "merge --pull".

Re: vc-update for bzr etc.

[Stefan Monnier]

>>> So the full functionality for Bzr should be something like this:
>>> - If it's a bound branch, do bzr update.
>>> - Otherwise, if there is a default pull location, prompt for a location
>>> and do "bzr merge --pull".
>>> - Otherwise, just do "bzr merge --pull" to use the default location.
>>> Does this sound right?
>> 
>> If it's not bound, it should just use "bzr pull" without prompting
>> the user, IMO.

> The "bzr pull" operation only works if the branches have not diverged.
> If the vc pull operation corresponds to "bzr pull", then what would it
> do in git?  IIUC, git pulls perform merging automatically, so if vc-pull
> does "bzr pull" in bzr and "git pull" in git, it would be doing two
> different things.

> That's why I thought the closest common denominator would be to use
> bzr's "merge --pull".

VC tries to present a uniform UI and that is good, but trying to impose
a uniform semantics to all commands is asking too much.  So I think it's
perfectly OK for vc-pull/update to do "bzr pull" for Bzr and
"git pull" for Git, even if they don't do exactly the same thing.


        Stefan

Re: vc-update for bzr etc.

[Stephen J. Turnbull]

Stefan Monnier writes:

 > VC tries to present a uniform UI and that is good, but trying to impose
 > a uniform semantics to all commands is asking too much.  So I think it's
 > perfectly OK for vc-pull/update to do "bzr pull" for Bzr and
 > "git pull" for Git, even if they don't do exactly the same thing.

bzr pull -- synchronize branch to parent exactly, never does a
            non-trivial merge, sometimes operates on a non-local
            branch and not on the workspace IIRC.
git pull -- merges branch into workspace, commits unless conflict,
            never affects a branch outside of the workspace.
hg pull  -- fetches branch, never updates workspace or affects a
            branch outside of the workspace.

I don't see the point of having a single command whose implementation
can vary so randomly.  That's not a uniform UI, that's a
nondeterministic one.

I agree that perfectly uniform semantics is not really possible, of
course.

Re: vc-update for bzr etc.

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> VC tries to present a uniform UI and that is good, but trying to impose
> a uniform semantics to all commands is asking too much.  So I think it's
> perfectly OK for vc-pull/update to do "bzr pull" for Bzr and
> "git pull" for Git, even if they don't do exactly the same thing.

Fair enough.  Here's an updated patch.  I renamed the new operation
vc-BACKEND-update-branch, and vc-update uses it preferentially if it
exists (falling back on the old merge-news operation if not).  For
vc-bzr-update-branch, it calls "bzr update" for bound branchs and
"bzr pull" for other branches.  Passing a prefix arg to vc-update causes
it to prompt for arguments to bzr.

WDYT?


*** lisp/vc/vc-bzr.el	2010-11-09 20:07:10 +0000
--- lisp/vc/vc-bzr.el	2010-11-22 04:29:26 +0000
***************
*** 236,241 ****
--- 236,280 ----
      (when rootdir
           (file-relative-name filename* rootdir))))
  
+ (defun vc-bzr-update-branch (prompt)
+   "Update the current Bzr branch.
+ If it is a bound branch, run \"bzr update\".
+ Otherwise, run \"bzr pull\"."
+   (let* ((rootdir (vc-bzr-root default-directory))
+ 	 (bound ;; Whether the branch is bound.
+ 	  (with-temp-buffer
+ 	    (insert-file-contents
+ 	     (expand-file-name ".bzr/branch/branch.conf" rootdir))
+ 	    (goto-char (point-min))
+ 	    (re-search-forward "bound *= *True" nil t)))
+ 	 (command (if bound "update" "pull"))
+ 	 (vc-bzr-program vc-bzr-program)
+ 	 (args nil)
+ 	 buf)
+     ;; If PROMPT is given, ask the user for the exact command.
+     (when prompt
+       (setq args
+ 	    (split-string
+ 	     (read-shell-command
+ 	      "Run bzr (like this): "
+ 	      (concat vc-bzr-program " " command))
+ 	     " " t))
+       (if (< (length args) 2)
+ 	  (error "Invalid bzr command")
+ 	(setq vc-bzr-program (car args)
+ 	      command (nth 1 args)
+ 	      args (cddr args))))
+     ;; Run asynchronously, ouputting to *vc-update* buffer.
+     (setq buf (get-buffer-create "*vc-update*"))
+     (with-current-buffer buf
+       (goto-char (point-max))
+       (unless (eq (point) (point-min))
+ 	(insert "\f\n"))
+       (insert (format "Running \"%s %s\" for \"%s\"...\n"
+ 		      vc-bzr-program command rootdir))
+       (vc-bzr-command command t 'async nil args))
+     (display-buffer buf)))
+ 
  (defun vc-bzr-status (file)
    "Return FILE status according to Bzr.
  Return value is a cons (STATUS . WARNING), where WARNING is a

=== modified file 'lisp/vc/vc.el'
*** lisp/vc/vc.el	2010-11-12 13:44:46 +0000
--- lisp/vc/vc.el	2010-11-22 03:56:27 +0000
***************
*** 2274,2308 ****
  (define-obsolete-function-alias 'vc-revert-buffer 'vc-revert "23.1")
  
  ;;;###autoload
! (defun vc-update ()
!   "Update the current fileset's files to their tip revisions.
! For each one that contains no changes, and is not locked, then this simply
! replaces the work file with the latest revision on its branch.  If the file
! contains changes, and the backend supports merging news, then any recent
! changes from the current branch are merged into the working file."
!   (interactive)
!   (let* ((vc-fileset (vc-deduce-fileset))
  	 (backend (car vc-fileset))
  	 (files (cadr vc-fileset)))
!     (save-some-buffers          ; save buffers visiting files
!      nil (lambda ()
!            (and (buffer-modified-p)
!                 (let ((file (buffer-file-name)))
!                   (and file (member file files))))))
!     (dolist (file files)
!       (if (vc-up-to-date-p file)
! 	  (vc-checkout file nil t)
! 	(if (eq (vc-checkout-model backend (list file)) 'locking)
! 	    (if (eq (vc-state file) 'edited)
! 		(error "%s"
! 		       (substitute-command-keys
! 			"File is locked--type \\[vc-revert] to discard changes"))
! 	      (error "Unexpected file state (%s) -- type %s"
! 		     (vc-state file)
! 		     (substitute-command-keys
! 		      "\\[vc-next-action] to correct")))
!           (vc-maybe-resolve-conflicts
!            file (vc-call-backend backend 'merge-news file)))))))
  
  (defun vc-version-backup-file (file &optional rev)
    "Return name of backup file for revision REV of FILE.
--- 2274,2320 ----
  (define-obsolete-function-alias 'vc-revert-buffer 'vc-revert "23.1")
  
  ;;;###autoload
! (defun vc-update (&optional arg)
!   "Update the current fileset or branch.
! On distributed version control systems, this updates the branch.
! With prefix ARG, prompt for an argument list for the command.
! 
! On all other version control systems, update the files in the
! current fileset to their tip revisions.  For each file that
! contains no changes, and is not locked, then this simply replaces
! the work file with the latest revision on its branch.  If the
! file contains changes, and the backend supports merging news,
! then any recent changes from the current branch are merged into
! the working file."
!   (interactive "P")
!   (when buffer-file-name (vc-buffer-sync t))
!   (let* ((vc-fileset (vc-deduce-fileset t))
  	 (backend (car vc-fileset))
  	 (files (cadr vc-fileset)))
!     (cond
!      ;; If an update-branch operation is defined, use it.
!      ((or arg (vc-find-backend-function backend 'update-branch))
!       (vc-call-backend backend 'update-branch arg))
!      ;; If VCS has `merge-news' functionality (CVS and SVN), use it.
!      ((and (vc-find-backend-function backend 'merge-news)
! 	   (not arg))
!       (save-some-buffers ; save buffers visiting files
!        nil (lambda ()
! 	     (and (buffer-modified-p)
! 		  (let ((file (buffer-file-name)))
! 		    (and file (member file files))))))
!       (dolist (file files)
! 	(if (vc-up-to-date-p file)
! 	    (vc-checkout file nil t)
! 	  (vc-maybe-resolve-conflicts
! 	   file (vc-call-backend backend 'merge-news file)))))
!      ;; For a locking VCS, check out each file.
!      ((eq (vc-checkout-model backend files) 'locking)
!       (dolist (file files)
! 	(if (vc-up-to-date-p file)
! 	    (vc-checkout file nil t))))
!      (t
!       (error "VC update is unsupported for `%s'" backend)))))
  
  (defun vc-version-backup-file (file &optional rev)
    "Return name of backup file for revision REV of FILE.

Re: vc-update for bzr etc.

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> VC tries to present a uniform UI and that is good, but trying to impose
>> a uniform semantics to all commands is asking too much.  So I think it's
>> perfectly OK for vc-pull/update to do "bzr pull" for Bzr and
>> "git pull" for Git, even if they don't do exactly the same thing.
>
> Fair enough.  Here's an updated patch.  I renamed the new operation
> vc-BACKEND-update-branch, and vc-update uses it preferentially if it
> exists (falling back on the old merge-news operation if not).  For
> vc-bzr-update-branch, it calls "bzr update" for bound branchs and
> "bzr pull" for other branches.  Passing a prefix arg to vc-update causes
> it to prompt for arguments to bzr.
>
> WDYT?

IMHO:
It looks like the future is pull/push.
If vc-pull is supported then vc-update can either use vc-pull directly
or just issue an error directing the users to use vc-pull. 
It does not look like a wise investment to go in the direction of
expanding support for vc-update.

>
>
> *** lisp/vc/vc-bzr.el	2010-11-09 20:07:10 +0000
> --- lisp/vc/vc-bzr.el	2010-11-22 04:29:26 +0000
> ***************
> *** 236,241 ****
> --- 236,280 ----
>       (when rootdir
>            (file-relative-name filename* rootdir))))
>   
> + (defun vc-bzr-update-branch (prompt)
> +   "Update the current Bzr branch.
> + If it is a bound branch, run \"bzr update\".
> + Otherwise, run \"bzr pull\"."
> +   (let* ((rootdir (vc-bzr-root default-directory))
> + 	 (bound ;; Whether the branch is bound.
> + 	  (with-temp-buffer
> + 	    (insert-file-contents
> + 	     (expand-file-name ".bzr/branch/branch.conf" rootdir))
> + 	    (goto-char (point-min))
> + 	    (re-search-forward "bound *= *True" nil t)))
> + 	 (command (if bound "update" "pull"))
> + 	 (vc-bzr-program vc-bzr-program)
> + 	 (args nil)
> + 	 buf)
> +     ;; If PROMPT is given, ask the user for the exact command.
> +     (when prompt
> +       (setq args
> + 	    (split-string
> + 	     (read-shell-command
> + 	      "Run bzr (like this): "
> + 	      (concat vc-bzr-program " " command))
> + 	     " " t))
> +       (if (< (length args) 2)
> + 	  (error "Invalid bzr command")
> + 	(setq vc-bzr-program (car args)
> + 	      command (nth 1 args)
> + 	      args (cddr args))))
> +     ;; Run asynchronously, ouputting to *vc-update* buffer.
> +     (setq buf (get-buffer-create "*vc-update*"))
> +     (with-current-buffer buf
> +       (goto-char (point-max))
> +       (unless (eq (point) (point-min))
> + 	(insert "\f\n"))
> +       (insert (format "Running \"%s %s\" for \"%s\"...\n"
> + 		      vc-bzr-program command rootdir))
> +       (vc-bzr-command command t 'async nil args))
> +     (display-buffer buf)))
> + 
>   (defun vc-bzr-status (file)
>     "Return FILE status according to Bzr.
>   Return value is a cons (STATUS . WARNING), where WARNING is a
>
> === modified file 'lisp/vc/vc.el'
> *** lisp/vc/vc.el	2010-11-12 13:44:46 +0000
> --- lisp/vc/vc.el	2010-11-22 03:56:27 +0000
> ***************
> *** 2274,2308 ****
>   (define-obsolete-function-alias 'vc-revert-buffer 'vc-revert "23.1")
>   
>   ;;;###autoload
> ! (defun vc-update ()
> !   "Update the current fileset's files to their tip revisions.
> ! For each one that contains no changes, and is not locked, then this simply
> ! replaces the work file with the latest revision on its branch.  If the file
> ! contains changes, and the backend supports merging news, then any recent
> ! changes from the current branch are merged into the working file."
> !   (interactive)
> !   (let* ((vc-fileset (vc-deduce-fileset))
>   	 (backend (car vc-fileset))
>   	 (files (cadr vc-fileset)))
> !     (save-some-buffers          ; save buffers visiting files
> !      nil (lambda ()
> !            (and (buffer-modified-p)
> !                 (let ((file (buffer-file-name)))
> !                   (and file (member file files))))))
> !     (dolist (file files)
> !       (if (vc-up-to-date-p file)
> ! 	  (vc-checkout file nil t)
> ! 	(if (eq (vc-checkout-model backend (list file)) 'locking)
> ! 	    (if (eq (vc-state file) 'edited)
> ! 		(error "%s"
> ! 		       (substitute-command-keys
> ! 			"File is locked--type \\[vc-revert] to discard changes"))
> ! 	      (error "Unexpected file state (%s) -- type %s"
> ! 		     (vc-state file)
> ! 		     (substitute-command-keys
> ! 		      "\\[vc-next-action] to correct")))
> !           (vc-maybe-resolve-conflicts
> !            file (vc-call-backend backend 'merge-news file)))))))
>   
>   (defun vc-version-backup-file (file &optional rev)
>     "Return name of backup file for revision REV of FILE.
> --- 2274,2320 ----
>   (define-obsolete-function-alias 'vc-revert-buffer 'vc-revert "23.1")
>   
>   ;;;###autoload
> ! (defun vc-update (&optional arg)
> !   "Update the current fileset or branch.
> ! On distributed version control systems, this updates the branch.
> ! With prefix ARG, prompt for an argument list for the command.
> ! 
> ! On all other version control systems, update the files in the
> ! current fileset to their tip revisions.  For each file that
> ! contains no changes, and is not locked, then this simply replaces
> ! the work file with the latest revision on its branch.  If the
> ! file contains changes, and the backend supports merging news,
> ! then any recent changes from the current branch are merged into
> ! the working file."
> !   (interactive "P")
> !   (when buffer-file-name (vc-buffer-sync t))
> !   (let* ((vc-fileset (vc-deduce-fileset t))
>   	 (backend (car vc-fileset))
>   	 (files (cadr vc-fileset)))
> !     (cond
> !      ;; If an update-branch operation is defined, use it.
> !      ((or arg (vc-find-backend-function backend 'update-branch))
> !       (vc-call-backend backend 'update-branch arg))
> !      ;; If VCS has `merge-news' functionality (CVS and SVN), use it.
> !      ((and (vc-find-backend-function backend 'merge-news)
> ! 	   (not arg))
> !       (save-some-buffers ; save buffers visiting files
> !        nil (lambda ()
> ! 	     (and (buffer-modified-p)
> ! 		  (let ((file (buffer-file-name)))
> ! 		    (and file (member file files))))))
> !       (dolist (file files)
> ! 	(if (vc-up-to-date-p file)
> ! 	    (vc-checkout file nil t)
> ! 	  (vc-maybe-resolve-conflicts
> ! 	   file (vc-call-backend backend 'merge-news file)))))
> !      ;; For a locking VCS, check out each file.
> !      ((eq (vc-checkout-model backend files) 'locking)
> !       (dolist (file files)
> ! 	(if (vc-up-to-date-p file)
> ! 	    (vc-checkout file nil t))))
> !      (t
> !       (error "VC update is unsupported for `%s'" backend)))))
>   
>   (defun vc-version-backup-file (file &optional rev)
>     "Return name of backup file for revision REV of FILE.

Re: vc-update for bzr etc.

[Thien-Thi Nguyen]

() "Stephen J. Turnbull" <stephen@xemacs.org>
() Mon, 22 Nov 2010 13:31:23 +0900

   bzr pull -- synchronize branch to parent exactly, never does a
               non-trivial merge, sometimes operates on a non-local
               branch and not on the workspace IIRC.
   git pull -- merges branch into workspace, commits unless conflict,
               never affects a branch outside of the workspace.
   hg pull  -- fetches branch, never updates workspace or affects a
               branch outside of the workspace.

   I don't see the point of having a single command whose implementation
   can vary so randomly.  That's not a uniform UI, that's a
   nondeterministic one.

   I agree that perfectly uniform semantics is not really possible, of
   course.

Looks like the sub-operations are:

 (0) determine "news"
 (1) download "news" (to some temporary space)
 (2) merge (conditionally, looping for conflict resolution, etc)
 (3) commit

Can these DVCSes do such sub-operations *individually* somehow?
Step (3) is given, but the others?

Re: vc-update for bzr etc.

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 21 Nov 2010 23:35:35 -0500
> Cc: Dan Nicolaescu <dann@gnu.org>, emacs-devel@gnu.org
> 
> Fair enough.  Here's an updated patch.  I renamed the new operation
> vc-BACKEND-update-branch, and vc-update uses it preferentially if it
> exists (falling back on the old merge-news operation if not).  For
> vc-bzr-update-branch, it calls "bzr update" for bound branchs and
> "bzr pull" for other branches.  Passing a prefix arg to vc-update causes
> it to prompt for arguments to bzr.

How do I do a "bzr merge --pull"?  This is a very frequent operation
in my workflows, when I work with local branches.

Re: vc-update for bzr etc.

[Stephen J. Turnbull]

Thien-Thi Nguyen writes:
 > () "Stephen J. Turnbull" <stephen@xemacs.org>
 > () Mon, 22 Nov 2010 13:31:23 +0900
 > 
 >    bzr pull -- synchronize branch to parent exactly, never does a
 >                non-trivial merge, sometimes operates on a non-local
 >                branch and not on the workspace IIRC.
 >    git pull -- merges branch into workspace, commits unless conflict,
 >                never affects a branch outside of the workspace.
 >    hg pull  -- fetches branch, never updates workspace or affects a
 >                branch outside of the workspace.
 > 
 >    I don't see the point of having a single command whose implementation
 >    can vary so randomly.  That's not a uniform UI, that's a
 >    nondeterministic one.
 > 
 >    I agree that perfectly uniform semantics is not really possible, of
 >    course.
 > 
 > Looks like the sub-operations are:
 > 
 >  (0) determine "news"
 >  (1) download "news" (to some temporary space)
 >  (2) merge (conditionally, looping for conflict resolution, etc)
 >  (3) commit
 > 
 > Can these DVCSes do such sub-operations *individually* somehow?
 > Step (3) is given, but the others?

I believe so, although the solutions in the case of bzr might be
exceptionally gross and possibly inefficient (eg, to do (1) I think
you would have to either create a new branch, or get the revid of the
tip and then uncommit, which doesn't destroy any commits, it just
rewinds the tip in the same way that git reset does).  git's solution
to (0) is a bit ugly too ("fetch --dry-run"), while bzr provides
"missing" and hg "incoming".

Re: vc-update for bzr etc.

[Stefan Monnier]

>> VC tries to present a uniform UI and that is good, but trying to impose
>> a uniform semantics to all commands is asking too much.  So I think it's
>> perfectly OK for vc-pull/update to do "bzr pull" for Bzr and
>> "git pull" for Git, even if they don't do exactly the same thing.

> bzr pull -- synchronize branch to parent exactly, never does a
>             non-trivial merge, sometimes operates on a non-local
>             branch and not on the workspace IIRC.
> git pull -- merges branch into workspace, commits unless conflict,
>             never affects a branch outside of the workspace.
> hg pull  -- fetches branch, never updates workspace or affects a
>             branch outside of the workspace.

> I don't see the point of having a single command whose implementation
> can vary so randomly.

That's OK: "cvs pull" is even further from the above, so my suggestion
is not to "just pass `pull' to the backend command" but "run the normal
command to update the current tree by bringing in changes from
upstream".  Based on what you say, vc-pull for Mercurial would not just
do "hg pull" but something more.


        Stefan

Re: vc-update for bzr etc.

[Stefan Monnier]

>> Fair enough.  Here's an updated patch.  I renamed the new operation
>> vc-BACKEND-update-branch, and vc-update uses it preferentially if it
>> exists (falling back on the old merge-news operation if not).  For
>> vc-bzr-update-branch, it calls "bzr update" for bound branchs and
>> "bzr pull" for other branches.  Passing a prefix arg to vc-update causes
>> it to prompt for arguments to bzr.

> How do I do a "bzr merge --pull"?  This is a very frequent operation
> in my workflows, when I work with local branches.

You use vc-merge (and to get the --pull, you'll probably have to add it
to your bazaar.conf).


        Stefan

Re: vc-update for bzr etc.

[Stefan Monnier]

>>> VC tries to present a uniform UI and that is good, but trying to impose
>>> a uniform semantics to all commands is asking too much.  So I think it's
>>> perfectly OK for vc-pull/update to do "bzr pull" for Bzr and
>>> "git pull" for Git, even if they don't do exactly the same thing.
>> 
>> Fair enough.  Here's an updated patch.  I renamed the new operation
>> vc-BACKEND-update-branch, and vc-update uses it preferentially if it
>> exists (falling back on the old merge-news operation if not).  For
>> vc-bzr-update-branch, it calls "bzr update" for bound branchs and
>> "bzr pull" for other branches.  Passing a prefix arg to vc-update causes
>> it to prompt for arguments to bzr.
>> 
>> WDYT?

> IMHO:
> It looks like the future is pull/push.
> If vc-pull is supported then vc-update can either use vc-pull directly
> or just issue an error directing the users to use vc-pull. 
> It does not look like a wise investment to go in the direction of
> expanding support for vc-update.

I don't see any reason why vc-pull couldn't be an alias of vc-update.


        Stefan

Re: vc-update for bzr etc.

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> How do I do a "bzr merge --pull"?  This is a very frequent operation
> in my workflows, when I work with local branches.

We are going to need to provide a separate merge operation, I think.

Although, even without that, this patch would allow you to do
`C-u C-x v +', which will prompt for the actual bzr command, and you
could change it to "bzr merge --pull".

Re: vc-update for bzr etc.

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> hg pull  -- fetches branch, never updates workspace or affects a
>>             branch outside of the workspace.
>
> That's OK: "cvs pull" is even further from the above, so my suggestion
> is not to "just pass `pull' to the backend command" but "run the normal
> command to update the current tree by bringing in changes from
> upstream".

The trouble is that for Bzr, the "normal command to update the current
tree" would be "bzr merge" (or "bzr merge --pull") if you're working in
a task branch.

I remain confused about what the intended use of "bzr pull" is.  As far
as I can tell, it's only used if someone wants a mirror of another
branch that is never modified.  But that seems like the less important
case.

> Based on what you say, vc-pull for Mercurial would not just do "hg
> pull" but something more.

Apparently, that would be "hg update tip".

Re: vc-update for bzr etc.

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: monnier@iro.umontreal.ca, dann@gnu.org, emacs-devel@gnu.org
> Date: Mon, 22 Nov 2010 11:57:42 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How do I do a "bzr merge --pull"?  This is a very frequent operation
> > in my workflows, when I work with local branches.
> 
> We are going to need to provide a separate merge operation, I think.
> 
> Although, even without that, this patch would allow you to do
> `C-u C-x v +', which will prompt for the actual bzr command, and you
> could change it to "bzr merge --pull".

I actually wonder why shouldn't vc-merge invoke "bzr merge --pull" by
default.  What would be the disadvantage of that?  If a pull is not
possible, this command will merge anyway.

Re: vc-update for bzr etc.

[Chong Yidong]

I've checked in the support for using vc-merge and vc-update with
DVCSes.  To summarize, this relies on two new state-changing VC
functions, vc-BACKEND-merge-branch (vc-BACKEND-merge was already taken,
for per-file merges) and vc-BACKEND-pull.

If the new functions are available, vc-merge/vc-update uses them; a
prefix argument prompts the user for the exact command to run, to allow
specifying flags or non-default source locations.  If the new functions
are unavailable, the old behavior (per file merges and updates) is
attempted.

vc-pull is an alias for vc-update.  (Should we make it the reverse?)

vc-bzr-pull and vc-bzr-merge-branch run asynchronously, outputting to a
display buffer.  Linking the filenames is desired but not implemented.
Maybe we should use compilation-mode for this, so that next-error can be
used to visit file conflicts?

Help refining this would be welcome.  And with the corresponding
features for other DVCS's.

Also, do I need to do anything special to update VC-dir buffers after
merging or pulling?

Re: vc-update for bzr etc.

[Stefan Monnier]

> vc-bzr-pull and vc-bzr-merge-branch run asynchronously, outputting to a
> display buffer.  Linking the filenames is desired but not implemented.
> Maybe we should use compilation-mode for this, so that next-error can be
> used to visit file conflicts?

No: the "display buffer" should be a *vc-dir* buffer.


        Stefan

Re: vc-update for bzr etc.

[Stephen J. Turnbull]

Chong Yidong writes:

 > I remain confused about what the intended use of "bzr pull" is.  As far
 > as I can tell, it's only used if someone wants a mirror of another
 > branch that is never modified.  But that seems like the less important
 > case.

Yes and yes.  Even the bzr developers admit that it's mainly there to
have symmetry with "push".

 > > Based on what you say, vc-pull for Mercurial would not just do "hg
 > > pull" but something more.
 > 
 > Apparently, that would be "hg update tip".

hg pull -u = hg pull + hg update tip.

Re: vc-update for bzr etc.

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> vc-bzr-pull and vc-bzr-merge-branch run asynchronously, outputting to a
>> display buffer.  Linking the filenames is desired but not implemented.
>> Maybe we should use compilation-mode for this, so that next-error can be
>> used to visit file conflicts?
>
> No: the "display buffer" should be a *vc-dir* buffer.

Good idea.  This might require a bit of infrastructure change, though,
to get vc-dir to list the updated files and mark them as "updated".

Re: vc-update for bzr etc.

[Stefan Monnier]

>> I remain confused about what the intended use of "bzr pull" is.  As far
>> as I can tell, it's only used if someone wants a mirror of another
>> branch that is never modified.  But that seems like the less important
>> case.

> Yes and yes.  Even the bzr developers admit that it's mainly there to
> have symmetry with "push".

I didn't realize it.  So maybe "bzr merge --pull" is a better choice,
although it will choose a different branch.


        Stefan

Re: vc-update for bzr etc.

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

> vc-pull is an alias for vc-update.  (Should we make it the reverse?)

Yes, please.  `pull' seems to be the term used nowadays.

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

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

Re: vc-update for bzr etc.

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>>> vc-bzr-pull and vc-bzr-merge-branch run asynchronously, outputting to a
>>> display buffer.  Linking the filenames is desired but not implemented.
>>> Maybe we should use compilation-mode for this, so that next-error can be
>>> used to visit file conflicts?
>>
>> No: the "display buffer" should be a *vc-dir* buffer.
>
> Good idea.  This might require a bit of infrastructure change, though,
> to get vc-dir to list the updated files and mark them as "updated".

vc-dir does that all the time after a checkin.  Just call
`vc-dir-update' with the list of file / state pairs.

Re: vc-update for bzr etc.

[Chong Yidong]

Dan Nicolaescu <dann@gnu.org> 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.

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

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?

Re: vc-update for bzr etc.

[Stefan Monnier]

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

Most of the relevant code should be in vc-update rather
than in vc-bzr-update.

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

Agreed.  See how PCL-CVS does it: at the top of the *cvs* buffer, there's
a line stating the command currently running (or several lines, one per
command, when several commands are running at the same time), as well as
an extra line stating the most recently finished command.


        Stefan

Re: vc-update for bzr etc.

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

> Dan Nicolaescu <dann@gnu.org> 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.

Re: vc-update for bzr etc.

[Chong Yidong]

Dan Nicolaescu <dann@gnu.org> writes:

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

Stuff in the modeline is awfully easy to overlook.  It doesn't really
address the feeling of "flimsiness" from doing an update/pull and seeing
no obvious response.  How bout putting it in a header line?

If you could explain in more detail why you think putting a status
message in the buffer is a bad idea, that would make it easier to figure
out what the right thing is.