[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Re: Future of monotone

From: Stephen Leake
Subject: Re: [Monotone-devel] Re: Re: Future of monotone
Date: Thu, 07 Feb 2008 01:00:54 -0500
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.1 (windows-nt)

Markus Schiltknecht <address@hidden> writes:

> Hi,
> Stephen Leake wrote:
>> I don't see how to do this on a branch basis.
>> The syntax of ~/.monotone/write-permission only allows specifying
>> users, not branches.
> Correct, sorry for the noise, I mixed things up.
>> How do I specify that abe is allowed to upload branch "foo", but not
>> any other branch?
>> I can set get_revision_cert_trust to not trust things abe has
>> uploaded, but I don't see how to prevent the upload in the first
>> place.
> Yes, you can't currently prevent abe from uploading. But having the
> correct trust hook in place, you don't really need to. 

I haven't tried this yet, but it seems to me it could be confusing. I
can just imagine a conversation between Beth and Abe:

Abe: I checked in a change that fixes that bug.

Beth: But it doesn't show up! What file is it in?

much, much later:

Beth: Oh! I have you listed as untrusted on that branch!

With per-branch write permissions, Abe gets a permission error on
checkin or sync, and the situation is much clearer.

> The problem is, every developer in your company will then need these
> trust hooks. This is (part of) the problem, policy branches should
> solve, IMO.


I hope if Abe is listed as not trusted for some branch in his own
get_revision_cert_trust or policy, any attempt on his part to commit
to that branch would be an error? Otherwise he won't see his own

On the other hand, we can use per-database write permissions. That's
how I have CVS setup at the moment. But when using monotone, there is
pressure to having everything in one database, to reduce the number of
sync steps.

> I'm currently thinking about if and how we can solve the trust problem
> in nuskool netsync. That's probably why I've confused things. 

Ah, that makes sense.

> Sorry again.

No problem.

-- Stephe

reply via email to

[Prev in Thread] Current Thread [Next in Thread]