[PATCH] vc-svn: vc-merge, avoid status checks

This patch fixes a couple of things about vc-svn that were bugging
me. It probably needs a bit more work before it should be merged but
I thought people might be interested.

Firstly, because of #1042 ("svn status -uv" fails on added files),
vc-svn was unable to commit the first revision of a file.

I have changed vc-svn-state to only run "svn status -v", rather than
-u. This is a bit "naughty" in terms of the vc backend interface,
because it really ought to check for updates. However, doing it this
way seems to work fine, and I can't at the moment think of anything it
will break. As a side effect this avoids the "st -uv" problem. By
avoiding network connections it is somewhat nicer for people with
remote repositories.

This means that an attempt to commit a file that is not up-to-date
will be trapped by svn, rather than emacs, but that does not seem like
a very bad thing to me. Having the commit work is probably the more
common case so perhaps it's better to assume success and cope with
failure.

I added basic C-x v m (vc-merge) support to allow pulling in updates
to a file.

Any comments?

-- 
Martin 
Index: vc-svn.el
===================================================================
--- vc-svn.el	(revision 5384)
+++ vc-svn.el	(working copy)
@@ -22,6 +22,18 @@
 ;;; COMMENT as a Subversion property?  Would that show up in fancy DAV
 ;;; web folder displays, or would it just languish in obscurity, the
 ;;; way CVS and RCS descriptions do?
+;;;
+;;; Implement other parts of the VC backend interface, such as
+;;; allowing merge of arbitrary revisions into the working copy.
+;;;
+;;; After manual merging, need some way to run `svn resolve'.  Perhaps
+;;; we should just prompt for approval when somebody tries to commit a
+;;; conflicted file?
+;;;
+;;; vc-svn ought to handle more gracefully an attempted commit that
+;;; fails with "Transaction is out of date".  Probably the best
+;;; approach is to ask "file is not up-to-date; do you want to merge
+;;; now?"  I think vc-cvs does this.
 
 
 ;;; To do in VC:
@@ -181,15 +193,26 @@
    (t 'edited)))
 
 
+;;; Is it really safe not to check for updates?  I haven't seen any
+;;; cases where failing to check causes a problem that is not caught
+;;; in some other way.  However, there *are* cases where checking
+;;; needlessly causes network delay, such as C-x v v.  The common case
+;;; is for the commit to be OK; we can handle errors if they occur. -- mbp
 (defun vc-svn-state (file)
   "Return the current version control state of FILE.
 For a list of possible return values, see `vc-state'.
+
 This function should do a full and reliable state computation; it is
 usually called immediately after `C-x v v'.  `vc-svn-state-heuristic'
-provides a faster heuristic when visiting a file."
-  (car (vc-svn-run-status file 'update)))
+provides a faster heuristic when visiting a file.
 
+For svn this does *not* check for updates in the repository, because
+that needlessly slows down vc when the repository is remote.  Instead,
+we rely on Subversion to trap situations such as needing a merge
+before commit."
+  (car (vc-svn-run-status file)))
 
+
 (defun vc-svn-state-heuristic (file)
   "Estimate the version control state of FILE at visiting time.
 For a list of possible values, see the doc string of `vc-state'.
@@ -255,6 +278,17 @@
   (vc-do-command nil 0 vc-svn-program-name file "revert"))
 
 
+(defun vc-svn-merge-news (file)
+  "Merge recent changes into FILE.
+
+This calls `svn update'.  In the case of conflicts, Subversion puts
+conflict markers into the file and leaves additional temporary files
+containing the `ancestor', `mine', and `other' files.
+
+You may need to run `svn resolve' by hand once these conflicts have
+been resolved."
+  (vc-do-command nil 0 vc-svn-program-name file "update"))
+
 (defun vc-svn-print-log (file)
   "Insert the revision log of FILE into the *vc* buffer."
   (vc-do-command nil 'async vc-svn-program-name file "log"))
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org