[Monotone-devel] Re: Best practice using monotone

[Bruce Stephens]

"Andy Jones" <address@hidden> writes:

[...]

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

Well, it seems not to be used by anything in the repository on
venge.net, that I can see?  Presumably the buildbots could provide
testsuite certs for nvm fairly easily.  And they don't.

It's less easy to see whether get_revision_cert_trust might be used,
but I think most branches are asserted by only one person (different
ones in each case), so I see no indication that that's expected to be
useful.

My guess is that the testsuite functionality is more likely to be
usefully implemented than the get_revision_cert_trust.  I've not
actually tried it, though, and I have a nasty feeling it's not really
been tried by anyone in real use.

> 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 not quite sure what your intended use is.  If you want to check
out some specific revision and then never change it, then surely you
could just never do "mtn update" there.

I guess you want some subset of a branch, and in that case, yes, using
a different key to sign the branch certs that were of interest would
work (along with get_revision_cert_trust to ignore others).

Or you could just use a distinct branch name, and use that only on a
subset of the revisions (using some special key, if you like).

[...]