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

[Markus Schiltknecht]

Hi,

Stephen Leake wrote:
> 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.

There's already a warning in place, which pops up if untrusted revisions 
could be used, but aren't because they're not trusted. IMO that's 
sufficient (since it's just fighting misconfiguration) and covers all cases.

A direct error message and failure on sync isn't always possible, 
because Abe and Beth could be syncing via Chuck, who trusts Abe. In that 
case, Abe can push his revision to Chuck. But Beth certainly shouldn't 
get a permission error when pulling from there (because there might be 
other trusted revisions he wants to pull). This isn't completely 
solvable with direct error messages, 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
> commits?

That doesn't really make much sense to me. How can Abe not trust 
himself? He's the boss on his machine, so he can certainly make monotone 
use his revisions on his machine. Again I think a warning, that the 
general policy distrusts his newly committed revision should be enough.

Abe can then either ask the project to trust him and sync later on. Or 
just accept that the project distrusts him and maybe fork? Whatever, we 
can't completely preventing Abe from committing, so why prevent it at all?

Regards

Markus