/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/scalability.txt

  • Committer: Martin Pool
  • Date: 2005-06-27 01:36:22 UTC
  • Revision ID: mbp@sourcefrog.net-20050627013622-0d56be3e3105043e
Merge from aaron:

------------------------------------------------------------
revno: 763
committer: Aaron Bentley <abentley@panoramicfeedback.com>
timestamp: Thu 2005-06-23 17:30:28 -0400
message:
  Copy files in immutable stores directly.
------------------------------------------------------------
revno: 762
committer: Aaron Bentley <abentley@panoramicfeedback.com>
timestamp: Thu 2005-06-23 16:12:33 -0400
message:
  Fixed direct call of get_url in RemoteBranch.get_revision
------------------------------------------------------------
revno: 761
committer: Aaron Bentley <abentley@panoramicfeedback.com>
timestamp: Thu 2005-06-23 12:00:31 -0400
message:
  Added prefetch support to update_revisions
------------------------------------------------------------
revno: 760
committer: Aaron Bentley <abentley@panoramicfeedback.com>
timestamp: Thu 2005-06-23 11:57:54 -0400
message:
  Added cache support to branch and pull
------------------------------------------------------------
revno: 759
committer: Aaron Bentley <abentley@panoramicfeedback.com>
timestamp: Thu 2005-06-23 11:21:37 -0400
message:
  Added find_cached_branch to branch
------------------------------------------------------------
revno: 758
committer: Aaron Bentley <abentley@panoramicfeedback.com>
timestamp: Thu 2005-06-23 11:17:10 -0400
message:
  Added CachedStore type to reduce remote downloads

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/scalability.txt
 
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