[RFC] use cases for 'projects'...

Jelmer Vernooij jelmer at samba.org
Mon Nov 5 14:12:31 GMT 2007


Am Dienstag, den 06.11.2007, 00:46 +1100 schrieb Robert Collins:
> Jelmer writes in his blog:
> 
>       * Tags should ideally be shared amongst a set of related branches.
>         This has come up often during discussions about where tags
>         belong.
>       * Management of sets of bzr branches is hard
>               * It seems to make sense for the configuration of several
>                 plugins to be project-specific:
>                       * bzr-pqm-submit's pqm address
>                       * bzr-email target address
>                       * bzr-cia's project setting
>                       * ...
>               * may be useful to override whoami
>               * having a way to group branches allows mass-pushes/pulls
>       * I often find that the public_location I set is almost the same
>         for related branches, with only the last part of the url
>         differing and containing the branch nick
>       * It would be nice if "bzr register-branch" could automatically
>         determine what product to register as
> 
> I don't think a 'project' concept addresses this because at least for
> me, groups of branches to push/pull are more often coupled by what I'm
> working on not by what project that comes from - e.g. it might be a
> couple of bzr branches and two or three plugin branches.
It depends on how you define "project" really. "bazaar" could be a project, and all of 
the different Bazaar branches could be part of that. That saves you the
trouble from setting up mail notifications / cia for each and every bzr
plugin. Same goes for push/pull, as you mention. OTOH, defining a
project as branches with common ancestry has the advantage that you can
potentially use the root id (when != "TREE_ROOT") to determine two
branches are part of the same project. 

Maybe we need both "products" (branches with common ancestry, e.g.
"bzr", "bzr-email" or "bzr-svn") /and/ "projects" (sets of products,
e.g. "Bazaar"). That, however, makes the Bazaar model more complex than
it's worth. 

> However, perhaps thats too specialised.
> 
> Here are some use cases that I run into:
> 
>       * bzr commit-notify would be nicer if it could filter on project.
>         e.g. 'I am interested in only bzr commits'.
>       * the hypothetical bzr irc-notify would be nice, one reason I
>         haven't written it yet is filtering and performance - it would
>         be nice to be config-free - that is to connect to one known irc
>         channel, to send enough data to that channel on each commit that
>         not every bzr client in the world suddenly DOS's the target url;
>         rather interested clients should be able to determine *some*
>         degree of interest without connecting to the server; or only
>         downloading a couple of tiny files.
> 
> Some discussion - we can filter already on e.g. URL's - but this works
> only so-so when one is doing local-area notifications as the url is
> often just bzr://hostname/basename.
Settings like this should be carried around when you move branches (or
sets of them). Locations.conf tends to get very long, making it hard to
find what you're looking for. 

> I don't think working with groups of branches is really a 'project'
> object - but working with groups of branches today should be
> straightforward if someone extends our url lookup logic to understand
> something like URL;tag=foo or URL#tag=foo.
What exactly do you mean? Do you mean tags in their VCS meaning or in
their "Web 2.0" meaning? Also, I don't see how this would solve the
push/pull-multiple-branches-at-once problem. 

Cheers,

Jelmer
-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
Jabber: jelmer at jabber.fsfe.org



More information about the bazaar mailing list