Questions regarding large projects

[John A Meinel]

Matthieu Moy wrote:
> John Arbash Meinel <john at arbash-meinel.com> writes:
> 
>> Iwan Vosloo wrote:
>>> Hi there,
>>>
>>> I am working on projects that will in time become quite large, and
>>> have just switched to bazaar-ng (0.7) from GNUarch.  (So, I'm quite
>>> familiar with arch, but have only an RTFM understanding of bazaar-ng.)
>>>
>>>
>>> I have questions regarding the running of larger projects using
>>> bazaar, and thought I'd rather dump them here instead of just doing my
>>> own thing.
>>>
>>> 1) What are the thoughts out there regarding structuring a large project
>>>    managed by bazaar into smaller sub-projects?  Is the current
>>>    thinking that you'd just make each sub-project a bazaar project on
>>>    its own?
>> If you want, you can certainly do this. (Similar to Arch's configs,
>> though we don't have config as a concept).
>>
>> We eventually will support nested trees in a very nice manner:
>>
>> http://bazaar.canonical.com/NestedTreeSupport
> 
> Note that unlike Arch, bzr supports partial tree operations
> (diff/status/commit), so, performance-wise, it's not necessary to
> split the project into subprojects.
> 
> (but you may want to do this for many other reason of course)
> 

Actually, bzr commit still has to read every weave for all existing
files. It is an issue about how we handle merges. (We have to check
every weave to see if we have a new parent lineage). The proposed fix
was to make it so that after a merge the working inventory contains
information about what files were modified, so that 'bzr commit' doesn't
have to compute that information.

So performance on really large trees is a little slow.

Also, until the ignore rules are fixed, if you have a tree with a lot of
unknowns (like because the build products are in the tree), and a lot of
ignores (for the same reason), 'bzr status' performance can suffer a
lot. We have a patch in the queue which fixes this, but we want a format
bump so that we can change the implementation of 'bzr ignore'.

Oh, and the inventory weave doesn't scale very well. So until we split
that into separate weaves it is also a slow-down.

Just to say that in the short term, there are performance gains to be
had by splitting things into smaller projects. In the long-term we have
lots of solutions to the current problems, which should allow bzr to
scale better. (And all that without optimizing any loops in C yet).

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060221/1f7dd9b8/attachment.pgp