monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Thoughts about 'testresult'...


From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] Thoughts about 'testresult'...
Date: Thu, 21 Apr 2005 18:12:59 +0200 (CEST)

In message <address@hidden> on 21 Apr 2005 08:55:04 -0700, Emile Snyder 
<address@hidden> said:

esnyder> I see, you would also like to either remove the
esnyder> accept_testresult_change() hook call, or redefine the default
esnyder> to 'return true'?

I forgot to mention that.  Yes, I want to throw away that hook.  When
asking users to explicitely ask for true testresults, the hook is not
interesting any more, at least from my perspective.

esnyder> The other thing that seems a little funny to me is that I'm
esnyder> used to thinking of selectors as handy ways to try to pick a
esnyder> single revision; it complains if it finds lots if I do
esnyder> 'monotone update a:richard' because there's lots of such
esnyder> revisions, and 'monotone update REV' takes one.

Well, I'm seeing this selector as being a little more selective than
the others, maybe.  Internally, it could retrieve all revisions, and
then do some kind of purge with the criterion that any revision that's
an ancestor to another are removed from the retrieved set.  The result
is the set of revisions that can be seen as "the latest true
testresults signed by the given key".  You may very well get more than
one revision, for example in teh following case:

    |
    A
   / \
  B*  C        * = testresult=1 signed by address@hidden
  |   |
  D   E*

r:address@hidden would then result in the set of revision ids for
nodes B and E.

esnyder> Do we have other commands where we use selectors in the way
esnyder> you've proposed for r:?

You might want to make a diff between, say, monotone 0.18 and the
latest revision that I've marked:

  monotone diff -r t:monotone-0.18 -r r:address@hidden

I'd say your imagination is your limit.

esnyder> Out of curiosity, is there an argument against having the
esnyder> general case flag, --cert=certname:certvalue that behaves
esnyder> like --branch: restricting the considered graph to revisions
esnyder> that have the given cert with the given value?

  c:certname=certvalue

The question is, should we take ALL revisions with that condition, or
just the latest?  Maybe we need to look over the selector syntax a bit
to support different desires.  After all. nothing stops me from
setting the tag 'foo' on several revisions (or?), and to want only the
latest revision with that tag later on (with the same criterion for
"latest" as I have for testresults above)...

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis




reply via email to

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