bzr up locks master branch

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

Robert Collins wrote:
> Public bug reported:
>
> This seems to be a regression done fairly recently.
>
> bzr up locks the master branch, it shouldn't - it should only lock the
> local branch.
>
> affects bzr
> status triaged
> importance high
>
> ** Affects: bzr
> Importance: High
> Status: Triaged
>

I'm fairly sure you're running into the ~ versus %7E bug. I could be
wrong if you have investigated further than that.

John
=:->

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

iEYEARECAAYFAkqCIcYACgkQJdeBCYSNAAMyCwCg1FrwSP/3lm3aRPLBCVha8sji
fqUAniOlox3KEX+dUfYhBjqLMlO5+w89
=LOdL
-----END PGP SIGNATURE-----

On Wed, 2009-08-12 at 01:58 +0000, John A Meinel wrote:
>
> I'm fairly sure you're running into the ~ versus %7E bug. I could be
> wrong if you have investigated further than that.

Oh, that would cause an issue with these symptoms?

-Rob

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

Robert Collins wrote:
> On Wed, 2009-08-12 at 01:58 +0000, John A Meinel wrote:
>> I'm fairly sure you're running into the ~ versus %7E bug. I could be
>> wrong if you have investigated further than that.
>
> Oh, that would cause an issue with these symptoms?
>
> -Rob
>

Yeah. If it thinks the master branch is ".../%7E..." and you try to
update against ".../~..." then it sees that get_bound_location() !=
target.base and it decides it needs to lock the master branch.

I haven't worked out any test cases, etc. And it would require some
possibly strange code paths. But it is *possible*.

Certainly doing:
  bzr-old co lp:project
  cd project
  bzr-new update lp:project

Is quite likely to exhibit this.

John
=:->

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

iEYEARECAAYFAkqCLDQACgkQJdeBCYSNAAO9FwCeK2QdeYfS7G4zaU/TBfF2d75p
20MAn20ENTJjvR5NDXFU5luXs6Ig9eXr
=0eW1
-----END PGP SIGNATURE-----

Ok. Is there a bug open for that, or should this be it?

And, any thoughts on fixing this? The one that jumps to my mind is to
normalise the url we load from the config.

-Rob

I'm pretty sure there is another bug open for it, as I gave someone the advice to "bzr unbind; bzr bind lp:foo" and that seemed to solve it for them.

I thought for a second bug #412657 was that bug, until I realize that it was a new bug, and certainly not the one I commented on earlier.

I think the main key is that whatever url is returned from get_bound_location() needs to have the same normalization as the one in Transport.base.

My guess is that we started normalizing Transport.base (which is used for Branch.base) but we don't normalize it when reading.

It seems this regression was introduced in bzr 1.17.

Can anybody still reproduce this?

[Expired for Bazaar because there has been no activity for 60 days.]