A Strawman design: Nested Branch References

This is proposal is a strawman, intended to provoke discussion and explore the problem space.

It seems to give pretty good answers to most of the questions at DistributedDevelopment/BzrStoriesQuestions

• — Andrew Bennetts

Assumption: Nested treeless branches

First, assume bzr has a new variation of the "nested trees" feature, the ability to version a treeless branch, called a nested treeless branch, e.g. record in an inventory that some/path is a treeless branch of revid REVID. When building a working tree on disk this is as if bzr branch --no-tree -r REVID . some/path was executed.

Because they are inventory entries, we can track renames of these things, and bzr merge will work with them fairly naturally, e.g. if one side adds or removes one, or if the revid is updated, etc. bzr merge when both sides have made divergent changes to their nested branch references may get hairy and recursive; presumably in that case a bzr merge of the two divergent versions of the nested branch needs to be resolved and committed...

(The main difficulty I see is deciding the repo for the nested branches -- if I checkout a branch with one of these in it, how will bzr know where to find the revision named in the nested branch reference? The simplest solution is to fetch all the revisions into the containing branch's repo. A nicer solution may be to make the containing branch stacked on the repo of the nested branch... this implies that a branch may need to be able to be stacked on multiple branches/repos.)

Proposal for source packages: version branch references instead of diffs

• debian/bzr-patches/, a directory of nested treeless branches, one per "patch".

• each bzr-patch is a branch that can be merged into the root of the package (i.e. upstream). Each defines a change to be applied to the upstream branch

  via bzr merge before building binary packages. The changes are to be applied in lexicographic order, e.g. 15-fix-crash would be applied before 33-fix-typo.

• debian/ dir is in its own branch
  • debian dir is a nested tree, versioning the contents of the bzr-patches directory.

  • thus a name -> revid mapping is versioned in the debian dir

  • i.e. if a new branch is created at debian/bzr-patches/15-fix-bug-123456,

    then that change can be bzr add and bzr ci as usual, and this fact recorded in the debian/ dir.

• bzr-patches branches probably stored as standalone stacked branches, using upstream as the basis (i.e. stacked-on=../..)
• this model is pretty easy to explain: it's very similar to versioning a debian directory of plain old diffs
• need an operation to export as source package that uses plain old diffs (for compatibility).
• lacks overall versioning of upstream version + debian directory
• debian/upstream is a nested tree reference to the upstream revid this package was built from. Thus the packaging branch contains enough information to construct the bzr-less source package (this process could be automated by bzr-builddeb):
  • bzr checkout revid in debian/upstream to src-package-tmp (bzr may need help finding the repo that has that revid, though!)
  • bzr checkout the packaging branch to src-package-tmp/debian
  • build debian/patches from debian/bzr-patches (by converting each

    branch to a diff, e.g. cd src-package-tmp/debian; bzr diff --old .. --new bzr-patches/15-fix-bug-123456 > patches/15-fix-bug-123456.diff)

• can use bzr switch debian/upstream, bzr switch debian/bzr-patches/15-fix-bug-123456 etc to change "thread".

This is in some ways an alternative to a loom: instead of tracking the multiple tips in a new structure, they are tracked as part of a tree.