Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments


If we had a bzrd, which was resident all the time and to which bzr could talk, it would be possible for that daemon to use inotify to know exactly which new files were created, and which files had been modified, in a tree. This may speed up the time to establish status in a large tree substantially.

All vcses that are performant on huge trees provide a way for the vcs to be notified of filesystem changes, instead of scanning for them. If bzr provided a facility like 'bk edit', then such a daemon could be one client. (Traditionally, people have configured their editors to run vcs commands, and some might prefer that over running bzrd.)

At the moment, it takes some time to establish which of the files in a tree have been touched or created since the last commit. The inotify approach means that it will scale with the number of changes made, not the number of files present. However, it's worth noting that the majority of the time it takes to run 'status' is spent in user code, not system calls, so there is still room for improving total time in bzr.


On large trees, there is a defined and unavoidable time required to check each file to see if it needs to be examined for changes. Bzr does a good job of cacheing that information and optimising the search process. But this still scales linearly with the number of files under revision control.

The Linux kernel provides a facility for applications to request notification when files and directories are created or modified. This is used, for example, to make sure that icons pop up on your desktop when you copy a file into ~/Desktop/ in Ubuntu. Other operating systems have similar facilities.

In future, it would be worth considering if the bzr process could fire up a long-running resident daemon when used for the first time, which could monitor the trees under active work. This daemon could be smart about the way it uses resources, going away if it is basically unused for a period of time. But while resident, it would be able to request such notification, and then bzr could ask it "what files are new or changed in this tree" in a very efficient manner, that would scale linearly with the number of files created or changed rather than the number of files under revision control.

Further Details

This is Futurology, of course, because we don't have a bzrd today which could house that functionality, and there is a lot to be considered before we start work on one.

For example:

  • would this actually be an efficient use of resources in the typical case? The launchpad tree has several hundred directories, and a Linux kernel tree has several thousand. I don't know what resources would be consumed by a bzrd that was asking for notification across the whole tree.


Use Cases

It is important that the description section covers the functionality-related aspects (the "what") of the change. Providing rationale (the "why") is always a plus.


This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Schema Changes

Data Migration


This section should house the larger issues that need discussing; you can sprinkle XXXs around the page if you want to keep the smaller open issues in context.

Unresolved Issues

Questions and Answers