[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] monotone disapprove does not give correct branch ce
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] monotone disapprove does not give correct branch cert |
Date: |
Tue, 25 Oct 2005 13:34:06 -0700 |
User-agent: |
Mutt/1.5.9i |
On Tue, Oct 25, 2005 at 07:53:23PM +0200, Wim Oudshoorn wrote:
> Emile Snyder <address@hidden> writes:
>
> > Yuck. cert.cc:guess_branch(revision) defaults to using
> > app.branch_name() if one is set; ie. you are in a working copy.
> > There are 4 commands using guess_branch to decide how to cert a new
> > revision:
> >
> > approve
> > disapprove
> > checkout
> > commit
>
> >From these only commit and disapprove will create a new revision
> in the database. So approve and checkout should not add any branch
> certificate.
checkout doesn't create any branch certificates; it calls guess_branch
to figure out what the appropriate default branch for the working copy
should be.
"approve" is short for "add a branch certificate"; that's all it does.
So I think it should add a branch certificate :-).
> But disapprove you give an explicit revision, so in which directory
> you are should be irrelevant. AFAICT there are two more or less
Yes.
> reasonable options,
>
> disapprove REV
>
> should get:
>
> * all branch certificates from REV
> or
> * no branch certificate at all.
>
> I lean towards the second options for the following reason,
> it is not clear beforehand what the full collection of branch
> certificates of REV is. A sync can add new branch certificates
> to an existing revision.
I don't think this makes a lot of sense. Firstly, at the user level,
it's extremely confusing -- people who haven't yet internalized
monotone's model of branches are dazed and confused at the idea of a
revision that is in no branch, and we should try to not confuse such
people when we can avoid it. There's a tension, in general, where a
system should simultaneously work more-or-less-okay for people who
don't really understand it at all and are applying some unknown vague
model they got from somewhere else, and at the same time, should have
a simple, clear and consistent model for people who _do_ take the time
to figure it out...
Fortunately, I think these goals are consistent here, because at the
more abstract level, branches are all about intentions -- putting a
revision in a branch is how we say that that revision is good for that
branches purpose. 'disapprove', now, is entirely about intentions --
we don't mean "this change was bad", we always have some purpose in
mind, "this change is bad for purpose X". So disapprove revisions
should have branch certs on them.
> > I would argue that only commit should default to using the working copy
> > value if one is set. approve and disapprove both take a revision as a
> > specific argument; I can sort of see using the value of the working copy
> > branch if that given revision has no branch cert, but not the other way
> > around.
>
> No I would be against taking some arbitrary branch just because
> an explict revision argument does not have a branch certificate
> by itself.
That seems reasonable -- "refuse the temptation to guess" and all
that.
-- Nathaniel
--
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould
This email may be read aloud.