log uses inclusive revision ranges; inconsistent with other commands

Bug #320119 reported by Ingo Strüwing on 2009-01-22
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Vincent Ladeuil

Bug Description

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)

Related branches

Ian Clatworthy (ian-clatworthy) wrote :

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) wrote :

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

Changed in bzr:
status: New → Won't Fix

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

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.

Changed in bzr:
status: Won't Fix → Confirmed
summary: - Inconsistent use of revision ranges
+ log uses inclusive revision ranges; inconsistent with other commands
Changed in bzr:
importance: Undecided → Medium
Vincent Ladeuil (vila) wrote :

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) wrote :

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

Changed in bzr:
assignee: nobody → Marius Kruger (amanica)
Marius Kruger (amanica) on 2009-07-19
Changed in bzr:
status: Confirmed → In Progress
Eric Siegerman (eric97) wrote :

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

Vincent Ladeuil (vila) on 2010-04-14
Changed in bzr:
assignee: Marius Kruger (amanica) → Vincent Ladeuil (vila)
Vincent Ladeuil (vila) on 2010-04-14
Changed in bzr:
milestone: none → 2.2b2
Martin Pool (mbp) wrote :

This isn't in 2.2b2.

Changed in bzr:
milestone: 2.2b2 → none

>>>>> 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)

Vincent Ladeuil (vila) on 2010-04-28
Changed in bzr:
milestone: none → 2.2b3
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers