[Buildbot-devel] What should be the default functionality of multiple repositories.

[Dustin J. Mitchell]

On Fri, Feb 10, 2012 at 6:43 AM, Harry <harry at aeteurope.nl> wrote:
> I think, the option ‘codebase is set to its repository’ is the most
> intuitive solutions so installations that do not have multiple locations for
> their repositories do not need to worry about codebases, they can just use
> the repository as codebase. If schedulers are configured to handle multiple
> repositories then changes are at least grouped under their repository, in
> contrast with the first option where changes get mixed.
>
> Of course both options can be implemented by defining the callable that
> returns ‘’ or change[‘revision’] but my question is about the default
> behaviour if the configfile has no callable to determine the codebase.

I think that the most important default behavior is for the
unmodified-config, single-repository case, and in particular thinking
of how to carry this case forward.  In this case, there is only one
codebase, so it can be considered implicit -- '' makes a good name for
it, then.  Indeed, in this case there may be multiple repositories
containing that codebase -- consider, for example, if we began to
support building Buildbot from forked repositories on github.  The
codebase is still implicitly buildbot, but the repository has changed.

I don't see a lot of value to running a multi-repo configuration
without a codebase generator, so I'm not sure that the defaults are
important in that case.  If for no other reason than future-proofing
the configuration, I think users setting up a multi-repo configuration
should have to decide on codebase names up front, even if there is a
1:1 mapping of codebase names to repositories.  This will allow the
flexibility to support additional repositories in the future, change
repositories, etc.

Using '' as a default codebase also makes it easy to recognize the
backward-compatibility case of an unmodified configuration.  This is
useful for supporting things like 'branch', 'repository', etc.
properties for existing configurations, while doing away with these
properties entirely in the more complex cases where they do not make
sense.

Dustin