[Top][All Lists]

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

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

From: Andy Jones
Subject: Re: [Monotone-devel] Re: Best practice using monotone
Date: Thu, 24 Aug 2006 17:40:17 +0100

In CVS I had a permanent work area sticky on the tag "test".  As each
change was tested and passed by the QA team it got tagged.  Then all I
had to do was "cvs update" in the release area.  The unit test version
of the product ran from this working area, expected the code to be

It seems to me that the "test" tag could be a signature.

Alternatively I could just write a script that did 'mtn update -r t:test' !

(Um, that +would+ get the +latest+ revision with that tag, right?)


On 24/08/06, Bruce Stephens <address@hidden> wrote:
"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, 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

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


Monotone-devel mailing list

reply via email to

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