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

[Stephen Leake]

Markus Schiltknecht <address@hidden> writes:

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

"Used" here means "needed for a merge, checkout, or update"?

That works, except if there are revisions present which really should
not be trusted, Beth will get used to ignoring trust warnings, and
miss one.

Then we need a setting that says "yes, I know this revision won't be
used; don't warn me anymore".

Hmm. I guess Beth can commit a new revision that reverts the ignored
revision, and then she won't get the original warning anymore? That
makes sense.

As long as warnings are fixable in some way, I prefer treating all
warnings as errors. But that's a UI choice; as long as the UI (I mean
a UI external to monotone) has a way of detecting the problem, I'm
happy. Better would be for monotone to provide a
--treat-warnings-as-error option.

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

That won't happen in the central policy case, but we have to allow for
all reasonable cases.

In this case, Beth would get a warning if Abe's revision could be
"used" in the above sense? 

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

Because the central policy says Abe is not allowed to commit to branch
"documentation" (which is implemented as 'Abe not trusted on branch
"documentation"'), but he forgets that and tries to commit a patch on
that branch anyway.

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

Ok. 

> Abe can then either ask the project to trust him and sync later on. 

Or have someone else commit the same change, after review.

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

It's a question of having the tool support the desired policy in the
simplest way, with the most immediate error/warning messages. We have
to agree that perfect policy enforcement is not possible, but find the
right balance between user friendliness and strict enforcement.

Personally, I have never limited write permissions on a per-developer
basis. But I think that's because I've only worked on small teams;
everyone is trusted equally, and mistakes are easy to find and fix.

I have worked on teams where write and read permissions where overly
restrictive, and they definitely limit productivity when used poorly.
But that doesn't mean monotone should not provide them.

I have granted read-only access to a central CVS repository, when
there was another team that needed that, but I did _not_ want to worry
about them making mistakes.

Monotone supports that use case in a simple way only at the database
level. Since the tendency is to put all projects in one database, that
is not very useful. It is complicated to list the other team as not
trusted, and if they do commit, I have to deal with the trust
warnings, and explain to them why their patch is not in the next
release. 

CVS supports read/write permissions on a file basis, since it relies
on the OS access control. So it is easy to provide write permissions
on a project (= directory tree) basis, although not on a branch basis,
in CVS.

Another solution would be to extend the mtn sync command to support
multiple databases per session, so there is less reason to use one
database. Of course, the user can do that now via scripts. But then
you might have to split a database if a new situation requiring some
read-only access arises.

Would it be difficult to extend write permissions to branches?

-- 
-- Stephe