Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments


If you want more information on a topic and/or are able to help make it happen, contact the people below.




Shallow branches


IDE Integration


SzilveszterFarkas, GuillermoGonzalez, IanClatworthy, JavierDerderian

Performance - network & local


AndrewBennetts, JohnArbashMeinel

Too many formats



Too many bugs


JamesWestby , MartinAlbisetti

Windows support



Line endings


RobertCollins, AaronBentley, WoutervanHeyst, JelmerVernooij

Nested trees/externals


WouterVanHeyst, JohnArbashMeinel






Branch groups


RobertCollins, IanClatworthy, DanielWatkins, JelmerVernooij




Better web browsing/loggerhead


MichaelHudson, GuillermoGonzalez

Sexy desktop integration


SzilveszterFarkas, JelmerVernooij

Content specific merge/diff


AaronBentley, JelmerVernooij

Startup time



Plugins & packaging


JamesWestby, MartinPool, SzilveszterFarkas

Signature Checking


Filtered Views










MatthewRevell, MartinAlbisetti


Network Performance

  • HTTP is faster in some places
    • HPSS overhead
    • smart client code
  • graph walking tuning, push-graph
  • push stream
  • tree construction
  • DeltaFormat

  • Init

Adoption Barriers

  • Integration
    • TortoiseBzr, Xcode, Eclipse, Textmate, Netbeans, KDevelop, Apl? (cross-language)

  • Already using foo
  • Decentralised mindset
  • Documentation overwhelming
  • Ease of setting up tools
    • loggerhead/hpss
  • Being able to run loggerhead without running as separate daemon
  • Line-endings
  • Id tag expansion
  • Nested trees/CM/externals
  • Subtree checkouts
  • Cherrypicking
  • Partial merge (some files only)
  • Hooks (easy/shell?)
  • Network speed
  • Startup time
  • bzr-svn too slow
  • Signature checking
  • WT oslocks
  • Administration
  • Codehosting too slow
    • no shared repos
    • implementation problems
  • Package availability
    • easy install hates us
    • Redhat
    • SuSE
    • Mac
    • two roads for Windows
  • Uninstall
  • Whole-environment install
  • Git-style branching
  • File copies
  • Too many formats in play
  • Too many models
  • Poor UI for formats
  • Shallow branches
  • Per-file merge-algorithms


  • slow


  • Administration
    • hooks
    • backups
    • Access Control
    • logging


  • 3 way issues


  • docs
  • central workflow
  • consistent config
  • ACL
  • logging
  • web serving
  • branch viewing


  • wrong model
  • memory hog
  • --fixes


  • polish

Subtree checkouts

  • resource tuning
  • ACLs
  • branches
  • workflow familiarity


  • missing commands
    • bind/unbind
    • merge
    • branch preferences + info + stats + reconcile button + upgrade
    • create repository (?)
    • export
    • revert
  • NautilusBzr / ThunarBzr

  • tree preview widget
  • commit sign checkbox
  • register diff file handler
  • viz signature checking
  • external difftool integration
  • shelve GUI

IDEs + XML Output

IDE Integration team

  • Support IDE integration developers
  • Support IDE integration users
  • Bridge with IDE developers (packaging, releases)
  • Follow on the IDE integration in general (download page)

Technical roadmap

  • Separated XML commands integrated in the core
  • XML/RPC Server backend (performance) (versioning on the protocol)
  • IDE Integration manual/IDE developers guide


  • Follow up and push for per-IDE guide and documentation
  • XML commands, scheme, dtd, differences between server and command line

Wishlist: Vim integration



  • access logs
    • who, bzr version, what action, what branch
  • ACLs
    • what granularity
    • multiple products, or multiple branches per product
    • limits within tree
    • are ACLs versioned? time based?
    • hooks?
  • removing all VFS access
    • push, init
    • deny updating files
  • garbage-collecting branches
  • upgrading formats
    • resource intensive
    • mass upgrades
  • light-weight Bazaar service
    • processes => big memory (-> testing & profiling bzr memory performance)

    • worker pool?
  • setting up a central Bazaar server
    • Bazaar itself good
    • web-based browsing
      • docs that are simple
      • recommended tools
  • server-side hooks
    • pre-checks (for QA)
    • post-checks (for announcement)
  • template plugin for helping central policies
    • be used/enforced client-side
  • backups
    • documenting gap between central & distributed

    • how to do while repo in use
    • how to restore
      • locking
      • does restoring dd repo make sense?
  • PQM
    • hard to set up
    • needs polish
    • explaining concept
    • explaining how to customise
    • consequences
      • isolation errors
      • bottlenecks
  • integrating with other related tools
    • continuous integration
    • bug tracker
  • initial migration
  • legacy VCS -> bzr sync

  • bzr -> bzr sync/mirroring

    • hot backups?
  • troubleshooting
    • "What do I do if $KIND become corrupted?"
    • recovery tool?
    • tool for dumping without full data
  • disk space management
  • FS advice
  • admin impact of plugins
    • rollout
  • availability


  • looms tute
  • ToC for admin guide
  • IDE hackers guide
  • review built-in help
    • ongoing
  • platform tips in user guide
  • shelf in best practices
  • plugins (standard) in User Ref
  • large projects usage

Per-file-merge algorithms

file-specific merge algorithms:

  • use cases:
    • NEWS
    • C-specific: e.g. function renames, indentation changing
    • Python: Imports conflicting
    • documents

How to hook in?

  • New merge algorithm with custom merge support
  • Make all merge algorithms check for custom per-file merge

What interface should be provided?

  • 3 way merge
  • What about criss-crosses?
    • defer to plugin author
    • allow user to override per-file merge algorithm explicitly
  • if there's a per-file merge algorithm, always use it to avoid surprise

Automatically detect that a customly merged file's conflicts have been resolved?

Sexy Desktop Integration

  • not for developers
  • fix NautilusBzr

    • rename, delete, new files
    • no performance overhead when no bzr branches -> install by default

    • browse previous revisions in Nautilus
  • seamless collaboration over the network (aka Sexy Network Integration)
    • Avahi ("share this directory")
      • too hard to set up?
      • nobody is using it?
    • Jabber (share/discover branches)
    • find related branches on the network
  • branch preferences dialog
  • BzrBoy

    • Tomboy integration (versioning + syncing)
    • ~ bzr "Time Machine"
  • versioned Gobby
    • some sort of collaborative editing
  • email client integration for merge requests
  • browser integration
    • handle bzr:// URLs
    • KIOSlaves
  • NautilusBzr most important


  • hooks in shell
  • more hooks
  • server side hooks
  • issues with Ian's patch
    • discussion about using branch-specific attributes for hooks or a singleton
    • configuration via files or directories
    • levels:
      • all branches on this pc
      • just this branch
      • pattern?
  • shell hooks for all hooks?

Line Endings

  • trivial changes resulting in entire file diffs. Hard to read, blows up repository size, invalidates sha1 caching in dirstate.
  • file writes to go through tree API, as reads do now.
    • infrastructure to transform content, write native endings to working tree, convert to canonical text file representation on commit
      • could also do things like keyword expansion
      • some way to control this behaviour, for example ignore style regexes to determine what files to do it for
    • Test that every command goes through the tree api by having a tree implementation that horribly mangles everything.
    • native in working tree not always the right thing to do



  • high resolution record of actions
    • log -> annotate -> merge

  • four types of specification
    • files
      • all, some (only/not)
    • time
      • all, some revisions



some revs



bzr merge

bzr merge -r x..y



  1. record data
    • x-merge-files: set of fileids
    • x-merge-revs: set of revids
  2. merge & revert to maintain list


  • Needs a seperate deamon by default, having it optional is a feature
  • hard to set up (save defaults)
  • KID
  • TurboGears

  • Fugly! Make it skinnable
  • Slow/Unstable/Hungry
  • Could dp way more to exploit meld
  • Easy branch comparison
  • Who wrote the code, where and get me the log message! (Fast, easy, 1-click)
  • WSGI
  • Has to have an Apache drop in
  • Web server shipped with the core
  • 3 different options: Full blown python server, easy python web drop in, commercial hosting solution (doesn't need to be python)

Too Many Formats

  • Need to get at least a rich-root format to be recommended as the default so that we can reduce the total number of formats we have to support with each release.
  • Also provide a default format which supports what bzr-svn needs.
  • Migration Path
    • rich-root-pack doesn't properly match up Revision.inventory_sha1 => sha(serialized(inventory)) in all cases

    • Create a new format (7?) for Revision xml and assert the inventory xml that it matches
    • When upgrading, if the sha1 is for the wrong format, it should be regenerated
    • Changing the name from inventory_sha1 => inventory_validator makes it more reasonable that it may not be a sha1

    • In memory Revision objects need to know what format the validator is referencing (repository specific) (inventory_kind)
    • Any time we ".add_revision()" to a Repository, it should check if the validator is correct for this Repository format, if not, it should be regenerated.
    • This also allows bzr-svn to use a different validator, which will only generate an inventory when committing to the target repository


GPG Checking

  • Many different libraries
  • GPG 2?
  • Verification in the Core
  • Investigate python binding
  • Bulk verify signatures, Performance issues?
  • Specify what signing a commit means
  • Verification scaling with tree size. How can this avoid this? Change what testaments contain? Chaining? Signing Inventory Deltas?
  • Allow multiple testament format?
  • Two different use cases: "Verify one commit" and "Verify tree state and history"
  • Signature failure: No signature present, bad signature, good signature, good signature that we don't trust, good and trusted
  • Consequences of verification failure
  • Document properly what you sign (currently, the tree state)
  • Branch configuration should propagate (project requirement, only for new branches)

Too many bugs

currently 1700 reported, 700 closed

bug tracker poor tool for this? mix of actual bugs vs rfes vs enhancements

why do this?

  • user pain
  • being responsive is good
  • having many open bugs looks good
  • unfixed bugs are a distraction
  • less confidence in whether things are actually working in the code

different categories of bugs

highest priority

  • data corruption - considered critical
  • user experience

makes it less clear what to do next -

filing bugs just so as not to forget the point

some bad bugs:

  • "X sucks"
  • "we should do xxx"

triage 5 a day?

  • at least giving feedback to the user is good
  • but spending too long on low-priority bugs is poor

1. what do we want to do?

2. is our process and tools helping us get there?

some bugs are fixed and not closed marking them fix released is annoying RM should check for fix committed bugs and make them released randomly elevating lower-priority bugs

how to get people into fixing it? give a hint on the bug?

bug day

  • encourage others to fix particular bugs
  • be on IRC
  • help reassess priority


  • few New bugs - at least say thankyou
  • guide for reviewers - explain how to add tests - ask to write to you personal
  • one bug day per release
  • some more todo comments rather than bugs for internal changes

launchpad feedback:

  • Fix committed -> Fixed released (automatic, unclear? marking)

  • Tas on same page as status, etc (preset?)
  • bug dependencies/relationships (bidirection links from text)
  • Next/Previous links
  • Keyboard shortcuts
  • Splitting bugs easily
  • Interleave status changes with comments
  • FASTER PLEASE (mainly on edge)
  • More obvious that you've done something

bad bugs:

  • very open-ended bugs
  • notes to self
  • refactorings
  • half-fixed bugs, left unclosed

Windows support

Root causes of issues:

  • As a rule, we're not Windows hackers: we are not them and vice versa
  • We need more severe consequences if and when Windows support regresses
  • Too many tests don't pass.

Top complaints:

  • GUI support
  • case insensitivity issues
  • line endings
  • docs have a Unix flavour - better but needs diligence to ensure neutrality
  • locking still an issue?

What can we do to appeal more?

  • IronPython port - appeal to the .net crowd

  • visual studio integration
  • msi installer
  • chm help
  • docs to cover loggerhead/webserve under IIS
  • bzr-svn on Windows needs to rock

Other ideas:

  • wine testing - some-one to experiment with and document how on our wiki
  • plugin buildbot testing to confirm works on Windows & Mac

  • more cross-platform plugin testing in general
  • better bialix connectivity would help (Canonical sponsor?)



  • Import gettext module, research performance implications

  • Can't use underscore
  • Output strings need to be specified as translatable
  • Incentive people to translate documentation (add last updated file)
  • Per file migration, Martin and Silvester
  • Other DVCS aren't translatable

    • I'm not sure what do you mean. Hg has very long basic support for i18n. But actually don't use it. --Alexander


  • attributing work
  • multi-line commit messages
  • unicode commit messages
  • revision-id merge, rather than a branch
  • email sucks for RPC
    • XMLRPC
    • local submission
  • server setup
    • packaging
  • client setup
    • packaging
  • docs in general
  • remove crufty VCS abstraction from implementation
  • non-ass web
    • templating
    • CSS
  • queue manipulation
  • web auth
  • Launchpad
    • not a direct replacement
  • faster validity feedback
  • better support for build farms (Buildbot integration)
  • result tracking
    • stats
    • intermittent failures in tests
  • publishing failures
  • better segfault management


  • Start moving useful plugins into the core
  • QA on a vast amount of plugins
  • Specification to become a "recommended plugin"
  • Have a build bot that tests every day with plugins installed
  • Put a "Plugin Developer Guide" in place
  • Start generating the release tarball with a set of plugins in it

Filtered Views

  • Why? Necessary for large projects.
    • more common in commercial born projects than FOSS
  • Scope of masking
    • single directory/file
    • list of directories/files (preferred)
    • regular expressions
  • Merging tracking is the key blocker
    • need cherrypick data to support this correctly
  • Handling of new directories
  • UI work across the board: revert, diff, st, etc.
  • Keep true root or "re-root" it
    • only makes sense if single directory is the scope
  • Generalised 'view' idea might help some workflows
    • e.g. scoping the next commit