"log -rdate:" and "log -cdate:"

[Martin Pool]

On 27 November 2010 21:43, Eli Zaretskii <eliz at gnu.org> wrote:
> The "date:" revisionspec seem not to be entirely user-friendly in
> conjunction with "bzr log".  Or maybe I'm missing something.

I think what is happening here is that the date revspec (indeed, all
revspecs) are fairly eagerly converted to a revision id, specifically
the earliest revision on the mainline on that date iirc.  So it's as
if you said 'bzr log -r 42 FILE.'

This has a couple of problems

>  bzr log -rdate:2010-10-08 src/xterm.c

if the file wasn't changed in that particular revision, you get
nothing.  As you discovered, if you use two dates, you can find
something.

We could change this in either of two ways (at least):

- choose a single revision, but a bit later, so it is the revision on
that date that touched that file
- we could make this a different kind of revno that actually implies a
range; this somewhat changes the algebra of combining them but it
could still work

or
- we could have a different approach that logs everything then filters
by date; this would make more sense if you consider there could be
interesting revisions within non-mainline revisions; and that dates
are not guaranteed to run in order

>
> To my surprise, this shows nothing.  Hmm...  Reading the docs more
> carefully, I see that it says "-rdate:yesterday..", note the dots.
> Aha!
>
>  bzr log -rdate:2010-10-08.. src/xterm.c
>  102487: Dan Nicolaescu 2010-11-23 Include <sys/ioctl.h> unconditionally.
>  ...
>  101865: Chong Yidong 2010-10-08 * xterm.c (x_draw_relief_rect): Clear corner...
>  101845: Chong Yidong 2010-10-08 * xterm.c (x_draw_relief_rect): If box width...
>
> Note that there are 2 revisions from 2010-10-08.  These are the ones I
> want.  But I want only them.  So:
>
>  bzr log -rdate:2010-10-07..date:2010-10-08 src/xterm.c
>
> But this again comes up empty.  Hmm...  How about this then?
>
>  bzr log -rdate:2010-10-07..date:2010-10-09 src/xterm.c
>  101845: Chong Yidong 2010-10-08 * xterm.c (x_draw_relief_rect): If box width...
>
> Only one of the two I wanted...  Okay, let's try this:
>
>  bzr log -rdate:2010-10-07..date:2010-10-10 src/xterm.c
>  101865: Chong Yidong 2010-10-08 * xterm.c (x_draw_relief_rect): Clear corner...
>  101845: Chong Yidong 2010-10-08 * xterm.c (x_draw_relief_rect): If box width...
>
> At last!  But why did I need to extend the date range by one more day,
> when both changes show 2010-10-08 in the log results?

I suspect, without checking the code, this is because we're filtering
in your timezone but by default showing the timestamps in the tz in
which they were committed (you can change that.)

>
> "bzr log -cdate:", which I thought would be The Right Thing, is even
> worse.  Observe:
>
>  bzr log -cdate:2010-10-07 src/xterm.c
>  (Nothing)
>  bzr log -cdate:2010-10-08 src/xterm.c
>  (Nothing)
>  bzr log -cdate:2010-10-09 src/xterm.c
>  (Nothing)
>
> Now, I realize that the docs (under revisionspec) says: "Matches the
> first entry after a given date", "after" being the key word here.  So
> "-cdate:" found a first revision _after_ the specified date, saw that
> it didn't change src/xterm.c, and showed an empty list.  But can you
> see how this is unhelpful, in the use-case I presented?  (Yes, I could
> use "date:YYYY-MM-DD,HH:MM" to get what I want, but I only knew the
> date, not the hour.)

Right, I agree.

>
> To summarize:
>
>  . there doesn't seem to be a good way of finding revisions of a
>    single file when only a date is known; -rdate: seems to be useful
>    mainly for showing revisions without selecting a file
>
>  . there appears to be some issue with the date, in that dates shown
>    in "bzr log"s output are somewhat inconsistent with -rdate:,
>    perhaps due to time-zone issues
>
> Did I miss something?  If not, can we have a more user-friendly way
> for this use-case, please?

I think that's correct.  I think the first has a bug report already.

-- 
Martin