Re: [Monotone-devel] monotone 0.48 released

[Stephen Leake]

Howard Spindel <address@hidden> writes:

> I've just installed release 0.48 on a Windoze machine.  It seems to work fine.
>
> However, I get a warning everytime it runs: date format '%x %X' cannot
> be used for commit

Specifically, from 'mtn status'. Does this happen for other commands (it
shouldn't)?

> Is this something I can ignore or are commits now broken on my machine
> (haven't tried one yet)?  

You can ignore it, but we should fix it in the point release (there will
be a 0.48.1 to fix another problem).

The problem is that Win32 does not have a date parsing function similar
to strptime. That is used to parse dates that are formatted in a
user-specified way.

However, use of user-specified formatted dates is entirely optional.

The reason 'status' complains is that the new commit comment editing
process puts a formatted date in the commit log, so the user can change
it if necessary. Then that date needs to be parsed. This is the only
place in mtn that user-specified dates are parsed (there are other
places where they are output).

However, if the user specifies a date format that is not parseable, the
commit comment editing process uses the standard date formatting (that
includes all formats on Win32). So there's no reason for 'status' to
complain.

> If it is something I can ignore from now, it would be nice if there
> were a way to get it to stop warning me.

You can tell monotone to ignore it by running "mtn --no-format-dates status".

You should specify the same option for commit, to avoid a similar warning.

You can specify --no-format-dates as the default for status and commit in
~/.monotonerc:

function get_default_command_options(command)
    local default_args = {}
    if (command[1] == "status") then
        table.insert(default_opts, "--no-format-dates")
    end
    if (command[1] == "commit") then
        table.insert(default_opts, "--no-format-dates")
    end
    return default_args
end


mtn developers:

A partial real fix is delete the check in 'status', since the commit
process can cope with unparseable user-specified date formats, whether
on Win32 or Unix. However, that leaves the check in commit, which is
still appropriate, for the case where the user specifies a date format
that is not parseable; it partly explains why they don't see their
chosen format in the commit comment they are editing. But the warning
message could be clearer about that.

A better real fix is to not enable user-specified dates by default;
users that want them can enable them, and specify the date format they
want at the same time, and worry about whether it can be parsed.

I also thought we replaced %x %X by something else; why is it showing up
here?

-- 
-- Stephe