On Tue, Oct 25, 2005 at 07:53:23PM +0200, Wim Oudshoorn wrote: > Emile Snyder <[EMAIL PROTECTED]> 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. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel