Re: [Monotone-devel] Re: Best practice using monotone

[Andy Jones]

Entirely at right angles to it, I'm afraid.  But if it's not best practice to use it, I suppose that's all I need to know.

I couldn't say whether the current model was a good one or not.  The testresult thing seems useful but not to me - in the language I use, the only thing you could do with it would be to check that the programs compiled, and any developer that didn't do that before a commit should be given a Good Talking To.

It still seems to me that you could use "approve" to make sticky checkouts, with a little work.  You'd need a wrapper script to mtn that called it with a special monotonerc, and a different signature for each "sticky state".  In the long run that might be easier than arranging for each release currently "out there" to be on the head of some branch.    But again, I'm not a typical case.  For me it is useful to have a working area in a given place that is welded to a given release, rather than just summoning it as needed via mtn co -r.

I'm on holiday next week, but I'm going to see if I can write all this up into something that makes sense.  If I can get it into good enough English, would you folks like me to post it on the Wiki?

Andy.

On 24/08/06, Bruce Stephens <address@hidden> wrote:

"Andy Jones" <address@hidden> writes:

> Okay, only one more dumb question that I can think of:  is there a doc
> somewhere that explains how the trust / quality assurance model works?

Just the manual, I think.

And I don't think anyone really believes what's there works
particularly well (in the sense of being what's actually wanted).
(Well, spot the lack of testsuite certs in nvm.)

There are some easy things that you can do: if you have a branch that
you want to regard as personal, then you can configure
get_revision_cert_trust to ignore branch certs not signed by you.
(Similarly if you want some branch to be signed by someone else.)

I think what's there was always intended to be replaced when someone
understood better how it ought to be done.

I believe the current thinking is to use special branches, and
these'll provide versioned policy, and all kinds of fancy things.
However, it all seems a bit vague to me.

<http://venge.net/monotone/wiki/VersionedPolicy> describes something,
but I suspect it's mostly orthogonal to what you're asking; it
concentrates on the versioning without mentioning too much on the
stuff that's being versioned.

[...]



_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel