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

Robert Collins robertc at robertcollins.net
Tue Nov 6 03:45:58 GMT 2007


On Mon, 2007-11-05 at 15:12 +0100, Jelmer Vernooij wrote:

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

It's a challenge to balance alright.

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

I mean in the bzr implementation: if you can address a tag within a
branch as a 'branch', using the config from the branch, you effectively
get git's behaviour with almost no effort.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20071106/b27e8af2/attachment.pgp 


More information about the bazaar mailing list