cannot merge branches after changing LP permissions

[Al Stone]

I am frankly not sure where to start with this bug.

I have a project in LP where I needed to restrict check-in permissions, so I went to "Change Branch Details" and changed the owner from one team to myself (I also tried this with another, smaller team). However, once that change was made, I could not do merges -- I would get the message "ERROR: not a branch" on any attempt to merge.

For example, suppose the project name is "foo" (the actual project is private, unfortunately). I changed the branch details and then tried to bring in a merge proposal like so:

   $ bzr branch lp:foo merge.bzr
   $ cd merge.bzr
   $ bzr merge lp:~ahs3/foo/bugfix
   ...ERROR: not a branch...

If I change the branch details back, all is well. So, I have no idea if this is something LP has done to the files needed by bzr, or if bzr is hopelessly confused, or if I do not understand something about LP (the far more likely scenario). It's even possible that I was being allowed to change branch details, but they weren't actually changing.

[Aaron Bentley (abentley)]

Changing the owner changes the branch name, so the simplest explanation is that you were using the obsolete name for the branch when you tried to merge. That would make this a dupe of bug #190116. If this was not the case, please post the actual before-and-after branch names so that we can investigate further.

[Al Stone (ahs3)]

It absolutely _never_ occurred to me that the branch name would change as a result of changing permissions. That is completely counterintuitive. So, yes, I guess this is a duplicate of #190116. Is this at least documented somewhere? Or shouldn't it at least show up on the LP page as a warning when it does happen? I spent a good half hour searching for clues and got nowhere.

Please separate the permissions from the naming. By keeping them coupled, I am now faced with a choice of either disrupting the development team so we can freeze the source tree, or not freezing the source so I can keep people productive. Neither choice is a good one.

[Aaron Bentley (abentley)]

No, I don't think this is documented. A warning sounds like a good idea, too.