[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