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

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

[Julio Merino]

The vc-mtn emacs module in emacs 23.2.1 does not work with monotone
0.48.  This prevents editing *any* file tracked by monotone.  Whenever
I attempt to open a file that is tracked by monotone, emacs spits out
the following in the minibuffer and fails to open the file:

Wrong type argument: stringp, nil

The problem is most likely related to some user interface changes that
happened in monotone 0.48: some commands such as 'mtn status' have
changed their output and thus the regular expressions bundled in
vc-mtn do not yield the correct matches.

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.

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

[Dan Nicolaescu]

Julio Merino <jmmv84@gmail.com> writes:

> The vc-mtn emacs module in emacs 23.2.1 does not work with monotone
> 0.48.  This prevents editing *any* file tracked by monotone.  Whenever
> I attempt to open a file that is tracked by monotone, emacs spits out
> the following in the minibuffer and fails to open the file:
>
> Wrong type argument: stringp, nil
>
> The problem is most likely related to some user interface changes that
> happened in monotone 0.48: some commands such as 'mtn status' have
> changed their output and thus the regular expressions bundled in
> vc-mtn do not yield the correct matches.

Yep, the regexp used by vc-mtn-workfile-branch no longer matches the
mtn status output.

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

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

[Stefan Monnier]

> Wrong type argument: stringp, nil

Try "Options => Enter Debugger on Error" and reproduce the bug, to get
a backtrace.

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


        Stefan

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

[Julio Merino]

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

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

[Julio Merino]

On Sun, Jun 27, 2010 at 12:45 AM, Julio Merino <jmmv84@gmail.com> wrote:
> 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:
[...]

ping!

Any update on this?  Is it there any easy workaround to, for example,
tell emacs not to load vc-mtn at all?

Thanks.

-- 
Julio Merino

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

[era eriksson]

According to downstream Debian bug #590262 it only fails the first time
you try to visit the file; trying again supposedly succeeds.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590262

Hope this helps,

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

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

[Julio Merino]

On Sep 2, 2010, at 8:19 AM, era eriksson wrote:

> According to downstream Debian bug #590262 it only fails the first  
> time
> you try to visit the file; trying again supposedly succeeds.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590262
>
> Hope this helps,

I have found the following to be a better workaround:

-----
; Trick vc-mtn into not finding monotone.  It's currently completely  
broken
; with monotone 0.48.
(setq vc-mtn-program "non-existent")
-----

Still, I'd love to see this fixed.

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

[Dan Nicolaescu]

Julio Merino <jmmv84@gmail.com> writes:

> On Sep 2, 2010, at 8:19 AM, era eriksson wrote:
>
>> According to downstream Debian bug #590262 it only fails the first
>> time
>> you try to visit the file; trying again supposedly succeeds.
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590262
>>
>> Hope this helps,
>
> I have found the following to be a better workaround:

A better workaround is to disable the monotone backend:

(setq vc-handled-backends (delq 'Mtn vc-handled-backends))


> ; Trick vc-mtn into not finding monotone.  It's currently completely
> broken
> ; with monotone 0.48.
> (setq vc-mtn-program "non-existent")
> -----
>
> Still, I'd love to see this fixed.

Do you want to take a stab at it?
Just need to modify the parser for the mtn command...

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

[Julio Merino]

On Sep 3, 2010, at 4:57 PM, Dan Nicolaescu wrote:
>> I have found the following to be a better workaround:
>
> A better workaround is to disable the monotone backend:
>
> (setq vc-handled-backends (delq 'Mtn vc-handled-backends))

Cool, that's what I've been waiting for.

>> ; Trick vc-mtn into not finding monotone.  It's currently completely
>> broken
>> ; with monotone 0.48.
>> (setq vc-mtn-program "non-existent")
>> -----
>>
>> Still, I'd love to see this fixed.
>
> Do you want to take a stab at it?
> Just need to modify the parser for the mtn command...

Sure, and I actually even tried.  But it's not as easy as changing  
some regexps... my elisp knowledge tends to zero.  The thing is that  
the automate interface is good for automatic interaction, but its  
output is completely different to what the interactive interface  
provides.  Hence, some of the assumptions currently in the code make  
it a bit harder to adjust...

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

[Chong Yidong]

Julio Merino <jmmv84@gmail.com> writes:

>> Do you want to take a stab at it?
>> Just need to modify the parser for the mtn command...
>
> Sure, and I actually even tried.  But it's not as easy as changing
> some regexps... my elisp knowledge tends to zero.  The thing is that
> the automate interface is good for automatic interaction, but its
> output is completely different to what the interactive interface
> provides.  Hence, some of the assumptions currently in the code make
> it a bit harder to adjust...

If you provide several precise examples of the monotone output, someone
else could try.

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

[Julio Merino]

On Sep 4, 2010, at 8:00 PM, Chong Yidong wrote:

> Julio Merino <jmmv84@gmail.com> writes:
> 
>>> Do you want to take a stab at it?
>>> Just need to modify the parser for the mtn command...
>> 
>> Sure, and I actually even tried.  But it's not as easy as changing
>> some regexps... my elisp knowledge tends to zero.  The thing is that
>> the automate interface is good for automatic interaction, but its
>> output is completely different to what the interactive interface
>> provides.  Hence, some of the assumptions currently in the code make
>> it a bit harder to adjust...
> 
> If you provide several precise examples of the monotone output, someone
> else could try.

OK, here they go.  I'm listing all the different calls to mtn that I found in vc-mtn, what they are being used for, and what they should be instead.

As I mentioned above, the code should be using "mtn automate" instead of the commands directly, because the output of the automate subcommands is designed to be parseable and to remain stable.

Hope this helps.

===> mtn status

This is currently used to determine:

1) The state of a file.
2) The state of a directory.
3) The current branch name.
4) The identifier of the parent revision.

Its output in 0.48 is something like:

---- begin ----
$ mtn status
----------------------------------------------------------------------
Revision: 74b28934c805d0f851ddf65b506b2b294b28bd1f
Parent:   fae253a2ecad09ee873d95fae7c53148708d5496
Author:   jmmv@NetBSD.org
Date:     09/05/10 12:41:28
Branch:   testing

Changes against parent fae253a2ecad09ee873d95fae7c53148708d5496

  dropped  dir2
  dropped  dir2/bar
  dropped  file2
  renamed  dir1
       to  dir3
  renamed  file1
       to  file3
  added    dir4
  added    dir4/baz
  added    file4
  patched  file0

---- end ----

1, 2 and 4 should be obtained using "mtn automate get_current_revision":

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

new_manifest [ebc50c8bd814864861acc5a3cbf8596e2f6424ca]

old_revision [fae253a2ecad09ee873d95fae7c53148708d5496]

delete "dir2"

delete "dir2/bar"

delete "file2"

rename "dir1"
    to "dir3"

rename "file1"
    to "file3"

add_dir "dir4"

add_file "dir4/baz"
 content [da39a3ee5e6b4b0d3255bfef95601890afd80709]

add_file "file4"
 content [da39a3ee5e6b4b0d3255bfef95601890afd80709]

patch "file0"
 from [da39a3ee5e6b4b0d3255bfef95601890afd80709]
   to [c2dfb20012cea6a8088917c6edea86db619000c8]
---- end ----

To get 3, aka the current branch name, one has to obtain the old_revision value from the output above and run "mtn automate certs" on it, to later get the value of the "branch" certificate:

---- begin ----
mtn automate certs fae253a2ecad09ee873d95fae7c53148708d5496
      key [6ea96157b01677a59e263d6b82337b781ce57370]
signature "ok"
     name "author"
    value "jmmv@NetBSD.org"
    trust "trusted"

      key [6ea96157b01677a59e263d6b82337b781ce57370]
signature "ok"
     name "branch"
    value "testing"
    trust "trusted"

      key [6ea96157b01677a59e263d6b82337b781ce57370]
signature "ok"
     name "changelog"
    value "Another.
"
    trust "trusted"

      key [6ea96157b01677a59e263d6b82337b781ce57370]
signature "ok"
     name "date"
    value "2010-09-05T09:08:42"
    trust "trusted"
---- end ----

===> mtn cat -r

Use "mtn -r <revision id> automate get_file_of <filename>" instead.

===> mtn list tags

Use "mtn automate tags":

---- begin ----
$ mtn automate tags
     tag "atf-0.1"
revision [b5177db1b525d850f0df932506cf6a0910eb1696]
  signer [6ea96157b01677a59e263d6b82337b781ce57370]
branches "org.NetBSD.atf.src"

     tag "atf-0.10"
revision [bab5e0f99e767de2e6650bf3c1aa7a7aad23a915]
  signer [6ea96157b01677a59e263d6b82337b781ce57370]
branches "org.NetBSD.atf.src"

     tag "atf-0.2"
revision [d448334ad6893ecd494228e8d5555272adcc5643]
  signer [6ea96157b01677a59e263d6b82337b781ce57370]
branches "org.NetBSD.atf.src"
[... more similar entries ...]
---- end ----

===> mtn list branches

Use "mtn automate branches":

---- begin ----
$ mtn automate branches
org.NetBSD.atf.htdocs
org.NetBSD.atf.src
org.NetBSD.atf.src.doc
org.NetBSD.atf.src.reorg
---- end ----

===> mtn add
===> mtn commit -m
===> mtn revert
===> mtn log
===> mtn diff
===> mtn annotate
===> mtn complete revision

Can't find how to do these with the automate interface, so they should remain as they are.

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

[Douglas Dickinson]

For the benefit of users with less emacs-fu who are broken on this bug...
Here's the simplest work around:

Download the latest version of vc-mtn.el from:
http://repo.or.cz/w/emacs.git/blob_plain?f=lisp/vc/vc-mtn.el

Find your emacs installation's copy of vc-mtn.el (or vc-mtn.elc),
move it somewhere else.

Copy the new version of vc-mtn.el into that directory.
NOTE: Even if the original was named *.elc your new file should be named *.el

(not being byte-compiled (.elc) will make it slower the first time
that you load a mtn version-controlled file, but for simplicity let's
not burden everyone with compiling files that are likely owned by
root)

bug#6513: bug#7171: vc-mtn to use "mtn automate"

[Lars Ingebrigtsen]

There's apparently not been any development on Monotone since 2014:

  https://www.monotone.ca/

According to this bug report, our vc-mtn doesn't work at all with the
version that was current in 2010, and there's been zero bug reports
about that in a decade.  So I think we should obsolete vc-mtn.el.

Does anybody have any comments?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#6513: bug#7171: vc-mtn to use "mtn automate"

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> There's apparently not been any development on Monotone since 2014:
>
>   https://www.monotone.ca/
>
> According to this bug report, our vc-mtn doesn't work at all with the
> version that was current in 2010, and there's been zero bug reports
> about that in a decade.  So I think we should obsolete vc-mtn.el.
>
> Does anybody have any comments?

+1


        Stefan

bug#6513: bug#7171: vc-mtn to use "mtn automate"

[Glenn Morris]

Lars Ingebrigtsen wrote:

> According to this bug report, our vc-mtn doesn't work at all with the
> version that was current in 2010, and there's been zero bug reports
> about that in a decade.  So I think we should obsolete vc-mtn.el.

I don't object, but I think you may have missed

https://debbugs.gnu.org/bug=6513#36

which was a "quiet" comment explaining that the breakage was fixed
2010-11-08. This bug stayed open as basically an improvement request to
use "mtn automate".

(Disclaimer: I haven't tested any of this.)

bug#6513: bug#7171: vc-mtn to use "mtn automate"

[Lars Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> I don't object, but I think you may have missed
>
> https://debbugs.gnu.org/bug=6513#36
>
> which was a "quiet" comment explaining that the breakage was fixed
> 2010-11-08. This bug stayed open as basically an improvement request to
> use "mtn automate".

Yup.  debbugs-gnu still doesn't display "quiet" comments, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#7171: vc-mtn to use "mtn automate"

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> I don't object, but I think you may have missed
>>
>> https://debbugs.gnu.org/bug=6513#36
>>
>> which was a "quiet" comment explaining that the breakage was fixed
>> 2010-11-08. This bug stayed open as basically an improvement request to
>> use "mtn automate".
>
> Yup.  debbugs-gnu still doesn't display "quiet" comments, I think.

Anyway, I've now made vc-mtn obsolete in Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no