looms: compatibility, performance, alternatives?

[David Reitter]

For the past 4 years or so, I've been working on a  project that sits  
downstream for a bigger one.   I'm considering moving my project to  
Bazaar (from CVS), as will the upstream project.  I would like my  
changes to be organized so that they can easily be propagated  
upstream.   Thus, I'd like to track several threads of development  
(patchsets) in order to be able to push upstream (or see pulled) some  
of the changes.  For example, our stack of patches may look like this  
(in reality we have some 30 separate patches):

1 - proj-specific / downstream
2 - patch-C
3 - patch-B
4 - patch-A
5 - upstream

I understand that the bzr-loom plugin is the right thing to use.  I  
have a few beginner's questions:

- Suppose a fellow developer does not have the bzr-loom plugin  
installed.  When they get the branch, do they get all patches by  
default? Which thread are their commits assigned to?  Can I configure  
this?  I would want them to commit to the top thread (downstream,  
level 1).

- Does using the bzr-loom plugin have negative performance  
consequences, particularly on common operations such as branching/ 
checking out, committing, pushing, merging, and "bzr log"?

- Suppose the upstream project does not use bzr-looms: I presume I can  
still merge from it and push single threads to it without problems.   
Correct?

- What are the alternatives to using loom?
   Note that it is a requirement for us to be able to provide simple  
access to the complete project code, that is, at level 1.

Thanks for your help!
- David


--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2193 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090108/e8ac26a4/attachment.bin