log uses inclusive revision ranges; inconsistent with other commands

[Ingo Strüwing]

bzr log -r "before:revid:x..revid:x"
  shows two revisions, while other bzr commands (e.g. diif, merge) select just one.

bzr log -r "revid:x..revid:x"
  shows one revision, while other bzr commands show nothing.

This seems to be documented in bzr help revisionspec somehow, but it is annoying and non-intuitive anyway.
BTW, mentioned documentation seems to be wrong about the numbers in example "bzr diff -r 3647..3649".

 bzr version
Bazaar (bzr) 1.10
  Python interpreter: /usr/bin/python 2.5.2
  Python standard library: /usr/lib/python2.5
  bzrlib: /usr/lib/python2.5/site-packages/bzrlib
  Bazaar configuration: /home2/mydev/.bazaar
  Bazaar log file: /home2/mydev/.bzr.log

Copyright 2005, 2006, 2007, 2008 Canonical Ltd.
http://bazaar-vcs.org/

bzr comes with ABSOLUTELY NO WARRANTY. bzr is free software, and
you may use, modify and redistribute it under the terms of the GNU
General Public License version 2 or later.

 bzr plugins
danny_plugins
    Danny's Plugins

difftools 0.91
    External diff tools plugin for Bazaar

fix277537
    Fix wrong order in inventory parents for specified revisions.

gtk 0.96.0.dev.1
    Graphical support for Bazaar using GTK.

launchpad
    Launchpad.net integration plugin for Bazaar.

mysql 0.4.1
    MySQL/Sun org workflow helpers

tetard
    (no description)

[Ian Clatworthy (ian-clatworthy)]

A patch to fix the documentation of revisionspec was applied to bzr.dev (trunk) a few days ago.

It's true that log treats ranges slightly differently to most other commands but that's by design:

* log shows the results *from* X to Y inclusive
* most other commands show the differences *between* X and Y.

In the words, the behaviour is different because the intent of the commands is different.

I think it is unlikely that we'll want to change the code but the documentation explaining the reasoning behind this difference needs work. I'm leaving this bug open accordingly.

[Marius Kruger (amanica)]

As Ian mentioned, this is by design and it is unlikely to change.

[Robert Collins (lifeless)]

On Fri, 2009-01-23 at 01:18 +0000, Ian Clatworthy wrote:
>
> * log shows the results *from* X to Y inclusive
> * most other commands show the differences *between* X and Y.
>
> In the words, the behaviour is different because the intent of the
> commands is different.
>
> I think it is unlikely that we'll want to change the code but the
> documentation explaining the reasoning behind this difference needs
> work. I'm leaving this bug open accordingly.

I think it would be ok to harmonise log with other commands; the fact
that is by design doesn't change the confusing effect on users.

-Rob

[Martin Pool (mbp)]

I think (possibly changing my mind here) that changing log would also
potentially be ok. I think bzr's current behaviour is consistent with
svn, which is only a weak reason to keep it, but if it's inconsistent
it'd be another reason to change it.

Can you think of any cases where making log non-inclusive would be annoying except for being a change in current behaviour?

I can see how it is confusing that eg log -r10..20 doesn't show you
what merge -r10..20 will merge.

[Vincent Ladeuil (vila)]

Note that if we change the behavior of log here, we may have to revisit how we handle '-r' (with a single revision) and '-c'.

Also note that 'bzr log -rnnn' used to display a single revision and has regressed since ~1.12 (?) but I think some other bugs have been filed for that.

[Marius Kruger (amanica)]

If you guys are sure you want this, I don't mind working on it.

[Eric Siegerman (eric97)]

On Fri, 2009-08-07 at 04:14 +0200, <email address hidden> wrote:
> * log -r 1..2 now only shows r2

Rather than changing the default and making the old behaviour available as an option, please seriously consider keeping the current (i.e. closed-range) behaviour as default, and adding an --exclude-lower-bound (or some such) option to request a half-open range.

Besides avoiding an incompatible UI change, this would allow folks to try it both ways (e.g. using an alias to get the half-open behaviour) and so to decide, based on experience as opposed to theory, whether the default should indeed be changed. I strongly believe that more people would find half-open-by-default to be a PITA than an improvement -- but that's just one more opinion sloshing around. Better to do some usability testing *before* changing the default.

The main driver for this change seems to be that log is perceived to be "inconsistent" with diff, but there are good, logical reasons for that. Matthew Fuller has explained them better than I could do:
    http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/59931
    http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/51876

Note also that a closed range for "log" traces its ancestry not just to SVN, but all the way back to RCS -- and indeed to SCCS in a limited way [1] (assuming, that is, that CSSC [2] is an accurate emulation in this respect; I don't have real SCCS available to test against). Of course, "because that's the way it's always been done" can be an unreliable guide, but when it comes to usability details like this one, I believe that longstanding practice should carry significant weight.

In summary, it would be useful to add --exclude-lower-bound (perhaps by another name), but *not* to make that the default -- at least, not without some usability testing first.

[1] The SCCS "prs" command, analogous to "bzr log", doesn't let one specify both ends of the range. But one can specify either end:
   - "-e -rX.Y" says "from earliest revision to X.Y"
   - "-l -rX.Y" says "from X.Y to latest revision"
 In both cases, rev. X.Y is included in the output.

[2] http://cssc.sourceforge.net/

  - Eric

[Martin Pool (mbp)]

This isn't in 2.2b2.

[Vincent Ladeuil (vila)]

>>>>> Martin Pool <email address hidden> writes:

    > This isn't in 2.2b2.
    > ** Changed in: bzr
    > Milestone: 2.2b2 => None

It's waiting for a review and has been tested by users (see
https://bugs.launchpad.net/bzr/+bug/474807/comments/50)