[Monotone-devel] monotone-viz oddities again?
I just noticed that I'm currently getting a disconnected graph in monotone-viz. Am I alone in this? Olivier, can you remind me how to generate some debugging output for you? Cheers, Richard -- 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
[Monotone-devel] Re: monotone-viz oddities again?
In message <[EMAIL PROTECTED]> on Wed, 26 Oct 2005 09:23:52 +0200 (CEST), Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> said: richard> I just noticed that I'm currently getting a disconnected richard> graph in monotone-viz. Am I alone in this? Olivier, can you richard> remind me how to generate some debugging output for you? And oh, I work with the bleeding edge, both of monotone-viz (4e8b670a7090b6a49ea60440be4182b1bb6ca86c) and monotone (e54b9741e204c966f94a71bbccafd6202cea0eb1). Cheers, Richard -- 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
[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-viz oddities again?
Richard Levitte - VMS Whacker [Wednesday 26 October 2005] : > > richard> I just noticed that I'm currently getting a disconnected > richard> graph in monotone-viz. Am I alone in this? Olivier, can you > richard> remind me how to generate some debugging output for you? Yes I've noticed this. Actually it's because the graph is no more disconnected. Someone did a commit&merge on a rather old revision (from august) which had effect on reconnecting what was previously two components. I'm not sure what I could do to "fix" the layout. > And oh, I work with the bleeding edge, both of monotone-viz > (4e8b670a7090b6a49ea60440be4182b1bb6ca86c) and monotone > (e54b9741e204c966f94a71bbccafd6202cea0eb1). Ah, I forgot to push my changes to the venge.net server so, in fact, you're not so bleeding edge :). I just pushed them now. With the latest monotone-viz you can view any set of branches (and not just a branch / a branch + all sub-branches). If you select n.v.monotone and the branch that was responsible for the disconnection in the graph (was that n.v.rewrites.path_handling ?), I think you'll get a nicer layout. -- Olivier ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: new default get_netsync_*_permitted hooks
Timothy Brownawell <[EMAIL PROTECTED]> writes: [...] > Any line that doesn't match ' *[^ ]* *".*"', or that doesn't have > "allow", "deny", "pattern", or "continue" as the first word is ignored. That seems to allow a bit too much opportunity for undetected errors, IMHO. I think if I were writing it, I'd pin the syntax down more, otherwise you may get things like: # jim fubared this branch once already... pattern "net.example.project.foobar*" allow "[EMAIL PROTECTED]" deby "[EMAIL PROTECTED]" continue "true" with unexpected effects. [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: monotone-viz oddities again?
In message <[EMAIL PROTECTED]> on Wed, 26 Oct 2005 10:53:17 +0200, Olivier Andrieu <[EMAIL PROTECTED]> said: oliv__a> Richard Levitte - VMS Whacker [Wednesday 26 October 2005] : oliv__a> > oliv__a> > richard> I just noticed that I'm currently getting a oliv__a> > richard> disconnected graph in monotone-viz. Am I alone oliv__a> > richard> in this? Olivier, can you remind me how to oliv__a> > richard> generate some debugging output for you? oliv__a> oliv__a> Yes I've noticed this. Actually it's because the graph is no oliv__a> more disconnected. Someone did a commit&merge on a rather old oliv__a> revision (from august) which had effect on reconnecting what oliv__a> was previously two components. I'm not sure what I could do oliv__a> to "fix" the layout. OK, so if understand correctly, checking for other possible paths is only done when there's a disconnection in the graph, correct? I understand why you don't do that for all nodes, as I can imagine the time spent would not make it worth it. However, here's an idea: regard apparent leaves as a possible disconnection, and check if monotone really regards them as leaves. If not, they should be treated as a graph disconnection. Of course, there will be cases when that doesn't lead any further, but I assume you know how to take care of that. oliv__a> > And oh, I work with the bleeding edge, both of monotone-viz oliv__a> > (4e8b670a7090b6a49ea60440be4182b1bb6ca86c) and monotone oliv__a> > (e54b9741e204c966f94a71bbccafd6202cea0eb1). oliv__a> oliv__a> Ah, I forgot to push my changes to the venge.net server so, oliv__a> in fact, you're not so bleeding edge :). I just pushed them oliv__a> now. With the latest monotone-viz you can view any set of oliv__a> branches (and not just a branch / a branch + all oliv__a> sub-branches). If you select n.v.monotone and the branch that oliv__a> was responsible for the disconnection in the graph (was that oliv__a> n.v.rewrites.path_handling ?), I think you'll get a nicer oliv__a> layout. OK, I'll play with that. I also noticed that the current real leaf doesn't stay at the bottom for the moment (because of the disconnected behavior). While I like the more compact display, in the current situation, it's really confusing to have the real leaf somewhere in the middle of the graph... 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] Re: monotone-viz oddities again?
Olivier Andrieu <[EMAIL PROTECTED]> writes: [...] > I'm not sure what I could do to "fix" the layout. dot has various ways of forcing nodes to lie on the same rank, so I guess you could do that by time or something. That seems like the wrong thing to do in general, but it might be worth specifying that for the most recent few revisions. Or increase the weightings given to the last few edges? That feels like it has a chance of working, and being reasonably easy to code. Or just don't show the whole graph: show the last six months or something. I'm not sure that would work in this case, but it would reduce the size of the graph. [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: monotone-viz oddities again?
Bruce Stephens <[EMAIL PROTECTED]> writes: [...] > Or increase the weightings given to the last few edges? That feels > like it has a chance of working, and being reasonably easy to code. I just tried that by hand, dumping the graph by setting MONOTONE_VIZ_DEBUG=dot, and editing it in doted, and if I add the weight attribute with value 2 to the last edge (58bf607091bceb3158f1872cdec3eb344e375ad0 to 7e8d1d331d6fd71d84b0db6b48de9265371b6541), that seems to work. I was imagining going through the ancestors and descendants of the starting node, setting weights of the edges to some suitable function of the distance from the node. But maybe just a hack to set the weight of the immediate edges would be enough, most of the time? [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone disapprove does not give correct branch cert
Nathaniel Smith wrote: 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... 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). I guess this is close to the model described by Wim later in this thread for propagate behavior...(adding the D revision on the main branch)? 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 :( Zbynek -- http://zw.matfyz.cz/ http://robotika.cz/ Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic ___ 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
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] branch representation
So, err, here's a stupid idea that popped into my head, reading the recent discussion of 'disapprove'. I want it to be clear that this is not a "here's something I've been thinking about for 3 months and it's going to solve 5 problems you hate and 5 you never even knew you had" kind of message, this is a "hrm, this is a crazy idea and I can't even tell whether it's crazy enough to be right or not" kind of message... So the idea is: what if we got rid of branch certs, and put a branch field inside the revision object? So each revision is uniquely, irrevocably, in a single branch. So each revision is not just a snapshot, but a snapshot with a purpose attached. And instead of automatically putting a branch cert on at commit time, you put a "yeah, this is good" cert on (since the rev already has a purpose built in, your vague affirmation of goodness can be assumed to match that). Yeah, this is a really weird idea. It's weird enough that I have trouble really imagining it to evaluate it. (And enough that I deserve to be hit repeatedly with a stick for bringing it up when we're trying to _stabilize_ things...) Anyway, this wouldn't help with things that people find counter-intuitive like, "this branch is discontinuous", or "this branch has multiple branch points", or "this branch has multiple heads". It would help with the confusion about revs being in multiple branches, and generally reduce the weirdness we have all the time where we have to assume all revs have branch certs on them, and try and guess an appropriate branch name given a revision, and so on -- it seems like the code and users both want to think of branch certs as at least somewhat special. I'm thinking of guess_branch, and update's tricky handling of branches, and netsync filtering by branch... It might make doing trust stuff significantly easier. I _think_ a design criterion for a trust system is that I want to be able to specify rules for trusting certs that aren't branch certs, and I want to do this per-branch. This seems very tricky, if the rule for deciding whether you trust a 'foo' cert begins "collect all branch certs on the same rev, invoke the branch trust rules on them, for each branch cert that turns out to be trusted, find that branch's trust rules for 'foo' certs, and then somehow combine the results of applying each branch's rules". And there are probably horrible convoluted attacks: Alice has tag and branch cert rights to branch A. Bob has tag and branch cert rights to branch B. Alice wants to check out the tag 'A-release' so she can send it to the CD manufacturers. Bob does good work over on his project, so Alice does trust him to tag revs on branch B, but he happens to hate project A. Bob takes a buggy rev R on branch A, and adds two certs to it: branch: B tag: A-release Now rev R is, according to the trust rules, quite definitely in both A and B. The A-release tag on it is trusted with respect to branch B's rules, but not respected with respect to branch A's rules. So... do we trust the A-release tag, or what? I guess the unavoidable conclusion is that you can't determine cert trust based on just the contents of the DB plus the current trust rules, but also need to know something about the current context? (checkout -b B -r t:A-release should work, checkout -b A -r t:A-release should silently ignore it?) This seems bad. Maybe I'm missing something. (Okay, maybe trust issues _have_ been stewing around in the back of my head for more than 3 months. But I don't really understand them, so it's maybe premature to use them as arguments in a discussion...) This idea does add a significant new piece to the model -- instead of the nice clean DAG of snapshots _here_, and generic metadata mechanism _there_ setup, we have a piece of magic metadata, that needs to be handled differently, etc. Umm. Probably lots of other things to say, too, but I'll stop here for now :-). -- Nathaniel -- "Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics." -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] branch representation
On Wed, 2005-10-26 at 17:05 -0700, Nathaniel Smith wrote: > It might make doing trust stuff significantly easier. I _think_ a > design criterion for a trust system is that I want to be able to > specify rules for trusting certs that aren't branch certs, and I want > to do this per-branch. This seems very tricky, if the rule for > deciding whether you trust a 'foo' cert begins "collect all branch > certs on the same rev, invoke the branch trust rules on them, for > each branch cert that turns out to be trusted, find that branch's > trust rules for 'foo' certs, and then somehow combine the results of > applying each branch's rules". If they don't all match, print a warning and exit? > And there are probably horrible > convoluted attacks: > Alice has tag and branch cert rights to branch A. > Bob has tag and branch cert rights to branch B. > Alice wants to check out the tag 'A-release' so she can send it to > the CD manufacturers. > Bob does good work over on his project, so Alice does trust him to > tag revs on branch B, but he happens to hate project A. > Bob takes a buggy rev R on branch A, and adds two certs to it: > branch: B > tag: A-release > Now rev R is, according to the trust rules, quite definitely in both A > and B. The A-release tag on it is trusted with respect to branch B's > rules, but not respected with respect to branch A's rules. So... do > we trust the A-release tag, or what? I guess the unavoidable > conclusion is that you can't determine cert trust based on just the > contents of the DB plus the current trust rules, but also need to know > something about the current context? (checkout -b B -r t:A-release > should work, checkout -b A -r t:A-release should silently ignore it?) > This seems bad. Maybe I'm missing something. Perhaps this is a reason to keep different projects in different databases? Bob could just put the A-release tag on something that's *only* on his branch, and it'd work just as well. > (Okay, maybe trust issues _have_ been stewing around in the back of my > head for more than 3 months. But I don't really understand them, so > it's maybe premature to use them as arguments in a discussion...) > > This idea does add a significant new piece to the model -- instead of > the nice clean DAG of snapshots _here_, and generic metadata mechanism > _there_ setup, we have a piece of magic metadata, that needs to be > handled differently, etc. > > Umm. Probably lots of other things to say, too, but I'll stop here > for now :-). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] branch representation
On Wed, Oct 26, 2005 at 05:05:14PM -0700, Nathaniel Smith wrote: > So the idea is: what if we got rid of branch certs, and put a branch > field inside the revision object? So each revision is uniquely, > irrevocably, in a single branch. So if an identical revision (in terms of resulting code) is to be on more than one branch, it needs to be more than one revision, and I now need some other way to prove that the revisions are identical-apart-from-branch? > Anyway, this wouldn't help with things that people find > counter-intuitive like, "this branch is discontinuous", or "this > branch has multiple branch points", or "this branch has multiple > heads". Good. Because I like these things. For me at least, it's not so much that they were counter-intuitive at first introduction, more that they were couter to previous training with other VCSs. I found them very intuitive, in part because they represented a simple consistent underlying pattern and deeper insight. They represented to me that monotone was fundamentally sane. Many of the issues that remain in the 'counter to previous training' category are matters of UI maturity, 'best practice patterns' development, etc. > It would help with the confusion about revs being in multiple > branches, and generally reduce the weirdness we have all the time > where we have to assume all revs have branch certs on them, and try > and guess an appropriate branch name given a revision, and so on -- it > seems like the code and users both want to think of branch certs as at > least somewhat special. Maybe. I'm not familiar with these assumptions and cases in the code, I have to defer to you there. > It might make doing trust stuff significantly easier. I _think_ a > design criterion for a trust system is that I want to be able to > specify rules for trusting certs that aren't branch certs, and I want > to do this per-branch. > > This seems very tricky, if the rule for deciding whether you trust a > 'foo' cert begins "collect all branch certs on the same rev, invoke > the branch trust rules on them, for each branch cert that turns out > to be trusted, find that branch's trust rules for 'foo' certs, and > then somehow combine the results of applying each branch's rules". I'm not sure it's that bad. It probably helps to think about trust having a direction. A lot of the rest of monotone is about directed graphs, trust pretty much should be too. The endpoint is revisions - ultimately, revisions are trusted if there's a path to them through the trust graph. Equally importantly, all the other nodes in the trust graph are *not* revisions; they're either direct or indirect certs. Right now, we only have direct certs (branch, etc) that point to revisions, indirect certs would be permissions certs and identity certs and trust certs of some or other form. These forms might include path constraints in the trust graph, such as for example the requirement that in order for the branch cert trust to apply to a revision, there must also be a (trusted) testresult (author/date/etc) cert for a certain name. All identities are trusted now, adding identity trust certs with constraints, makes this graph deeper, but not necessarily any less directed. In fact, if we're looking for a design criterion around trusts, I think one should be that trust should always remain directed at least in evaluation. For comparative illustration, think about gpg web-of-trust evaluation. The certs themselves are a web; the trust evaluation algorithm searches through this graph adding weighted trust scores to build a directed tree from the trust roots. You example above sounds convoluted, because you change direction several times when trying to describe the trust evaluation algorithm. Say instead you do something morally equivalent to: * build a graph of all certs * (early optimisation) prune all paths that don't lead to the desired selection criteria (revision(s), branches, etc .. if relevant; perhaps you're searching for trusted revisions) * starting at the identity trust root(s?), start labelling certs with identity trust by signer * prune all certs that aren't trusted for identity (maybe we need a specific terminology for this, perhaps 'authenticated') * starting at the permission trust root(s?), start labelling certs according to trust-constraint matching rules * prune all certs that don't have their permissions constraints met * any certs remaining lead from both identity and trust roots, through to trusted revisions. Furthermore, this thought model might provide useful design clues for (especially) permissions rules/certs. Put it another way.. perhaps one of the reasons the users and the code want to treat branches specially right now is that, right now, the *only* trust/permission mechanisms we really have in practical use are based around branches. (testresult certs, as the next-in-line candidate, reveal more about the lack of a stronger permissions syst
[Monotone-devel] Re: branch representation
Nathaniel Smith <[EMAIL PROTECTED]> writes: > So the idea is: what if we got rid of branch certs, and put a branch > field inside the revision object? So each revision is uniquely, > irrevocably, in a single branch. So each revision is not just a > snapshot, but a snapshot with a purpose attached. And instead of > automatically putting a branch cert on at commit time, you put a > "yeah, this is good" cert on (since the rev already has a purpose > built in, your vague affirmation of goodness can be assumed to match > that). I can't really follow what you mean with "yea, this is good" cert. Is that supposed to be a new kind of cert? > it seems like the code and users both want to think of branch certs > as at least somewhat special. I'm thinking of guess_branch, and > update's tricky handling of branches, and netsync filtering by > branch... I think a better way is to deemphasize the importance of the branch certificate. I think the concept that it is just a way to get to a revision is very powerfull. The reason I think monotone should by default add a branch certificate at commit time is convenience, nothing more. (Oh and it is a huge convenience.) > > This idea does add a significant new piece to the model -- instead of > the nice clean DAG of snapshots _here_, and generic metadata mechanism > _there_ setup, we have a piece of magic metadata, that needs to be > handled differently, etc. I like this clear model. I don't think putting the branch inside the revision is going to solve anything. It will reduce the flexibility you have with branches and I don't see any inherit advantage. Also, I think that with the clean structure it has now, monotone is actually easier to grasp than most other VC systems. The hard thing when explaining monotone to others is let realize that it IS simple, making it more complex to alleviate that is the wrong direction IMO. Wim Oudshoorn. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
