[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