monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] strptime not in MinGW time.h


From: Stephen Leake
Subject: Re: [Monotone-devel] strptime not in MinGW time.h
Date: Sat, 22 May 2010 07:09:53 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt)

Thomas Keller <address@hidden> writes:

> I think its sufficient to disable the date format changing on win32 for
> now 

I'm not clear exactly what this would mean. The date format is specified
either by --date_fmt or by the Lua hook get_date_format_spec. I don't
see an easy way to "disable" those on Win32.

date_fmt is used in lots of places for date output.

Perhaps you mean "disable commit date changing", not "disable date
format changing". That makes more sense.

> and trigger a warning if the original entered value has been changed
> by the user to a value our date parsing infrastructure cannot
> understand. This is better than disabling it completly on win32 and if
> somebody cares he / she can contribute the work to include strptime
> into monotone as suggested earlier to make it fully work.

The only place strptime is needed is in cmd_ws_commit.cc
get_log_message_interactively; it parses the date from the changelog
text, which the user may have edited.

We can disable editing the commit date, by simply not putting that field
in the text sent to the edit_comment hook.

Currently, 'status' checks to see if date_fmt (either from the option or
from hook_get_date_format_spec) is valid, in the sense that
date_t::as_formatted_localtime and date_t::from_formatted_localtime
succeed when using it.

On Win32, this check will always fail, because strptime is not
implemented.

So get_log_message_interactively should do the same check to decide
whether to allow editing the commit date.

That way, even on Unix, if the user provides a date_fmt that strptime
doesn't like, commit won't fail.

-- 
-- Stephe



reply via email to

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