Re: [Monotone-devel] monotone disapprove does not give correct branch cert

[Nathaniel Smith]

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.