Cannot use bzr uncommit to roll back to a revision that has revno with dots

Bug #250150 reported by Sergey Petrunia on 2008-07-19
44
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Unassigned
Breezy
Medium
Unassigned

Bug Description

It is not possible to "bzr uncommit" to a revision that has dots in the revno.

Here's the demonstration:

psergey@pslp mysql-6.0 $ bzr log --show-ids --limit=10
<skip>
------------------------------------------------------------
revno: 2670
revision-id: <email address hidden>
parent: <email address hidden>
parent: <email address hidden>
committer: Chuck Bell <email address hidden>
branch nick: mysql-6.0-backup-merge
timestamp: Tue 2008-07-15 16:02:29 -0400
message:
  Pull from main (falcon changes). Changed myisamlog.test to indicate last change was reported as BUG#38133.
    ------------------------------------------------------------
    revno: 2599.106.21
    revision-id: <email address hidden>
    parent: <email address hidden>
    parent: <email address hidden>
    committer: Hakan Kuecuekyilmaz <email address hidden>
    branch nick: mysql-6.0-falcon-to-merge
    timestamp: Mon 2008-07-14 19:28:28 +0200
    message:
      Merge.
        ------------------------------------------------------------

psergey@pslp mysql-6.0 $ bzr uncommit -r2599.106.21
bzr: ERROR: exceptions.TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

Traceback (most recent call last):
  File "/home/psergey/lib/python/bzrlib/commands.py", line 846, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/home/psergey/lib/python/bzrlib/commands.py", line 797, in run_bzr
    ret = run(*run_argv)
  File "/home/psergey/lib/python/bzrlib/commands.py", line 499, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/psergey/lib/python/bzrlib/builtins.py", line 3797, in run
    local=local)
  File "/home/psergey/lib/python/bzrlib/builtins.py", line 3820, in _run
    revno = revision[0].in_history(b).revno + 1
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

bzr 1.6b3 on python 2.4.4 (linux2)
arguments: ['/home/psergey/bin/bzr', 'uncommit', '-r2599.106.21']
encoding: 'ANSI_X3.4-1968', fsenc: 'ANSI_X3.4-1968', lang: None
plugins:
  difftools /home/psergey/.bazaar/plugins/difftools [0.91.0]
  extmerge /home/psergey/.bazaar/plugins/extmerge [unknown]
  gtk /home/psergey/.bazaar/plugins/gtk [0.95.0dev1]
  launchpad /home/psergey/lib/python/bzrlib/plugins/launchpad [unknown]
  mysql /home/psergey/.bazaar/plugins/mysql [0.3.14]
*** Bazaar has encountered an internal error.
    Please report a bug at https://bugs.launchpad.net/bzr/+filebug
    including this traceback, and a description of what you
    were doing when the error occurred.

# Specifying revid doesn't help:

psergey@pslp mysql-6.0 $ bzr uncommit -rrevid:<email address hidden>
bzr: ERROR: exceptions.TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

Traceback (most recent call last):
  File "/home/psergey/lib/python/bzrlib/commands.py", line 846, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/home/psergey/lib/python/bzrlib/commands.py", line 797, in run_bzr
    ret = run(*run_argv)
  File "/home/psergey/lib/python/bzrlib/commands.py", line 499, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/psergey/lib/python/bzrlib/builtins.py", line 3797, in run
    local=local)
  File "/home/psergey/lib/python/bzrlib/builtins.py", line 3820, in _run
    revno = revision[0].in_history(b).revno + 1
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

bzr 1.6b3 on python 2.4.4 (linux2)
arguments: ['/home/psergey/bin/bzr', 'uncommit', '-rrevid:<email address hidden>']
encoding: 'ANSI_X3.4-1968', fsenc: 'ANSI_X3.4-1968', lang: None
plugins:
  difftools /home/psergey/.bazaar/plugins/difftools [0.91.0]
  extmerge /home/psergey/.bazaar/plugins/extmerge [unknown]
  gtk /home/psergey/.bazaar/plugins/gtk [0.95.0dev1]
  launchpad /home/psergey/lib/python/bzrlib/plugins/launchpad [unknown]
  mysql /home/psergey/.bazaar/plugins/mysql [0.3.14]
*** Bazaar has encountered an internal error.
    Please report a bug at https://bugs.launchpad.net/bzr/+filebug
    including this traceback, and a description of what you
    were doing when the error occurred.

Getting this resolved is important for us at MySQL because we quite often need to check the behavior of some preceding version.

James Westby (james-w) wrote :

Hi,

> Getting this resolved is important for us at MySQL because we quite often need to check the behavior of some preceding version.

There are other ways to this than uncommit, e.g. revert. Obviously you should make sure
that you don't have uncommitted changes before you start, but as you have to revert after
uncommit to do what you want you should already be doing that.

Thanks,

James

Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed

On Sat, 2008-07-19 at 17:40 +0000, Sergey Petrunia wrote:
>
> Getting this resolved is important for us at MySQL because we quite
> often need to check the behavior of some preceding version.

I agree that this is a bug. Note that uncommit *does not* change your
tree to the requested revision - it just pops the commit off the stack.
So you have to revert anyway to get back to the older tree version.

Some ways of doing this:
 bzr revert -rx.y.z
 bzr branch -rx.y.z $branches/trunk $branches/old-branch && bzr switch
old-branch

Hope this helps,
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

GuilhemBichot (guilhem-bichot) wrote :

Hit this today too; branched mysql-maria at https://code.launchpad.net/~mysql/mysql-server/mysql-maria
and did
bzr uncommit -r 'revid:<email address hidden>'
BUG#261770 seems to be the same, I'll post there too.

Martin Pool (mbp) on 2010-02-11
tags: added: easy uncommit
GuilhemBichot (guilhem-bichot) wrote :

In hindsight, I don't see a strong reason for being able to uncommit to such dotted revision. As Robert explained, "bzr revert -r" and "bzr branch -r" are fine.
I think that when we filed this, we thought of uncommit as the only way to get back in time.
So, fine if it is fixed, but not necessary for MySQL.

Ian Clatworthy (ian-clatworthy) wrote :

Well the exception is certainly ugly in any case. Maybe we should trap a non-mainline revision argument and suggest other commands?

On 12 February 2010 14:02, Ian Clatworthy <email address hidden> wrote:
> Well the exception is certainly ugly in any case. Maybe we should trap a
> non-mainline revision argument and suggest other commands?

If people explicitly ask to uncommit to a non-mainline revision I
don't see why we should not allow that. It probably just needs the
check removed.

--
Martin <http://launchpad.net/~mbp/>

> If people explicitly ask to uncommit to a non-mainline revision I
> don't see why we should not allow that. It probably just needs the
> check removed.

Well... what would it mean, though? Uncommit leaves your WT in the
state it currently is, with all changes included in the current state,
including pending merges. Preserving that behavior means that after
the uncommit, you'd have to be in a state where your now-current head
ends up somewhere on the RHS of the history.

On 12 February 2010 15:07, fullermd <email address hidden> wrote:
>> If people explicitly ask to uncommit to a non-mainline revision I
>> don't see why we should not allow that.  It probably just needs the
>> check removed.
>
> Well...   what would it mean, though?  Uncommit leaves your WT in the
> state it currently is, with all changes included in the current state,
> including pending merges.  Preserving that behavior means that after
> the uncommit, you'd have to be in a state where your now-current head
> ends up somewhere on the RHS of the history.

To be more precise, it turns anything that was merged in into a
pending merge. I'm not sure if you'd commonly want to do this but
it's well-defined and doesn't need to be forbidden, unless we feel
sure people are only doing this when they're confused.

--
Martin <http://launchpad.net/~mbp/>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> On 12 February 2010 14:02, Ian Clatworthy <email address hidden> wrote:
>> Well the exception is certainly ugly in any case. Maybe we should trap a
>> non-mainline revision argument and suggest other commands?
>
> If people explicitly ask to uncommit to a non-mainline revision I
> don't see why we should not allow that. It probably just needs the
> check removed.
>

The reason it fails is because we log the mainline. Also because at one
point doing "uncommit -r X" actually meant "set_last_revision(x-1)". I
think we now just do "set_last_revision(x)" so that should be simpler.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt1W1sACgkQJdeBCYSNAAPGLgCgh1Qz/SrFSHcoaj+UPKcviX2C
5zIAn1tbiOrWbe/aLRJDHe+rs72eXrxy
=kOJ7
-----END PGP SIGNATURE-----

Dimitri John Ledkov (xnox) wrote :

$ bzr update -r x.y.z

fails as well.

Updating working tree to find out where something got broken between mainline commits is important.

Dmitrijs Ledkovs wrote:
> $ bzr update -r x.y.z
>
> fails as well.
>
> Updating working tree to find out where something got broken between
> mainline commits is important.

Yes. That's bug 517800, and it was actually fixed in lp:bzr a month ago:

<http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5140>

Jelmer Vernooij (jelmer) on 2017-11-08
tags: added: check-for-breezy
Jelmer Vernooij (jelmer) on 2018-11-04
Changed in brz:
status: New → Triaged
importance: Undecided → Medium
tags: removed: check-for-breezy
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers