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

[Maritza Mendez]

On Mon, Nov 29, 2010 at 12:56 AM, Martin Pool <mbp at canonical.com> wrote:

> 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
>
>
Martin,

Thank you for your openness to discussing this aspect of revisionspecs.  My
team and I have experience similar to Eli's post.  I cannot articulate it
any better than this: dates seem to be special.  People (including me) seem
to have intuitive expectations when specifying a date different from the
simple (and well defined) semantics of the date: syntax.  So I think your
third bullet (log+filter) is especially insightful.  I already do something
like this manually and often.  A trivial example is to reverse the "sense"
of 'date' to pick the "latest before" instead of the "earliest after"
revision for the upper end of a revspec range.  I understand your third
bullet as meaning "leave revspecs alone but allow for a thin interpretive
layer" which is both good for the stability of bzr and fulfills the
"batteries included" vision.  I realize there are efficiency implications,
but efficiency counts most when the user gets what she expects.  :)

~M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20101129/3a2630e0/attachment.htm