Re: Another VC terminology change?

[Dan Nicolaescu]

Stefan Monnier <address@hidden> writes:

  > >> >> Not about "checkout" which sometimes means "update" and sometimes 
"get".
  > >> > Speaking of "update", vc-update needs to be rethought a bit.
  > >> > Mercurial, bzr and git (maybe other systems too) don't seem to want to
  > >> > do merges based on a file, but on changesets.
  > >> > What should we do about that?
  > >> 
  > >> Those backends should simply signal an error if requested to update
  > >> something less than the whole tree.
  > 
  > > So what would the UI be for that?
  > 
  > You mean API rather than UI, right?

I mean UI. How does the user request a merge on such a VCS?  Using
"C-x v +" from any VC managed file?  Should it then warn that the
whole tree is getting merged?

  > > vc-BACKEND-merge-news currently has a `file' parameter.
  > > Should backends check if it is a directory, and then run the merge
  > > command?
  > 
  > Those backends which can only perform such operations on whole trees, should
  > (obviously) check that the parameter refers to a whole tree and signal an
  > error if it doesn't.
  > 
  > > Who is responsible for updating all the buffers for files that have
  > > been changed by the merge?
  > 
  > VC.  The backend should return a list of files that were updated (maybe
  > together with their new status?), and then vc.el will be in charge of
  > reverting the corresponding buffers (and update the relevant vc-dired
  > buffers, ...).

What happens if there are conflicts in files that are not opened?
Should VC show pop a vc-dired window and show them?