Re: [Monotone-devel] Re: monotone disapprove does not give correct branch cert
On Wed, Oct 26, 2005 at 08:59:27PM +0200, Wim Oudshoorn wrote: > > The only model I see now in branches is that "branch is a set of > > revisions sharing a branch certificate". I miss the single origin and > > the continuity :( > > That is just my mental model and it is working perfectly. yup. > Below I will outline my mental model of what monotone does > or should do. Keep in mind that this is JUST my mental model > and monotone might do things differently. I will still talk > as if monotone works the way I expect, so take it with > a grain of salt ;-) I'll try to add some salt from my mental model, then. Forgive me for extensive quoting, I don't want to lose your details as context. > MENTAL MODEL > > > (1) The revisions are a simple direct acyclic graph. Not > necessary connected. > > That is: > > * You have revisions, which are nodes in a graph. > A revision correspond to a collection files/directories > with a certain content. However the content > does NOT uniquely identify a revision. Yes, because the ancestor id is part of the revision, and provides the edit-graph structure. > * You have arrows between revisions. > Such that there is at most one arrow > between two revisions, and you can not > return to you'r starting point when > you walk the arrows. Yes. These arrows construct the ancestry graph, which represents the editorial history of changes. They also happen to correspond to deltas that store the actual edits made across that edge, but that's not important to this view of the model (you could store each revision in complete form and derive the diffs later instead, if you wanted). Furthermore, there are smaller per-file deltas and graphs that are usually not seen, and are also not important here. > (2) Now on these revisions you add some extra data, the > certificates. These certificates are not fundamental > for the working of monotone. Yes. A common parlance for such things is decoration, or annotation. Certificates add descriptions or attest to statements about revisions. > Now the the combination with version control for me is the following: > > (A) The branch label (or certificate) is used to group revisions together, > in some conceptual group of versions (revisions). This group > has some identity that stays the same over time. > Namely it is a version of the software product you are developing. > > Note: This label is JUST a convenience label, to make > the monotone user interface easy to use. Yes. > (B) The edges/arrows between the revisions I use to indicate that > one version/revision of the software supercedes another revision. > > so Rev 1 ---> Rev 2 > > means I think Rev 2 is better than Rev 1, that is the only thing > it does. Hm. I'm not entirely certain that even this much interpretation should be ascribed to a revision. I think all this shows is that Rev 2 was an edit made to Rev 1. Good, bad or other interpretations should be described by certificates - and all may change over time or be subjective. > One important thing I want to stress here is the fact that for > me 'branch' and 'arrow' (being better) are not related at all, they > are orthogonal properties. Certainly. > So I can easily have: > >Rev 1 > Rev 2 >branch A branch B > > And I still think Rev 2 is better than Rev 1, although the are > in different branches. Not really about the 'better' part, as above. It's just edit history.. Rev 2 might be very much worse, by many criteria. The only sense of better than really applies is "has had more work done on it", even if that work ends up being bad work. It might be the very first step of a rewrite of a subsystem, where all you've done is rip out the old (working, but a little grotty) implementation in preparation for replacing it with further work. You make statements to this effect by decorating the revisions with certs, especially branch certs. Firstly, by giving B a name that indicates its experimental nature - and secondly by *omitting* the A cert. This part you clearly have right, as below. > EXAMPLE >I decided to have my source files for version 1.2.9 of my project >XYZ grouped together under the branch name "XYZ-1.2.9" >and the source files for version 1.3.4 of my project >XYZ grouped together under the branch name "XYZ-1.3.4" A small nit, related to usage and terminology rather than to concepts. These kinds of names for project versions are usually releases, and represented by tags, rather than branches. A branch is often used to maintain a stable copy of the code for critical fixes, before and after the actual release point, and those branches are often named similarly. My only point here is that to explain these concepts very clearly you need to use names and examples that very clearly illustrate the sep
[Monotone-devel] Re: monotone disapprove does not give correct branch cert
Zbynek Winkler <[EMAIL PROTECTED]> writes: > What would be the "clear and consistent model" this time? I also like > clear and consistent models but I think this time it is not as > clear... IMHO clear and consistent model could be if each branch had > exactly one branch point (one revision in each branch would be the > *first* revision) and all revisions in the said branch would be > descendants of this revision (thus the branches would not have holes). > Oh not for me :-) > > The only model I see now in branches is that "branch is a set of > revisions sharing a branch certificate". I miss the single origin and > the continuity :( That is just my mental model and it is working perfectly. Below I will outline my mental model of what monotone does or should do. Keep in mind that this is JUST my mental model and monotone might do things differently. I will still talk as if monotone works the way I expect, so take it with a grain of salt ;-) Oh people who know monotone might skip this and jump to the end where I continue my nitpicking rant. MENTAL MODEL (1) The revisions are a simple direct acyclic graph. Not necessary connected. That is: * You have revisions, which are nodes in a graph. A revision correspond to a collection files/directories with a certain content. However the content does NOT uniquely identify a revision. * You have arrows between revisions. Such that there is at most one arrow between two revisions, and you can not return to you'r starting point when you walk the arrows. (2) Now on these revisions you add some extra data, the certificates. These certificates are not fundamental for the working of monotone. Now the the combination with version control for me is the following: (A) The branch label (or certificate) is used to group revisions together, in some conceptual group of versions (revisions). This group has some identity that stays the same over time. Namely it is a version of the software product you are developing. Note: This label is JUST a convenience label, to make the monotone user interface easy to use. (B) The edges/arrows between the revisions I use to indicate that one version/revision of the software supercedes another revision. so Rev 1 ---> Rev 2 means I think Rev 2 is better than Rev 1, that is the only thing it does. One important thing I want to stress here is the fact that for me 'branch' and 'arrow' (being better) are not related at all, they are orthogonal properties. So I can easily have: Rev 1 > Rev 2 branch A branch B And I still think Rev 2 is better than Rev 1, although the are in different branches. EXAMPLE I decided to have my source files for version 1.2.9 of my project XYZ grouped together under the branch name "XYZ-1.2.9" and the source files for version 1.3.4 of my project XYZ grouped together under the branch name "XYZ-1.3.4" Than it is is perfectly possible I have four versions of source: Rev 1 -> Rev 2 XYZ-1.2.9XYZ-1.2.9 \ \> Rev 3 Rev 4 XYZ-1.3.4 XYZ-1.3.4 With this I make the following statements: Rev 2 is better than Rev 1 Rev 3 is better than Rev 1 And I can ask monotone the following questions: - What is the best version of XYZ-1.2.9 monotone update/checkout --branch=XYZ-1.2.9 and it will answer: Rev 2 - What is the best version of XYZ-1.3.4 monotone update/checkout --branch=XYZ-1.3.4 and it will answer: Huh, don't know, could be Rev 3 or Rev 4. (actually it will complain about multiple heads) END EXAMPLE Now with grouping most people have experience, it is what we do all the time: * These files are my sources for XYZ * These files are my sources for ABC * These files are my sources for ABC with experimental feature QQ so these are prime candidate for branches. Just to reiterate, it is not needed to make them branches, however why would you want to fight the nice classification system monotone has? The more interesting question, where do you want to put arrows? As stated above, arrows just tell monotone which version you prefer. And instead of you telling monotone explicitly which version is better, monotone makes an educated guess: * If you started working on Rev 1 and after a few changes store the new version in monotone as Rev 2. Monotone knows you started with one and will assume that all your hard work was an improvement on Rev 1, you would not deliberately make it worse would you? so it will happily add an arrow: Rev 1 ---> Rev 2. * Suppose you end up in the situation that you have two revisions Rev 1 and Rev 2. And like them both, so you want to combine all the good of Rev 1 wi
[Monotone-devel] Re: monotone disapprove does not give correct branch cert
Nathaniel Smith <[EMAIL PROTECTED]> writes: [Some interesting pointer ommitted, which I will read when I am online again] > On Wed, Oct 26, 2005 at 12:34:54AM +0200, Wim Oudshoorn wrote: >> >> rev A.. XXX >> branch main >> \/ >>rev B rev C / propagate back to main >>branch fixbranch fix >> >> >> now if you try the above you don't get a nice new node rev D >> with branch certificate, you get just a branch certificate >> >> branch main >> >> added to rev C. This in itself is not bad, but very unfortantely >> monotone does not even add an edge between rev A and rev C to >> indicate that a propagate has taken place. > > Adding an edge is, of course, physically impossible. (Given current > understanding of the physics of computation.) At first I completely failed to understand why this is impossible. However it took me while to realize that this indeed meant adding an edge later. I was more aiming for the behaviour described below, which would be my ideal. The somewhat less satisfactory solution of adding an edge, which I implicitly proposed, is indeed not feasible. So the perfect behaviour for me would be that from the situation: Rev A branch main \ Rev B ---> Rev C branch fixbranch fix After giving the command monotone propagate fix main you end up with: Rev A Rev D branch main > branch main \ / Rev B > Rev C branch fix branch fix I would even go so far that I would expect Rev A --> Rev C branch mainbranch main \ / Rev B branch fix should happen. >> Suppose you want to disapprove the propagate from branch fix >> to branch main because the fix was faulty and need some more development. >> How to do this cleanly? > > I'd love to know -- this is exactly the "Rollback" case discussed on > that wiki page above. Bram and I and maybe some others on #revctrl > used to mumble about various ad-hoc solutions for this, but all I > really know about it is on that page. I can't read the references you have given. But what about disapproving a change. That is, you have to give two revisions and it tries to apply the inverse of the difference between those two revisions? So: A ---> B ---> C disapprove B-->C gives: A ---> B ---> C ---> D(content of D = content of B) \___/ now a more complicated situation: A---> B __/ C and now you can disapprove A -->B and get _ / \ A --> B --> D(content of D = content of A) / C Oh and the rationale for adding the edges: - If looking at anacestors you can ignore edges coming in from the disapprove node and end up with a very sensible graph structure. - So seem them as repair edges. program like modot or graphvis could colour the edge coming in to a disapprove in a different colour to signify that that one is disapproved. Finally disapproving the disapprove above would mean disapproving A-->D and you end up with / \ A--> B --> D -->E (content E = content B) __/ \_/ C Now all these examples are done on a simple edge, but you can extend it to arbitrary revisions, so for example monotone disapprove rev1 rev2 disapprove of all changes made between rev1 and rev2 * This will create a new node revD which, contains the same files in the same state as rev1. * revD wil be a child of rev1 and rev2 * revD will contain a certificate indiciting it disapproves of rev2 and goes back to rev1 So: rev1 ..(potential path but not needed)...> rev2 ---> RevD [rev2 is bad, \_/ rev1 is good!] Oh and when rev1 and rev2 contain different branch certificates it will ask the user. Wim Oudshoorn. P.S.: Most likely you already thought of all this in IRC So I will read up on your discussion and com back to it. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: monotone disapprove does not give correct branch cert
On Wed, Oct 26, 2005 at 12:34:54AM +0200, Wim Oudshoorn wrote: > Nathaniel Smith <[EMAIL PROTECTED]> writes: > > "approve" is short for "add a branch certificate"; that's all it does. > > So I think it should add a branch certificate :-). > > I stand corrected. I never use approve and somehow I thought > it was a shortcut for 'this revision did pass the tests'. Ah, that's a sensible misunderstanding... honestly, the "approve" and "disapprove" commands don't have the best names, the code review stuff is more of a sketch than a fully fleshed design, as yet. > > 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. > > Of course. But what do you do in the following situation: > > rev Arev Brev C > branch 1 ---> branch 3 -- disapprove --> branch(es) ??? > branch 2 branch 4 Error out and tell the user to use -b to specify a branch. Maybe list the plausible branches, too. > Also. I have the uncomfortable feeling that the disapprove should > not be on a revision, but should be on an edge instead. > AFAICT, but I haven't tried it yet, you can't disapprove of a merge, > or a propagate > > > rev A > branch 1 ->rev C--- disapprove??? > branch 1 >/ > rev B / propagate > branch 2 Disapproval for merges is a very hard problem. There was some discussion of this on IRC a few weeks ago: http://frances.vorpus.org/~njs/mt-disapprove-merge.log of which I guess Emile added some part to the docs... See also: http://revctrl.org/Rollback > But suppose the above works I can immediately tell that it will not work > in the following situation, which btw is quite common in our setup: > > > rev A.. XXX > branch main > \/ >rev B rev C / propagate back to main >branch fixbranch fix > > > now if you try the above you don't get a nice new node rev D > with branch certificate, you get just a branch certificate > > branch main > > added to rev C. This in itself is not bad, but very unfortantely > monotone does not even add an edge between rev A and rev C to > indicate that a propagate has taken place. Adding an edge is, of course, physically impossible. (Given current understanding of the physics of computation.) > Suppose you want to disapprove the propagate from branch fix > to branch main because the fix was faulty and need some more development. > How to do this cleanly? I'd love to know -- this is exactly the "Rollback" case discussed on that wiki page above. Bram and I and maybe some others on #revctrl used to mumble about various ad-hoc solutions for this, but all I really know about it is on that page. > I realize I drifted somewhat from the original topic, > but disapprove in my mind is not really flushed out yet > and it can't hurt to think about this. Indeed, these are hard problems, discussion is very valuable. > Oh and it falls for me in the same category is some other > nitpicking I have with the refusal of empty commits etc. > When I have a clear head and some time I really really > should write these things down. That'd be great. Thanks :-). -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: monotone disapprove does not give correct branch cert
Nathaniel Smith <[EMAIL PROTECTED]> writes: > 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 :-). I stand corrected. I never use approve and somehow I thought it was a shortcut for 'this revision did pass the tests'. >> But disapprove you give an explicit revision, so in which directory >> you are should be irrelevant. AFAICT there are two more or less > >> 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. > 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. Of course. But what do you do in the following situation: rev Arev Brev C branch 1 ---> branch 3 -- disapprove --> branch(es) ??? branch 2 branch 4 Also. I have the uncomfortable feeling that the disapprove should not be on a revision, but should be on an edge instead. AFAICT, but I haven't tried it yet, you can't disapprove of a merge, or a propagate rev A branch 1 ->rev C--- disapprove??? branch 1 / rev B / propagate branch 2 But suppose the above works I can immediately tell that it will not work in the following situation, which btw is quite common in our setup: rev A.. XXX branch main \/ rev B rev C / propagate back to main branch fixbranch fix now if you try the above you don't get a nice new node rev D with branch certificate, you get just a branch certificate branch main added to rev C. This in itself is not bad, but very unfortantely monotone does not even add an edge between rev A and rev C to indicate that a propagate has taken place. Suppose you want to disapprove the propagate from branch fix to branch main because the fix was faulty and need some more development. How to do this cleanly? I realize I drifted somewhat from the original topic, but disapprove in my mind is not really flushed out yet and it can't hurt to think about this. Oh and it falls for me in the same category is some other nitpicking I have with the refusal of empty commits etc. When I have a clear head and some time I really really should write these things down. Wim Oudshoorn ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: monotone disapprove does not give correct branch cert
On Tue, 2005-10-25 at 18:50 +0100, Bruce Stephens wrote: > Emile Snyder <[EMAIL PROTECTED]> writes: > > 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. > > I'm unconvinced that disapprove ought to do that. Surely it ought to > use the branches that are on the original revision, maybe giving a > warning if there aren't any? (I guess branchless revisions are > unusual enough to merit at least a warning?) Overridable by the > --branch option, I guess. I'm good with that. thanks, -emile signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: monotone disapprove does not give correct branch cert
Emile Snyder <[EMAIL PROTECTED]> writes: > approve > disapprove > checkout > commit > > 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. I'm unconvinced that disapprove ought to do that. Surely it ought to use the branches that are on the original revision, maybe giving a warning if there aren't any? (I guess branchless revisions are unusual enough to merit at least a warning?) Overridable by the --branch option, I guess. Unless I'm missing something, it's easy enough to add a branch cert if one is really wanted; I'm dubious that using the one in the working copy is going to make any sense (unless it's already on the original revision). [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
