Questions regarding large projects

[John Arbash Meinel]

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

The one you want to look for is by-reference nested trees. Which means
that you have a master project, with sub-projects. Such that you can
modify and commit the sub-projects, and when you commit the master
project, it records the state of the sub-projects. So when you do a
'get' of the master project, it can re-create the sub-projects as well.
We discussed it at the last conference, and I'm pretty sure all of us
thought it would be a great idea. I don't think anyone has started
actually implementing it, but it is certainly stewing in the back of our
brains.

> 
> 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.
>   

Both of these are fine. Just as a side note, though, bzr supports mesh
topology, so you don't have to keep things in a star like you did for Arch.

>    (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

I think that flow is fine. 'bzr' doesn't make any requirements on your
namespace. Also, because bzr works with meshes, you can easily have each
developer working on their own branch, and have them merge among
eachother, eventually committing to a shared location.  That is actually
how 'bzr' itself has been developed. Lots of people have their own
branches, and then a few of the primary developers keep integration
branches (where we merge in code from other people), and then
periodically we merge eachother's integration branches. Just this week
we created a pqm, so anyone with access has the ability to merge things
into the official mainline. (The pqm allows us to do it without giving
sftp access, and forces the test suite to pass, etc).

What I did in my personal project was to create:

$project/
  dev/
    0.6/ # Shared 0.6 development location
    0.7/
  release/
    0.6.3/
  OLD/ # Old branches accumulate here
    0.5/

Right now, all of these are standalone branches, but it should work well
when we have full repositories with shared storage.
We also don't have official 'tags' yet. Though the spec has been rather
thoroughly discussed.
http://bazaar.canonical.com/BzrTagging

Which is why you have OLD, with a full branch to indicate the exact 0.5
release point. With tags, you could just make a tag in the official
branch, and then not worry about it.

At this point, you have 2 options for more branches. With standalone
branches, it is a little bit cleaner to have branches only as the
leaves, because otherwise you start to mix the working tree with the
branch location. When we have repositories without working trees,
nesting becomes much less of a problem.

So right now what I'm using is:

$project/
  dev/
    0.7/
    0.7-feature/
    0.7-feature2/

In the future, I would probably recommend:

$project/
  dev/
    0.7/ # This is a branch
      feature1/
      user1/
        feature-x/
      user2/
        feature-y/

In my head, it is nice to have the 0.7 integration branch be a shorter
path than the feature branches which are going to contribute to it.

There is also nothing stopping you from using Arch-style branches. It is
 just a naming convention.

http://machine.com/my@archive--2005/
  project--branch--0.1/
  project--branch--0.1.1/
  project_foo--feature-x--0.1.2/

bzr lets you name things however you want. I recommend the nested
design, because I think it is cleaner. But the unrolled design has the
advantage that with a simple 'ls' you can see all of the branches that
exist.

So I realize I probably gave you more information than you needed. But I
wanted to make it clear that bzr is a lot more flexible than Arch. And
you can use it to suit your workflow, rather than wrapping your workflow
around bzr.

I think we probably need to work out some semi-interactive documentation
which prompts users for how they want their workflow to be, and then
recommends a layout.

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/0004faf3/attachment.pgp