documentation.HELP! Bazaar Documentation

Bazaar v2.2b1 documentation

Bazaar

Table of contents

• Developer Document Catalog (2.2b1)
• Contributing to Bazaar
  • Talk to us
  • Starting
  • Making a branch
  • Writing tests
  • Proposing a merge
• Bazaar Release Cycles
  • The Process
    • Schedule
    • Regularity
    • Numbering
    • Terminology
    • Bug Work
    • Feature and Performance Work
    • Plugins
    • Data and Network Formats
    • Hosting Services
    • Simultaneous Installation
    • OS Distributions
    • Packaging
    • Code Freeze vs Announcement
    • Weekly Metronome Mail
  • Questions
  • Expected Benefits
  • Reviewing for the Stable Branch
  • References
• Profiling
  • Using profilers
  • Profiling locks
  • Profiling HPSS Requests
• Tracking Bugs in Bazaar
  • Links
  • Generalities
  • Priorities
  • Clear Bugs
  • Bug Status
  • Bug Importance
  • Assignment
  • Targetting Bugs
  • Backports
  • The News File
  • Tags
• Bazaar Developer Guide
  • Getting Started
    • Exploring the Bazaar Platform
    • Finding Something To Do
    • Planning and Discussing Changes
    • Bazaar Development in a Nutshell
      • Making the change
      • Making a Merge Proposal
      • Why make a local copy of bzr.dev?
    • Understanding the Development Process
    • Preparing a Sandbox for Making Changes to Bazaar
    • Navigating the Code Base
  • The Code Review Process
    • Review cover letters
    • Reviewing proposed changes
    • Checklist for reviewers
    • Reviews on Launchpad
      • Proposing a merge through the web
      • Proposing a merge by mail
      • Reviewing changes
    • Reviews through Bundle Buggy
      • Sending patches for review
  • Coding Style Guidelines
    • hasattr and getattr
    • Code layout
    • Module Imports
    • Naming
    • Standard Names
    • Destructors
    • Cleanup methods
    • Factories
    • Registries
    • InterObject and multiple dispatch
    • Lazy Imports
    • The Null revision
    • Object string representations
    • Exception handling
    • Test coverage
  • Core Topics
    • Evolving Interfaces
      • Deprecation decorators
    • Getting Input
      • Processing Command Lines
      • Standard Parameter Types
    • Writing Output
      • Progress and Activity Indications
    • Displaying help
    • Handling Errors and Exceptions
    • Assertions
    • Documenting Changes
      • NEWS File
      • Commands
      • API Documentation
    • General Guidelines
      • Copyright
  • Miscellaneous Topics
    • Debugging
    • Debug Flags
    • Jargon
    • Unicode and Encoding Support
      • Command.outf
      • bzrlib.urlutils.unescape_for_display
    • Portability Tips
    • C Extension Modules
    • Making Installers for OS Windows
  • Core Developer Tasks
    • Overview
      • What is a Core Developer?
      • Communicating and Coordinating
    • Submitting Changes
      • An Overview of PQM
      • Selecting a Public Branch Location
      • Configuring the PQM Plug-In
      • Submitting a Change
      • Tracking Change Acceptance
    • Reviewing Blueprints
      • Blueprint Tracking Using Launchpad
      • Recording Blueprint Review Feedback
    • Planning Releases
      • Using Releases and Milestones in Launchpad
      • Bug Triage
• Bazaar Testing Guide
  • The Importance of Testing
  • Running the Test Suite
    • Running particular tests
    • Disabling plugins
    • Disabling crash reporting
    • Test suite debug flags
    • Using subunit
    • Using testrepository
  • Writing Tests
    • Where should I put a new test?
      • Unit tests
      • Blackbox (UI) tests
      • Per-implementation tests
      • Doctests
    • Shell-like tests
    • Import tariff tests
    • Testing locking behaviour
    • Skipping tests
    • Test feature dependencies
      • Writing tests that require a feature
      • Defining a new feature that tests can require
    • Testing exceptions and errors
    • Testing warnings
    • Interface implementation testing and test scenarios
    • Test scenarios
    • Test support
      • TestCase and its subclasses
      • BranchBuilder
      • TreeBuilder
• Releasing Bazaar
  • Preconditions
  • Starting a cycle
  • Starting the release phase
  • Making the source tarball
  • Publishing the source tarball
  • Announcing the source freeze
  • Publishing the release
  • Announcing the release
  • Merging the released code back to trunk
  • Releases until the final one
  • See also
• Managing the Bazaar PPA
  • Background
  • Preconditions
  • Packaging Bazaar
    • Short form
    • Long Form
    • Packaging bzr-svn
  • Monitoring the contents of PPAs
• Bazaar Windows EC2 Server
  • Goals
  • Approach
  • Procedures
    • Preparation
    • To start up an instance
    • To save a system snapshot as an image
    • Management console (useful!)
• Bazaar Architectural Overview
  • Essential Domain Classes
  • Transport
    • Filenames vs URLs
  • Repository
    • Stacked Repositories
• Integrating with Bazaar
  • Manipulating the Working Tree
  • Compare trees
  • Adding Files
  • Removing Files
  • Renaming a File
  • Moving Files
  • Committing Changes
  • Generating a Log for a File
  • Annotating a File
  • Working with branches
  • Branching from an existing branch
  • Pushing and pulling branches
  • Checkout from an existing branch
  • History Operations
    • Finding the last revision number or id
    • Getting the list of revision ids that make up a branch
    • Getting a Revision object from a revision id
    • Accessing the files from a revision
• Bazaar Design Principles
  • Testing
  • Data formats
• Plans
  • 1   Bazaar Performance Roadmap
    • 1.1   About the performance roadmap
      • 1.1.1   What should be in the roadmap?
      • 1.1.2   What should the final system look like, how is it different to what we have today?
      • 1.1.3   What use cases should be covered?
      • 1.1.4   How is development on the roadmap coordinated?
      • 1.1.5   Planned changes to the bzr core
        • 1.1.5.1   Library changes
        • 1.1.5.2   Interoperable disk changes
        • 1.1.5.3   Possibly non-interoperable disk changes
        • 1.1.5.4   Non-interoperable disk changes
      • 1.1.6   Integration of performance changes
    • 1.2   Analysis of use cases
      • 1.2.1   Analysing a specific use case
      • 1.2.2   Performing the analysis
      • 1.2.3   What factors should be considered?
    • 1.3   Use cases
      • 1.3.1   Initial push / pull
        • 1.3.1.1   Optimal case
        • 1.3.1.2   Disk case
        • 1.3.1.3   Smart Network Case
          • 1.3.1.3.1   Phase 1
          • 1.3.1.3.2   Phase 2
        • 1.3.1.4   Dumb Network Case
        • 1.3.1.5   Wants
      • 1.3.2   Incremental push/pull
        • 1.3.2.1   Functional Requirements
        • 1.3.2.2   Factors which should add work for push/pull
        • 1.3.2.3   Push/pull overview
          • 1.3.2.3.1   New data identification
            • 1.3.2.3.1.1   Set synchronisation approaches
            • 1.3.2.3.1.2   DAG synchronisation approaches
            • 1.3.2.3.1.3   File level scaling
            • 1.3.2.3.1.4   API scaling
          • 1.3.2.3.2   Data reading
            • 1.3.2.3.2.1   File level scaling
            • 1.3.2.3.2.2   API scaling
          • 1.3.2.3.3   Data Verification and writing
            • 1.3.2.3.3.1   Overview summary
            • 1.3.2.3.3.2   File level scaling
            • 1.3.2.3.3.3   API scaling
        • 1.3.2.4   Notes from London
      • 1.3.3   Add
        • 1.3.3.1   Least work we can hope to perform
        • 1.3.3.2   Per file algorithm
      • 1.3.4   Commit Performance Notes
        • 1.3.4.1   Changes to commit
        • 1.3.4.2   Commit: The Minimum Work Required
        • 1.3.4.3   Commit vs Status
        • 1.3.4.4   Avoiding Work: Smarter Change Detection
        • 1.3.4.5   Avoiding Work: Better Layering
        • 1.3.4.6   Avoiding work: avoiding reading parent data
        • 1.3.4.7   Code structure
        • 1.3.4.8   Complications of commit
        • 1.3.4.9   Interface stack
        • 1.3.4.10   Branch->Tree interface
        • 1.3.4.11   Information from the tree to repository
        • 1.3.4.12   Information from the repository to the tree
        • 1.3.4.13   Selective commit
        • 1.3.4.14   Common commit code
        • 1.3.4.15   Order of traversal
        • 1.3.4.16   Open question: per-file graphs
      • 1.3.5   diff Performance Analysis
        • 1.3.5.1   Minimal Work
          • 1.3.5.1.1   Reuse of historical comparisons
          • 1.3.5.1.2   Historical Tree Against Historical Tree
          • 1.3.5.1.3   Basis Against Historical Tree
          • 1.3.5.1.4   Basis Against Basis
          • 1.3.5.1.5   Working Tree Against Basis
          • 1.3.5.1.6   Working Tree Against Historical Tree
          • 1.3.5.1.7   Working Tree Against Working Tree
        • 1.3.5.2   API Changes
        • 1.3.5.3   Storage considerations
      • 1.3.6   Garbage Collection
        • 1.3.6.1   Least work we can hope to perform
      • 1.3.7   Revert
        • 1.3.7.1   Least work we can hope to perform
      • 1.3.8   The status command
        • 1.3.8.1   UI Overview
        • 1.3.8.2   Ideal work for working tree to historical status
        • 1.3.8.3   Locality of reference
        • 1.3.8.4   Scaling observations
      • 1.3.9   Annotate
      • 1.3.10   Scaling analysys of Merge
        • 1.3.10.1   Needs
        • 1.3.10.2   Notes
      • 1.3.11   Bundle Creation
        • 1.3.11.1   Needs
      • 1.3.12   Uncommit Performance Notes
        • 1.3.12.1   Specification of uncommit
      • 1.3.13   Missing
    • 1.4   Subsystem designs
      • 1.4.1   Directory fingerprints
        • 1.4.1.1   Introduction
        • 1.4.1.2   Use-case oriented APIs
          • 1.4.1.2.1   commit
          • 1.4.1.2.2   log
        • 1.4.1.3   Open questions
        • 1.4.1.4   Conclusions
        • 1.4.1.5   Design changes
        • 1.4.1.6   API changes
  • co-located branches
    • Rationale
    • Use Cases
    • Implementation
      • UI Changes
      • Code Changes
    • Schema Changes
    • Unresolved Issues
  • Bazaar Windows Shell Extension Options
    • Introduction
    • Background Information
      • The facts about shell extensions
      • Analysis of TortoiseSVN code
      • Analysis of existing TortoiseBzr code
    • Detailed Implementation Strategy
      • External Command Processor
      • Performance considerations
      • RPC options
      • Vista versus XP
      • Reuse of TSVNCache?
      • Reuse of this code by Mercurial or other Python based VCS systems?
    • Implementation plan
    • Alternative Implementation Strategies
      • Implement Completely in Python
  • CHK Optimized index
    • Required information
    • Partial Hash
    • Scaling Sizes
      • Scaling up
      • Scaling down
    • Other discussion
      • group encoding
      • variable length index entries
      • storing uncompressed offset + length
      • null content
      • VF.keys()
      • More than 64k groups
• Specifications
  • Revision Properties
    • Usage
    • Well-known properties
  • API Versioning
    • Status
    • Motivation
    • Terminology
    • API versions
    • Managing API versions
    • Exported API's
    • Use Cases
      • Requiring bzrlib 0.18 in a plugin
      • Exporting an API from a plugin
  • Bazaar Apport Integration
    • Consequences for users
    • Implementation notes
    • Future ideas
  • Authentication ring
    • Rationale
    • Authentication definitions
    • File format
    • Use Cases
    • UI Changes
    • Implementation constraints
    • Questions and Answers
  • Bundles
    • Status
    • Motivation
    • Desired features
    • Historical Design
    • June 2007 Design
    • Future Plans
      • Physical encoding
      • Code reuse
  • Container format
    • Status
    • Motivation
    • Terminology
    • Use Cases
      • Streaming data between a smart server and client
        • Incremental push or pull
      • Persistent storage on disk
      • Usable before deep model changes to Bazaar
      • Examples of possible record content
    • Characteristics
      • No length-prefixing of entire container
      • Structured as a self-contained series of records
      • Addressing records
      • Reasonably cheap for small records
    • Specification
      • Record types
        • End Marker
        • Bytes
      • Names
  • Overview
    • Current approach
    • Things to keep
    • Things to remove
    • Thoughts
  • Delta strategy
  • Implementation Strategy
  • Indices
    • Status
    • Motivation
    • Terminology
    • Overview
    • General Index API
      • Services
        • Build index
        • Retrieve entries from the index
        • Merging of indices
    • Index implementations
      • GraphIndex
  • Inventories
    • Overview
    • In memory inventories
    • Serialization
      • dirstate
      • xml
    • Serialization scaling and future designs
      • Current situation
      • Long term work
      • Layering
      • Design elements to achieve the goals in a future inventory implementation
    • Hash bucket based inventories
      • Overview
      • Goal satisfaction
      • Issues
      • Canonical form
      • Apply
      • Delta
    • Radix tree based inventories
      • Overview
      • Goal satisfaction
      • Issues
      • Canonical form
      • Apply
      • Delta
    • Hash Trie details
      • Insertion
    • Inventory deltas
    • Delta consistency
      • Avoiding inconsistent deltas
  • LCA Merge
    • Essential characteristics
    • Algorithm
    • LCA merge and Three-way merge
    • Exception to three-way behavior
    • Why a new name
    • Performance
  • Possible flaws
  • Acknowledgements
  • Network Protocol
    • Overview
    • Layering
      • Medium
      • Protocol
      • Request/Response processing
      • Server-side
      • Client-side
    • Protocol description
      • Version one
      • Version two
      • Version two with streamed bodies
      • Version three
        • Headers
        • Conventional requests and responses
        • Early error returns
        • Full-duplex operation
    • APIs
    • Paths
    • Requests
    • Recognised errors
  • Plugin API
    • Introduction
      • See also
    • Structure of a plugin
    • Plugin metadata before installation
      • Metadata protocol
      • Control Formats
      • Example
    • Plugin metadata after installation
      • Help and documentation
      • API version
      • Plugin version
      • Detecting whether code's being loaded as a plugin
    • Plugin performance
    • Plugin registrations
    • Publishing your plugin
  • Repositories
    • Status
    • Motivation
    • Terminology
    • Command Requirements
    • Data access patterns
      • Patterns used
    • Facilities to scale well
      • Indices
        • Index size
        • Index ordering
        • Changing our current indexes
          • Replace .kndx
      • Data
      • Moving to pack based repositories
        • Naming of files
        • Discovery of files
        • Housing files
        • Combining indices on demand
        • Merging data on push
        • Choosing compression/delta support
    • Caching and writeing of data
      • Locks
      • Write Groups
  • Repository Streams
    • Status
    • Motivation
    • Use Cases
      • Fetch operations
        • Smart server operations
      • Bundles
      • Data conversion
    • Characteristics
      • Single round trip
      • Forward-only reads
    • Serialisation
      • Weaves
      • Bundles
    • Specification
      • Requesting a stream
      • Structure of a stream
      • Consuming a stream
        • factory metadata
  • Case Insensitive File Systems
    • Handling these file-systems
    • Implementation of support for these file-systems
  • Development repository formats
    • Using development repository formats
      • Motivation
      • Format names
      • Support for upgrade and migration
      • Before converting to a development format
      • Creating a new development format branch
      • Creating a new development format repository
      • Upgrading an existing branch or repository to development
      • Starting a new development format branch from one in an older format
      • Develoment formats for bzr-svn users
      • Reporting problems
    • Technical notes
      • When to create a new development format
      • How to create a new development format
    • Format Details
      • development
      • development-rich-root
      • development-subtree
      • Development6RichRoot[Subtree]
  • KnitPack repository format
    • Using KnitPack repositories
      • Motivation
      • Preparation
      • Creating a new knitpack branch
      • Creating a new knitpack repository
      • Upgrading an existing branch or repository to knitpack format
      • Starting a new knitpack branch from one in an older format
      • Testing packs for bzr-svn users
      • Reporting problems
    • Technical notes
• Implementation notes
  • BTree Index Prefetch
    • Rationale
      • Example
    • BTree Structure
      • Example 1 layer
      • Example 2 layer
      • Example 3 layer
      • Current Info
    • Data and Request
    • Thoughts on expansion
    • Algorithm
  • Computing last_modified values
    • Introduction
    • Definition
    • Generation in commit
    • Generation during conversion
    • Avoiding last_modified
    • Compared to annotate
    • Use cases
    • Cases to test
    • Performance considerations
    • Open questions
      • Possible structure
  • Content Filtering
    • Filters
    • Conventions
    • Dirstate interactions
    • User interface
    • Performance considerations
    • Future ideas and open issues
    • See also
  • LCA Tree Merging
    • Scalars
      • Definition
      • Resolution Algorithm
      • InventoryEntry.revision
• Miscellaneous notes
  • Dirstate
  • "bzr update" performance analysis
  • No new revisions
  • No local changes, only new revisions
  • out of date heavyweight checkout, out of date w/master

next page

Get in touch

Submit feedback about this site to:

• [email protected]