On Sun, Feb 12, 2006 at 07:47:36AM +0100, Richard Levitte - VMS Whacker wrote:
> Incorrect. disapprove does what you describe it should do, as
> follows, except for the merge that you have to do separately:
Oh. Er. Um. Well... oops!
I blame a flaky memory, and perhaps the fact that the only time
In message <[EMAIL PROTECTED]> on Sun, 12 Feb 2006 09:41:14 +1100, Daniel
Carosone <[EMAIL PROTECTED]> said:
dan> On Sat, Feb 11, 2006 at 03:37:01AM -0800, Justin Patrin wrote:
dan> > > Personally, I think the functionality of 'disapprove' should
dan> > > move to 'revert' ('revert -r REV [RESTRIC
On Sat, Feb 11, 2006 at 03:37:01AM -0800, Justin Patrin wrote:
> The name 'revert' of course makes sense for this, but this will also
> clash with the 'revert' used to revert a change in a working copy
How so? The current behavior is included as a special case, it just
defaults to reverting t
On 2/11/06, Daniel Carosone <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 11, 2006 at 03:37:01AM -0800, Justin Patrin wrote:
> > > Personally, I think the functionality of 'disapprove' should move to
> > > 'revert' ('revert -r REV [RESTRICTION]; commit'), and 'approve' could
> > > just go away, or stay
On Sat, Feb 11, 2006 at 03:37:01AM -0800, Justin Patrin wrote:
> > Personally, I think the functionality of 'disapprove' should move to
> > 'revert' ('revert -r REV [RESTRICTION]; commit'), and 'approve' could
> > just go away, or stay on until we have a real story, or whatever.
>
> The name 'reve
On 2/11/06, Nathaniel Smith <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 10, 2006 at 05:25:36PM +0100, Richard Levitte - VMS Whacker wrote:
> > I'm taking a look at the current revision approval possibilities, and
> > there are things I don't quite understand. Also, it looks like this
> > hasn't been
On Fri, Feb 10, 2006 at 05:25:36PM +0100, Richard Levitte - VMS Whacker wrote:
> I'm taking a look at the current revision approval possibilities, and
> there are things I don't quite understand. Also, it looks like this
> hasn't been looked at for ages.
It hasn't. It was sort of stuck in as a s
Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes:
[...]
> I did a little bit of experiment, and found out that I had
> misunderstood what the heads of a branch with a disconnected graph
> would be. That was basically my worry with this scheme.
>
> My mantra for the night: experiment a li
In message <[EMAIL PROTECTED]> on Sat, 11 Feb 2006 09:25:27 +1100, Daniel
Carosone <[EMAIL PROTECTED]> said:
dan> On Fri, Feb 10, 2006 at 10:39:02PM +0100, Richard Levitte - VMS Whacker
wrote:
dan> > Yeah, the only problem, as far as I see it, is that approve takes
dan> > --branch, so for exampl
On Fri, Feb 10, 2006 at 10:39:02PM +0100, Richard Levitte - VMS Whacker wrote:
> Yeah, the only problem, as far as I see it, is that approve takes
> --branch, so for example, I could very easily say something like:
>
> monotone approve --branch=net.venge.monotone.approved.linux \
> 6e87084a8
On Fri, 2006-02-10 at 22:39 +0100, Richard Levitte - VMS Whacker wrote:
> In message <[EMAIL PROTECTED]> on Fri, 10 Feb 2006 15:15:13 -0600, Timothy
> Brownawell <[EMAIL PROTECTED]> said:
>
> tbrownaw> On Fri, 2006-02-10 at 19:26 +0100, Richard Levitte - VMS Whacker
> wrote:
> tbrownaw> > What w
In message <[EMAIL PROTECTED]> on Fri, 10 Feb 2006 15:15:13 -0600, Timothy
Brownawell <[EMAIL PROTECTED]> said:
tbrownaw> On Fri, 2006-02-10 at 19:26 +0100, Richard Levitte - VMS Whacker
wrote:
tbrownaw> > What would be needed is perhaps have approve avoid adding
tbrownaw> > a branch cert for a
On Fri, 2006-02-10 at 19:26 +0100, Richard Levitte - VMS Whacker wrote:
> I've been rethinking. Ignore that, changing the approve command will
> not really make things better, because then we need to check that the
> value of an "approved" cert matches any available "branch" cert or the
> current
I've been rethinking. Ignore that, changing the approve command will
not really make things better, because then we need to check that the
value of an "approved" cert matches any available "branch" cert or the
current branch, and that would require something quite a bit more
complex than the curre
Hi,
I'm taking a look at the current revision approval possibilities, and
there are things I don't quite understand. Also, it looks like this
hasn't been looked at for ages.
First of all, we probably need to rewrite the example for the
get_revision_cert_trust, as it currently uses the "ancestor"
15 matches
Mail list logo
