monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Issues with mtn commit and the latest net.venge.mo


From: Derek Scherger
Subject: Re: [Monotone-devel] Issues with mtn commit and the latest net.venge.monotone head
Date: Fri, 6 Mar 2009 20:30:59 -0700



On Fri, Mar 6, 2009 at 2:10 PM, Tero Koskinen <address@hidden> wrote:
Hi,

"mtn commit" seems to be broken in revision
d24b59732a5b3293592457cba013c8f8b716a875.

I found out two problems

Problem 1)

When doing "mtn commit" I get:
$ mtn ci
mtn.real: beginning commit on branch 'fi.iki.tkoskine.ahven'
mtn.real: warning: [string "<std hooks>"]:314: bad argument #1 to 'find' (string expected, got nil)
mtn.real: misuse: edit of log message failed
$

Downthread your monotone version reports that std_hooks.lua is patched, any chance there's a stray change in there causing the problem?


Setting EDITOR to "vi" (or something else helps):
$ echo $EDITOR

$ export EDITOR=vi
$ mtn commit
mtn.real: beginning commit on branch 'fi.iki.tkoskine.ahven'
mtn.real: committed revision 40a7d624e7f9f798ce2d6edac39b39712ce9fbdd
$

The problem was gone when I updated to revision
04766db8e363880fd1d50692d793661d9f4fdcf4. (A newer revision might also
work, I didn't iterate through every rev.)

Problem 2)

When doing "mtn commit -m 'long message'" I get unknown path errors:
$ mtn commit -m 'Increase version to 1.7'
mtn.real: warning: restriction includes unknown path '1.7'
mtn.real: warning: restriction includes unknown path 'to'
mtn.real: warning: restriction includes unknown path 'version'
mtn.real: misuse: 3 unknown paths
$

This looks like a shell problem. I don't know how monotone can cause a quoted string to become separated. Is "mtn" a script that doesn't have the proper "$@" or whatever with required quotes to represent arguments? I'm wondering about a script because you say "mtn" and it reports "mtn.real" ? Also, what shell are you running?

Looking at it again I wonder if your first problem has the same cause?

In other words, the text after the first word is interpreted as paths.
Update to rev 04766db8e363880fd1d50692d793661d9f4fdcf4 didn't solve
this, but in release 0.42 '-m' option works as expected.

Is that one running through the same script if there is one?

Cheers,
Derek



reply via email to

[Prev in Thread] Current Thread [Next in Thread]