[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Meta-policy proposal
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] Meta-policy proposal |
Date: |
Mon, 11 Sep 2006 20:52:52 -0700 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Mon, Sep 11, 2006 at 03:59:08PM -0700, Rob Schoening wrote:
> Does monotone have a concept of a "project"? I didn't think it did, other
> than by convention.
>
> I'm not necessarily saying that it should, but since a lot of this
> use-case discussion revolves around authorization issues in the lifecycle
> of a project, it does beg the question somewhat.
Some of the things we've experienced that make us think adding a
"project" concept is a good idea:
-- Shared trust rules require some sort of "group of branches" unit
(the current discussion).
-- In 99% of cases, you want "a project" to be the unit you sync on.
In current usage, people treat "net.venge.monotone*" in this
manner. (Obviously it's useful to be able to sync only a subset
of a project too, but that should be something you have to ask
for explicitly; this is a case where there should be a default.)
-- In 99% of cases, you want "a project" to be what you store in a
particular db.
-- If we move away from having everything given globally unique
names (branches, key names, even tags...), then we need some sort
of "namespace" concept, that a group of collaborators can use to
achieve a shared vocabulary. Experience says that we really
should move away from globally unique names.
-- Higher-level process is all about relationships between branches.
If you want to talk about "has this been merged back", "what
branches are waiting review", etc., then you need something like
a project scope.
-- It matches how social groups organize around software
development, and how people think and talk about software
development. For example, in speech practice, projects all get
short names ("gcc", "monotone", ...) that refer a particular
unified group of developers with some shared process.
-- Nathaniel
--
"If you can explain how you do something, then you're very very bad at it."
-- John Hopfield