Re: [Monotone-devel] Approval revisited...
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 I actually used this so far, it was probably to 'disapprove' something that was at least a local head already. Sorry about that. Regardless of what happens to 'disapprove', which at the very least is poorly named, revert -r does sound useful in its own right. For example, in a workspace merge, I could use it to pick files for the merge result as they were in one or the other head being merged. -- Dan. pgp7UF7OqyNgP.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
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 looked at for ages.
It hasn't. It was sort of stuck in as a statement of intention,
before anyone realized _quite_ how long it would take to get a solid
VCS foundation so we could get back to the actual _workflow_ stuff
that was the original goal...
I don't know that there's a lot of point in trying to patch this up
piecemeal; we don't have any coherent model for how review would work
right now, and fiddling with the trust hook (which is also one of
these vestigial has-been-there-forever, never-really-designed things)
doesn't seem like it will really get us there?
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 'revert' of course makes sense for this, but this will also
clash with the 'revert' used to revert a change in a working copy
The real answer is the trust branch stuff, which is actually getting
much closer now that we have rosters in and are starting to get handle
on how we can get over the speed problems we've been facing forever.
It will be nice if we can stop fighting fires for a bit... *knocks on
wood*
--
Justin Patrin
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
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 'revert' of course makes sense for this, but this will also
clash with the 'revert' used to revert a change in a working copy
This is exactly the same command. Notice the -r REV, which means to
revert the [RESTRICTION] files to as they were in REV (as opposed to
the BASE rev as default), and a commit after. Thus a revert is just
like an update that doesn't change MT/revision, so diffs and commits
are still relative to the original BASE.
This works fine if your BASE is the revision where the 'bad' change
was first made, or at least some near descendent before other changes
have been made in the relevant files too. If intervening changes have
been made, the current functionality of 'disapprove' is to apply a
reverse patch against the current head.
That's handy and convenient, but I actually think the more appropriate
way to achieve this is to actually go back up the graph and checkout
the original damaged BASE rev, revert and commit as above, and then
merge the new head with the anti-change with the current head.
The resulting graph just makes more sense: it connects the bad change
with the repair, and shows you the alternate path in between that's
affected by the bad code.
So, yes please.
--
Dan.
pgp7ojUvMs3r0.pgp
Description: PGP signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
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 [RESTRICTION]; commit'), and
dan 'approve' could just go away, or stay on until we have a real
dan story, or whatever.
dan
dan The name 'revert' of course makes sense for this, but this will
dan also clash with the 'revert' used to revert a change in a
dan working copy
dan
dan This is exactly the same command.
No.
dan Notice the -r REV, which means to revert the [RESTRICTION] files
dan to as they were in REV (as opposed to the BASE rev as default),
dan and a commit after. Thus a revert is just like an update that
dan doesn't change MT/revision, so diffs and commits are still
dan relative to the original BASE.
dan
dan This works fine if your BASE is the revision where the 'bad'
dan change was first made, or at least some near descendent before
dan other changes have been made in the relevant files too. If
dan intervening changes have been made, the current functionality of
dan 'disapprove' is to apply a reverse patch against the current
dan head.
Incorrect. disapprove does what you describe it should do, as
follows, except for the merge that you have to do separately:
dan That's handy and convenient, but I actually think the more
dan appropriate way to achieve this is to actually go back up the
dan graph and checkout the original damaged BASE rev, revert and
dan commit as above, and then merge the new head with the anti-change
dan with the current head.
dan
dan The resulting graph just makes more sense: it connects the bad
dan change with the repair, and shows you the alternate path in
dan between that's affected by the bad code.
I entirely agree with that last remark, and since that's what
disapprove does (well, except for the merge), why should we change it,
and even more, why should we mix it up with another command that does
something different altogether?
dan So, yes please.
My vote goes to no! pretty please, no!
Cheers,
Richard
-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte [EMAIL PROTECTED]
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
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
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 branch, and that would require something quite a bit more complex than the current get_revision_cert_trust hook. What would be needed is perhaps have approve avoid adding a branch cert for a branch the revision isn't already in... Um, I think that's the entire purpose of approve. It basically says, I, so-and-so, approve revision for inclusion into branch .... Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
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 branch the revision isn't already in... tbrownaw tbrownaw Um, I think that's the entire purpose of approve. It tbrownaw basically says, I, so-and-so, approve revision for tbrownaw inclusion into branch .... 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 \ 6e87084a87413eed2c31100054ff8d5045f0be4d If that gets repeated a few, do you know what kind of graph that branch (which I invented on the spot) would have? Maybe I worry too much, but consider if someone mistakenly connects the revision to another unrelated branch by using approve unwisely? I think approve should at least warn if the given branch doesn't match one of the branch certs already attached to the revision. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
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 would be needed is perhaps have approve avoid adding tbrownaw a branch cert for a branch the revision isn't already in... tbrownaw tbrownaw Um, I think that's the entire purpose of approve. It tbrownaw basically says, I, so-and-so, approve revision for tbrownaw inclusion into branch .... 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 \ 6e87084a87413eed2c31100054ff8d5045f0be4d If that gets repeated a few, do you know what kind of graph that branch (which I invented on the spot) would have? Hmm? It would have the shape of whatever part of the revision history graph got put into it. Maybe I worry too much, but consider if someone mistakenly connects the revision to another unrelated branch by using approve unwisely? Couldn't they do the same by using commit -b foo unwisely? I think approve should at least warn if the given branch doesn't match one of the branch certs already attached to the revision. Is it more often used to reiterate someone else's claim that a rev should be in a given branch, or to bless it into a special branch (release branch, maybe) that people are, by policy, not generally supposed to commit to? (Is it used often at all?) Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
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 \ 6e87084a87413eed2c31100054ff8d5045f0be4d If that gets repeated a few, do you know what kind of graph that branch (which I invented on the spot) would have? There's nothing whatsoever intrinsically wrong with a disconnected branch, so long as the users of that branch have appropriate expectations. Take a look a the BranchAnalogy page on the wiki for some more discussion, if you haven't already; that's mostly intended to explain the concept to new users, but there are some examples in the discussion that are pertinent, iirc. Here's a concrete hypothetical use case: in some slightly alternate/future monotone, when we have the ability to grant netsync write permissions by branch, we open up the public server and allow anyone to push new revisions into a branch nvm.patch-submissions. The appropriate revid, or a suitable selector for it, then gets put into bug trackers or sent to the mailing list, rather than the whole patch, which might be large. This branch will, typically, contain a whole pile of heads, many of them clustered around the revisions tagged for releases, and some others from users who follow mainline scattered in between. Some of the patches will be good. A monotone developer with suitable rights/trusts reviews one of these patches, and finds it good. They monotone approve that rev onto net.venge.monotone and monotone merge to pull the patch back in to a new head on the mainline. Furthermore, suppose several people submit slightly different patches for the same issue. Those revs can be explicit_merged, still in the submissions branch, before the discrepancies are resolved and an integrated patch proposal is approved onto mainline. If this becomes a significant amount of work, it will presumably be continued in a new development branch for the purpose. I think approve should at least warn if the given branch doesn't match one of the branch certs already attached to the revision. Well, maybe warn, but I see two primary uses for 'approve': - attest that code in some state (branch) is also appropriate for some other state (perhaps a release branch, or mainline), perhaps after code review. - reinforce an assertion already made, by adding another cert by a different signer, perhaps one more widely trusted (or perhaps for users in some branches that want multiple signers?) My issue isn't really with approve at all: it's with the way that disapprove does something entirely different. I understand why, but at the very least the name is wrong. -- Dan. pgp7dwR3KoAlu.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
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 little first, ask questions later. Well, I did a quick experiment, setting up a branch a with a few revisions (merged). Then an entirely separate branch b with one revision. Then I approved h:b onto a, and a now has two heads. So I suspect if someone wants to add approval to something in net.venge.monotone.contrib.monotree and their cat steps on enter at the wrong moment: monotone approve ... --branch=net.venge.monotone then net.venge.monotone gets an unwanted head. That's probably not an enormous issue: nothing will update to it, for example. Doesn't it make net.venge.monotone unmerged, though, and mess up propagate and stuff? And if you try and recover by updating to a proper revision in net.venge.monotone, then monotone automate selector h:net.venge.monotone.contrib.monotree MT/revision; monotone commit; monotone merge, or something, then anyone wanting to pull just nvm gets bits of monotree, don't they (because those are now ancestors of nvm, even though they have no actual input to it)? Shouldn't we have a way to kill individual certs locally? (I mean a proper one, not involving db execute!) [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
