Questions regarding large projects
Iwan Vosloo
iv at lantic.net
Tue Feb 21 15:33:55 GMT 2006
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?
2) The other question is regarding the "correct" usage of branches...
Say you have a main repository on the web which you use to
coordinate and distribute your code. Developers create local
branches, on remote machines. (A star-topology.)
a) I suppose that http access is fine for giving read-only access,
b) and that the you can give sftp (or similar) access to the
developers you want allow to merge their stuff back into the main
archive.
(I'm assuming in the below that branches kind-of work like in
arch:)
c) How do you think branch numbering should work here: using
arch, one scheme is to create an 0.1 branch on the main server, and
also, (say) an 0.1.1 branch. Then developers can check out a
version of 0.1.1 and contribute their changes back to the main
server's 0.1.1 branch. Say it's been decided to stop work on 0.1.1,
you somehow freeze that branch and merge it into 0.1 (on the main
repository). You also create the 0.1.2 branch from the new 0.1
version where you start working on version 0.1.2, etc.
In other words, each x.x.x branch represents where developers are
currently working towards the x.x.x version of the project. When
that version is released, you create a new branch for the new
version you'll be working towards. Bugfixes to older versions of
the project can still be appended to their (largely inactive) old
branches.
-i
More information about the bazaar
mailing list