cannot uncommit to a non-mainline revision

[Mats Kindahl]

The following command:

    $ bzr uncommit -r ancestor:../../6.0-rpl-merge/

Generates the exception below. I have tried figuring out the revision using revision info (which works fine) and then get the same error when using the literal revisionid instead of the 'ancestor:' specification above. The ancestor above is a merge changeset.

bzr: ERROR: exceptions.TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 857, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 3708, in run
    local=local)
  File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 3731, in _run
    revno = revision[0].in_history(b).revno + 1
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

bzr 1.6 on python 2.5.2 (linux2)
arguments: ['/usr/bin/bzr', 'uncommit', '-r', 'ancestor:../../6.0-rpl-merge/']
encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'en_US.UTF-8'
plugins:
  difftools /home/mats/.bazaar/plugins/difftools [0.91.0]
  extmerge /home/mats/.bazaar/plugins/extmerge [unknown]
  fastimport /home/mats/.bazaar/plugins/fastimport [unknown]
  gtk /home/mats/.bazaar/plugins/gtk [0.96.0dev1]
  launchpad /usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
  mysql /home/mats/.bazaar/plugins/mysql [0.3.18]
  tests /home/mats/.bazaar/plugins/tests [unknown]
*** 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.

[Aaron Bentley (abentley)]

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

Mats Kindahl wrote:
> Public bug reported:
>
> The following command:
>
> $ bzr uncommit -r ancestor:../../6.0-rpl-merge/
>
> Generates the exception below. I have tried figuring out the revision
> using revision info (which works fine) and then get the same error when
> using the literal revisionid instead of the 'ancestor:' specification
> above. The ancestor above is a merge changeset.

Of course, it should not fail like this.

This is happening because you are uncommitting to a revision that is not
in the lefthand ancestry-- a revision that was never committed or pulled
into this branch in the first place.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFItcwJ0F+nu1YWqI0RAuxTAJ9bYvWSnlXAWwORuleRMaFuLiSiWQCdHnU7
99pmTN9sA9ljIhPQV7SGnCM=
=3V3m
-----END PGP SIGNATURE-----

[Mats Kindahl (mkindahl)]

Aaron Bentley wrote:
> Mats Kindahl wrote:
>> Public bug reported:
>
>> The following command:
>
>> $ bzr uncommit -r ancestor:../../6.0-rpl-merge/
>
>> Generates the exception below. I have tried figuring out the revision
>> using revision info (which works fine) and then get the same error when
>> using the literal revisionid instead of the 'ancestor:' specification
>> above. The ancestor above is a merge changeset.
>
> Of course, it should not fail like this.
>
> This is happening because you are uncommitting to a revision that is not
> in the lefthand ancestry-- a revision that was never committed or pulled
> into this branch in the first place.

Hi Aaron!

Thanks for the information. I have to admit that I don't understand what
it means that a revision is not "in the lefthand ancestry". However, my
problem is quite simple: sometimes it is necessary to create a branch
that is the GCA of two other branches (for example, to be able to create
a patch for two versions that I can pull into both branches even
assuming that they have diverged). For this to work, one would expect
the ancestor: specification to denote a revision that it is possible to
uncommit to, otherwise there is not much use for ancestor: except to get
information.

I would suggest that either the ancestor: specification gives the latest
revision that is in both branches *that it is possible to uncommit to*,
or that a new "protocol" for a revision specification is introduced that
allow this.

Best wishes,
Mats Kindahl

--
Mats Kindahl
Lead Software Developer
Replication Team
MySQL AB, www.mysql.com

[Aaron Bentley (abentley)]

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

Mats Kindahl wrote:
> Aaron Bentley wrote:
>> Mats Kindahl wrote:
> Thanks for the information. I have to admit that I don't understand what
> it means that a revision is not "in the lefthand ancestry".

The left-hand ancestry contains only those revisions you have committed
or pulled into the branch, not those you have merged. It follows the
left-hand parents in the graph.

> However, my
> problem is quite simple: sometimes it is necessary to create a branch

To create a branch at an arbitrary revision, use "branch -r", not uncommit.

> that is the GCA of two other branches

Ancestor calculates the LCA, not the GCA.

> (for example, to be able to create
> a patch for two versions that I can pull into both branches even
> assuming that they have diverged).

But you want the LCA apparently.

 For this to work, one would expect
> the ancestor: specification to denote a revision that it is possible to
> uncommit to, otherwise there is not much use for ancestor: except to get
> information.

ancestor: is tremendously useful for diff. If that were its only
justification that would be more than enough.

> I would suggest that either the ancestor: specification gives the latest
> revision that is in both branches *that it is possible to uncommit to*

ancestor: will not change.

> or that a new "protocol" for a revision specification is introduced that
> allow this.

This is a bug in uncommit. It should have worked. I was just telling
you that it was an unusual, possibly mistaken use of uncommit. There's
no need to introduce new revision specifications to work around it.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIuEkz0F+nu1YWqI0RAkZCAJ0UB/5jnOJztyH08AjY4WKL0hKiDwCfWk2M
OucH0B2KYdKc+qIecuMxidY=
=AKS2
-----END PGP SIGNATURE-----

[Mats Kindahl (mkindahl)]

Aaron Bentley wrote:
[snip]

> This is a bug in uncommit. It should have worked. I was just telling
> you that it was an unusual, possibly mistaken use of uncommit. There's
> no need to introduce new revision specifications to work around it.

OK. So once the bug is fixed, it will work to use uncommit in this fashon?

Best wishes,
Mats Kindahl

>
> Aaron

[GuilhemBichot (guilhem-bichot)]

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#250150 seems to be the same, I'll post there too.
Aaron, about "This is happening because you are uncommitting to a revision that is not
in the lefthand ancestry-- a revision that was never committed or pulled
into this branch in the first place." :
what is absolutely sure is that at some point (Dec 5) this revision above was the head of branch mysql-maria. Then, via some "bzr merge"s and "bzr push"s between this branch and mysql-5.1 (https://code.launchpad.net/~mysql/mysql-server/mysql-5.1), it indeed ended up as "not in the lefthand ancestry"; we probably did:
cd mysql-5.1
bzr merge mysql-maria
bzr push mysql-maria
Why did I use "uncommit -r": because I wanted to revert my working tree to when 'revid:<email address hidden>' was the head of the branch (I would have done "bzr revert" after that). I am not sure this is mistaken use?

[Vincent Ladeuil (vila)]

@Mats: it is necessary to create a branch that is the GCA of two other branches

bzr pull --overwrite -r<revid>

Will give you the branch you want in your actual working tree.

@Guilhem: I am not sure this is mistaken use?
bzr pull --overwrite -rrevid:<email address hidden>

will give you what you want. So it's not mistaken use, but pull is more appropriate.

Now, 'uncommit -rrevid' should be fixed to accept arbitrary revisions.

Keep in mind though, that uncommit will:
- put the content of the revision in the working tree,
- point the associated branch to the revid
- record as pending merges all merges that occured between the tip and the revision

The last point is the most problematic (it's trivial for revnos, not so trivial for arbitrary revids),
but I'm pretty sure that for both of you it is of no interest since you both
want to get rid of it anyway by issuing 'bzr revert' just after the uncommit.

[GuilhemBichot (guilhem-bichot)]

Merci Vincent; pull --overwrite will do the trick.