[Top][All Lists]

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

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

From: Markus Schiltknecht
Subject: Re: [Monotone-devel] Re: Re: Future of monotone
Date: Thu, 07 Feb 2008 14:42:17 +0100
User-agent: Mozilla-Thunderbird (X11/20080110)


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

Last I checked, "used" here for certain means "update". But I strongly suspect (and hope) it's pretty much the same code path for "heads" and "checkout" and "merge" as well, yes.

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.

What do you mean by "missing a warning"? A warning is a warning. If Beth disagrees with the warning, and changes his mind to trusting Abe, he will have to change his cert_trust hook.

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

You can do that by simply killing the revision from the database. IMO there's not much point in maintaining an untrusted revision together with a flag that it will never be trusted anyway...

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.

That's another option, although I dislike it somewhat, because you are sucking in the untrusted revision forever into the history of your repository.

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.

I don't quite agree here. Warnings are quite different from errors, IMO. And a UI external to monotone (you mean, build on top of monotone, right?) should use the automate interface anyway.

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.

Agreed, as long as that central policy is enforced...

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

I'd say so, yes.

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
That doesn't really make much sense to me. How can Abe not trust

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.

Uh.. I was referring to the "he won't see his own commits". That's certainly something that should never happen.

If Abe should be allowed to commit or not is certainly debatable. If we disallow it, we certainly have to add "--force" option to disregard that (non fatal) error. I'm generally not a fan of such "--force" options, because I'm assuming clever users as well as software, which can easily undo unwanted changes.

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

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

Which I'm considering pretty painful, but YMMV.

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.

See above. I'd like to be able to commit and continue working, probably commit multiple times, and only later on make sure I get permissions to upload my work. Any kind of "--force" options are just plain annoying, IMO. Or do you know of any real Unix user who hasn't hard-wired "rm -rf" in his fingers?

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.

Exactly, that's why a warning is enough. Chances are pretty high, that the user known what he's doing.

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.

In the above example, the only person who would have to worry about Abe's erroneous commit would be Abe himself. Because all the others have the correct policy in place.

Note, that the above issue about the warning is how it *currently* works. While all of this "policy" discussion is how it *should* work. Thus I'm also stating that Abe's malicious revision shouldn't be propagated via netsync, because the project's policy distrusts it. So there's no warning and nothing for Beth to worry about.

Monotone supports that use case in a simple way only at the database

That's annoying, yes. But it's the current state and not how we want it to be.

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

IMO, you are mixing things here. The warning is the best we can currently do. Policy branches don't exist, yet. Maybe I'm ready with the nuskool sync algorithm by the time policy branches are landing? Maybe not.

I certainly agree, that Beth shouldn't have to worry (not even about a warning) if Abe committed to a branch, to which he doesn't have "write access" to.

Another solution would be to extend the mtn sync command to support
multiple databases per session,

That would be pretty annoying to code, I think. It seems more doable, to respect the (local copy of the) policy and refuse to pull in untrusted revisions. (with nuskool, i.e. a DAG based refinement, that is).

Would it be difficult to extend write permissions to branches?

For me, that's one of the reasons to favor a DAG based sync algorithm. I.e. nuskool.



reply via email to

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