reconfigure of stacked-on branch does not check stacked repo will be compatible

[Martin von Gagern]

Reconfiguring a stacked branch to use a shared repo with a different rich-root support seems to break the branch in question. The attached script demonstrates the issue. It would be nice if either things worked or reconfigure would print a suitable error message, maybe asking users to unstack the branch first, and then abort without modifying anything.

+ bzr init --1.6 src
Created a standalone tree (format: 1.6)
+ cd src
+ echo foo > foo
+ bzr add foo
adding foo
+ bzr ci -m foo
Committing to: .../testing/src/
added foo
Committed revision 1.
+ cd ..
+ bzr clone --stacked src dst
Created new stacked branch referring to file://.../testing/src/.
+ bzr info dst
Standalone tree (format: 1.6)
Location:
  branch root: dst

Related branches:
  parent branch: src
     stacked on: src
+ bzr init-repo --2a .
Shared repository with trees (format: 2a)
Location:
  shared repository: .
+ cd dst
+ bzr reconfigure --use-shared
Doing on-the-fly conversion from <RepositoryFormatKnitPack5> to <RepositoryFormat2a>.
This may take some time. Upgrade the repositories to the same format for better performance.

+ bzr info
bzr: ERROR: KnitPackRepository('file://.../testing/src/.bzr/repository/')
is not compatible with
CHKInventoryRepository('file://.../testing/.bzr/repository/')
different rich-root support
+ bzr status
bzr: ERROR: KnitPackRepository('file://.../testing/src/.bzr/repository/')
is not compatible with
CHKInventoryRepository('file://.../testing/.bzr/repository/')
different rich-root support

[Robert Collins (lifeless)]

 summary "reconfigure of stacked-on branch does not check stacked repo will be compatible"
 status confirmed
 importance medium

So what is happening here is that stacking requires a format match - its
nothing specifically to do with rich root.

If you get into this state, 'bzr upgrade' of the thing you are stacked
on to the same format as your local shared repo will get it all going
again.

Note that stacked branches in shared repos isn't really a great idea
anyway, and not something we expect to see much in the wild.

-Rob

[Martin von Gagern (gagern)]

> Note that stacked branches in shared repos isn't really a great idea
> anyway, and not something we expect to see much in the wild.

Suppose I wish to develop a bunch of interdependent feature branches for
a project with a big history - either long or some huge files committed
in the past. Then I'd choose that approach in the wild.

[Robert Collins (lifeless)]

On Wed, 2010-02-24 at 21:46 +0000, Martin von Gagern wrote:

> Suppose I wish to develop a bunch of interdependent feature branches for
> a project with a big history - either long or some huge files committed
> in the past. Then I'd choose that approach in the wild.

That would be a mistake though: stacked branches require access to the
history anyway, and accessing it over the internet repeatedly will be
slower than having it locally in a simple shared repository.

The use case for stacked branches is shared-nothing storage optimisation
on hosting sites; where the stacking is local.

-Rob