Guidance on working with a multi-level project in bzr

[Alexander Belchenko]

Patrick van der Velde пишет:
> Hi All
> 
> I've recently started working a project which contains multiple
> modules. The goal is to be able to work on each of these modules
> independently. In order to do so I'd like to create a separate bzr
> repository for each module, however I'm not entirely sure how to
> approach this. I know that there are several plugins that can assist
> me with this work (bzr-externals, scmproject, nested trees).

"Nested trees" is not a plugin, but unfinished bzr core feature.
bzr-externals and scmproj are plugins which trying to emulate nested trees.

> Unfortunately I'm not entirely sure what the best way is to use these
> plugins.

Both bzr-externals and scmproj are close in general idea: you define a 
project config in the some parent directory and describe your components 
(or modules): where to get them (from server) and where put them (on 
local disk). Both plugins get every component as plain branch (or 
checkout) and combine them into project on logical level.

Differences between both are: bzr-externals relies on using hooks to 
work with entire project when you run standard commands in the root of 
the project, while scmproj using set of dedicated commands to work with 
the project. If you're keen to GUI tools like TortoiseBzr or Bazaar 
Explorer then bzr-externals would be better choice. On the other hand 
scmproj has more features regarding execute some non-standard operations 
over the entire project and allows you to work with each component of 
the project (including root of the project).

> Currently my project directory structure looks like (where <D> is
> directory and <F> is file):
> <D>  design
> <D>  doc
> <D>  install
> <D>  modules
>         <D> core
>         <D> plugins
>         <D> ui
>         <D> utils
> <D>  tools
> <F> build.ps1
> 
> The module directories contain the individual module projects. Each
> module will have at least one (but possibly more, like plugins)
> directory sets like:
> 
> <D>  bin
> <D>  config
> <D>  design
> <D>  doc
> <D>  install
> <D>  lib
> <D>  resource
> <D>  src
> <D>  templates
> <D>  tools
> 
> The tools, lib and templates directories may contain elements that are
> shared between multiple modules (e.g. the binaries for a unit testing
> framework) so I would like to 'extract' those and I was thinking of
> using bzr-externals for that purpose.
> 
> Also some modules need other modules to work. e.g. the core module
> needs a version, not necessarily the latest version, of the utils
> module. I could compile the utils module and store the binaries in an
> external repository and link it though a bzr-externals reference or I
> could reference the entire project. However I'm not sure which is
> best.
> 
> Finally I would like to run a continuous integration server (Hudson)
> on both the individual sub-projects and the full version of the
> project. I suspect I'll need scmproj for this although I could well be
> wrong.
> 
> So now I'm wondering if my proposed setup (use bzr-externals for
> shared 'libraries' and maybe use scmproj for the overall projects)
> will work? Also if anybody has any suggestions / hints / tips for
> setting up a project like this from the bzr point of view then I would
> love to hear about it.

I would not recommend you to mix bzr-externals and scmproj for the same 
project, select one or another. Based on your description I'd recommend 
you to initialize project at the root of main directories, and another 
subproject in modules directory. Therefore each modules component will 
be child of modules project, and that project in turn will be component 
(subproject) of the main project.

If you have more specific questions I'll be happy to help. I'm the 
author of scmproj, but I won't say my plugin is better than 
bzr-externals. In some regards I think the latter has its own merits. I 
don't use bzr-externals for my projects but have some understanding on 
how it supposed to work.

> 
> With kind regards
> 
> Patrick
> 
>