~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/scalability.txt

  • Committer: Robert Collins
  • Date: 2005-10-29 23:48:45 UTC
  • Revision ID: robertc@robertcollins.net-20051029234845-7ae4e7d118bdd3ed
Implement a 'bzr push' command, with saved locations; update diff to return 1.

    * 'bzr diff' now returns 1 when there are changes in the working 
      tree.

    * 'bzr push' now exists and can push changes to a remote location. 
      This uses the transport infrastructure, and can store the remote
      location in the ~/.bazaar/branches.conf configuration file.

    * WorkingTree.pull has been split across Branch and WorkingTree,
      to allow Branch only pulls.

    * commands.display_command now returns the result of the decorated 
      function.

    * LocationConfig now has a set_user_option(key, value) call to save
      a setting in its matching location section (a new one is created
      if needed).

    * Branch has two new methods, get_push_location and set_push_location
      to respectively, get and set the push location.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
***********
 
2
Scalability
 
3
***********
 
4
 
 
5
bzr needs to scale up very well: projects with tens of thousands of
 
6
commits, tens of thousands of files, and tens of thousands of
 
7
branches.
 
8
 
 
9
We are concerned with both the big-O performance of the design, and
 
10
the multiplicative factors of the implementation.  Both is important.
 
11
 
 
12
For example, darcs, svn and arch use more than one inode per working
 
13
file (pristine, id file, etc).  This is only a constant factor, but
 
14
enough to more than double the space used by a typical tree.  We would
 
15
like to avoid it if we can.
 
16
 
 
17
From a early stage in development the features which do work should be
 
18
tested on large trees.
 
19
 
 
20