A few questions/potential issues in Bazaar-NG

Aaron Bentley aaron.bentley at utoronto.ca
Mon Aug 22 15:07:50 BST 2005

Hash: SHA1

Matthieu MOY wrote:
> Aaron Bentley said:

>>Centralized storage means that you only pay for the
>>first branch.  For every subsequent microbranch, you only pay for the
>>actual changes.
> Does this mean that if I branch from upstream an revision N, and then,
> later, branch from upstream at revision N+M, the second branch will be
> able to share the storage with the first one? (If so, that's great and I
> remove my 0.1%!).

Yes, that's one of the main reasons why I want centralized storage.  We
haven't got a final plan, but we do have a wiki page:


> In Bazaar, currently, I can maintain my own branch in sync with upstream,
> and microbranch from it cheaply, but I can't do that if I branch directly
> from upstream each time.

Isn't baz branch --no-cacherev enough?

>>And are you considering the
>>fact that for many projects, a complete history in weave format will be
>>smaller than a revlib entry?
> There are at least two differences betweed the weaves and the revlib: The
> revlib is local (=> fast access)

In bzr, the branch history is always stored locally.  Also, I should
point out that bzr doesn't need fast access to most files; when
calculating diffs or merges, it uses a stored hash to determine that the
file has not changed, so it only needs to retrieve files that have changed.

> and recontructible (=> no backup). For
> example, I have a 100Mb quota on my reliable-backed-up-and-archived
> webspace, but 20Gb on my local-and-not-backed-up disk.

So the recommended practice with bzr, even after central storage is
implemented, will be to keep your branch data local, and mirror it
remotely.  For people who want their commits instantly uploaded, we can
use a commit hook.

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the bazaar mailing list