commit message is not displayed when using svn

[redguardtoo]

I think follow code has not svn implementation:

(defun git-messenger:git-commit-message (commit-id)
  (let ((args (git-messenger:cat-file-arguments commit-id)))
    (unless (zerop (git-messenger:execute-command 'git args t))
      (error "Failed: 'git cat-file'"))
    (goto-char (point-min))
    (forward-paragraph)
    (buffer-substring-no-properties (point) (point-max))))

I think you can use svn log -r changset for example:

$ svn log -r 27990
------------------------------------------------------------------------
r27990 | C55520 | 2015-03-02 19:05:18 +1100 (周一, 02 三月 2015) | 1 line

Modified for US1880, US2301, US2323, US2887 
------------------------------------------------------------------------

[syohex]

git-messenger:svn-commit-message is called in subversion repository(git-messenger:git-commit-message is not called in subversion repository)

Commit message is displayed as below.

[redguardtoo]

git-messenger:svn-commit-message implementation issue. I use other modes like evil-mode, so forward-paragraph might have different behaviour

here is my fix:

diff --git a/git-messenger.el b/git-messenger.el
index 6e81fcb..4805000 100644
--- a/git-messenger.el
+++ b/git-messenger.el
@@ -146,9 +146,8 @@ and menus.")
       (error "Failed: 'svn log"))
     (goto-char (point-min))
     (let (end)
-      (forward-paragraph)
-      (when (re-search-forward "^-\\{25\\}" nil t)
-        (forward-line -1)
+      (goto-char (point-max))
+      (if (re-search-backward "^-\\{25\\}" nil t)
         (setq end (point)))
       (buffer-substring-no-properties (point-min) (or end (point-max))))))

As you can see (forward-line -1) is removed because my svn v1.8.11 don't need this.

Here is the output of svn log -c 27091:

------------------------------------------------------------------------
r27091 | C55520 | 2015-02-11 19:22:30 +1100 (3, 11  2015) | 1 line

ID2113 done - chen
------------------------------------------------------------------------

[syohex]

I have applied your fix at #33.