Converging Bazaar and BazaarNG

Status

• Created: 23/04/05 by RobertCollins

• Priority: HighPriority

• People: RobertCollinsLead, MartinPoolSecond

• Contributors:

• Interested: MarkShuttleworth

• Status: ApprovedSpecification, BazaarSpecification, BazaarDevel

• Branch:
• Malone Bug:
• Packages:
• Depends:

• UduSessions: 2

Introduction

This specification discusses the planned convergence of Bazaar and BazaarNG so that users of baz today, or potential users of bzr can plan when and how they will be able to use production-ready BazaarNG, and what to expect from baz in the future.

See also HctAndBazNgConvergence which tells the other side of the story.

Rationale

Both Bazaar and Bazaar-NG are turning into excellent distributed development tools. In the medium term we want to produce a single tool which has the best aspects of both, and which allows a lossless upgrade of existing data.

Exactly how this unification will be achieved depends on the technical progress and user acceptance of the two tools over coming months. Without short-circuiting that process, this page describes issues to watch during development.

A major reason for moving away from the arch design is to simplify the design and the user experience. The final tool should retain the relative simplicity of bzr.

Implementation Plan

The following points of difference between bzr and baz need to be resolved:

• baz has explicitly-named branches; bzr has branches identified by the head revision / location.

  • BranchNaming is being worked on.

  • Baz is gaining support for fetching branches from URLs, which partially closes this gap.
• bzr branches are unix directories, rather than objects within an archive. (Code that relies on enumerating the namespace elements within an archive may need to change, but I don't think HCT does that.)

• File formats are different between the two tools; RobertCollins has some experimental support for this already.

• Explicit inventories rather than file-ids, and the tagging-method is much simpler.
  • Bazaar will translate the GNU Arch policy into Bazaar-NG policy when trees are converted. Round tripping is not a goal, so this should be straight forward for the common case ... non trivial policy conversion will not be done automatically.
• Control files are not versioned.

  • Bazaar's {arch} directory is versioned. Making this unversioned in a significant and critical step.

    For most branches this will not be a problem. However, tla allows people to be rather too clever in modifying files in that directory other than by using tla: they might store their address book in {arch}/address-book and this would work under arch. They can also use arch to revise historical commit messages. This information would be lost in a straightforward import from arch. One possible approach is to carry selected files across from arch into bzr, but it's probably not worthwhile.

• Bazaar-NG has more abstract storage; uses in-memory virtual trees. Does not store deltas.
  • Bazaar will implement similar systems in the short term and identical ones in the medium term.
• Configs punted to external tool? No decision has been reached on this. More UI research needs to be performed to make a sane decision. The UI for configs in tla/baz is not ideal. It seems that configs in tla are largely independent of the version-control functionality, and only coincidentally implemented in the same tool. If that is the case they can be lifted out to a separate tool, or a bazaar-ng plugin, with no problems.
• Bazaar NG has no revlib facility as it's not needed with its storage format.

Possible outcomes form a spectrum from continuing with the Python code through to dropping it and continuing with baz. At present it seems likely that a hybrid will contain some Python code with C modules.

There is an open question of whether archives will need a conversion step or whether there will be a single tool which can read all historical formats. A conversion step seems reasonable. Bazaar will provide a one way trapdoor - upgrade to the Bazaar-NG formats, but not downgrade.

Some of these, such as file formats, can be resolved as a "simple matter of coding". The model changes require rather harder architectural decisions about which models should be supported by which programs.

Data Preservation and Migration

Bazaar will preserve all relevant data as it migrates archives. (Some arch internal data may be discarded as not relevant).

Migration may not preserve all data which exercises edge cases or exotic features of the source format, such as modifying files under {arch} in unconventional ways.

User Interface Requirements

Bazaar will evolve to the Bazaar-NG UI - but will also provide feedback on it as it does so. Over time, BazaarNG will feel increasingly familiar to users who have followed Bazaar development, especially Canonical developers.

Outstanding Issues

• The timeframe for the convergence is not yet clear, but it is expected to be in 2005.

CategoryUdu CategorySpec