bug#6513: vc-mtn broken with monotone 0.48 (can't even open files)

[Julio Merino <jmmv84@gmail.com>]

On Sat, Jun 26, 2010 at 11:27 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Wrong type argument: stringp, nil
>
> Try "Options => Enter Debugger on Error" and reproduce the bug, to get
> a backtrace.

Here comes one:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("\\`[^:/#]*[:/#]" nil)
  vc-mtn-mode-line-string("/home/jmmv/os/atf/2/atf-c++.hpp")
  apply(vc-mtn-mode-line-string "/home/jmmv/os/atf/2/atf-c++.hpp")
  vc-call-backend(Mtn mode-line-string "/home/jmmv/os/atf/2/atf-c++.hpp")
  vc-mode-line("/home/jmmv/os/atf/2/atf-c++.hpp" Mtn)
  vc-find-file-hook()
  run-hooks(find-file-hook)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer atf-c++.hpp> "~/os/atf/2/atf-c++.hpp"
nil nil "~/os/atf/2/atf-c++.hpp" (22103647 0))
  find-file-noselect("~/os/atf/2/atf-c++.hpp" nil nil t)
  find-file("~/os/atf/2/atf-c++.hpp" t)
  call-interactively(find-file nil nil)

>> The fix is to stop using random mtn commands in vc-mtn and change the
>> code to *only* use subcommands of 'mtn automate'.  'automate' is The
>> interface to interact with monotone from other applications, because
>> it exposes a stable interface with well-defined intput/output
>> semantics.
>
> Thank you, that is very useful to know.
> I wrote vc-mtn.el a long time ago but don't actually use Monotone much
> these days and don't have much time to devote to it, so if you could
> help us fix it, that would be really appreciated.

I'd like to help in fixing it, and I actually tried to do it myself...
but my elisp skills are quite rudimentary and I don't have that much
time to learn it right now :-P  That said, fixing the code shouldn't
be that hard; just a matter of renaming some commands and changing the
regular expressions used to deal with the results.

The major offending command that is causing breakage seems to be "mtn
status" and, in particular, regexes like:

    (re-search-forward "Branch: \\(.*\\)\n.*\nChanges against parent
\\(.*\\)" nil t)
    (while (re-search-forward
           "^  \\(?:\\(patched  \\)\\|\\(added    \\)\\)\\(.*\\)$" nil t)

I suggest changing the code to use "monotone automate
get_current_revision", which yields an output like:

-----
$ mtn automate get_current_revision
format_version "1"

new_manifest [6466cf3b1c785b949d02ef85daea66bd42a0d140]

old_revision [6aa25b8d86bd92a304ec21edd1374f56077ea658]

add_file "foo"
 content [da39a3ee5e6b4b0d3255bfef95601890afd80709]

patch "atf-check/atf-check.cpp"
 from [a200c3b32c0e7676797d20a188d4c20963b4d10e]
   to [ae4801edb72c0486c7652c030fc3f8196b21840e]

patch "test-programs/result_test.sh"
 from [398f9f2beba40eb66d93d1b424e4ea703d16f6f0]
   to [584a05bec8a359759b2f82d39862f43c9d4d794a]
-----

Note the version number at the top of the output, which can be used to
detect if the output is compatible with what the code expects.  Also
note the add_file, patch and old_revision lines, which should match
old previous regexp patterns.

I can probably invest some time tomorrow trying to find what is the
best way to implement every mtn command through the automate
interface.  But it'd be nice if we fixed first the show stoppers.

But, anyway, please take a look at:

     http://monotone.ca/docs/Automation.html#Automation

It describes all automate commands, their output and their
compatibility.  It seems to be pretty well documented :-)

-- 
Julio Merino