On Thu, Aug 24, 2006 at 09:40:08AM +0100, Andy Jones wrote: > I think the first half of the manual is the best discussion of version > control that I have ever read. I mean that. A lightening bolt hit me, > and I finally understood why I had this love/hate relationship with CVS. > (Up until that point I had honestly thought that version control was so > complex a subject that any VCS +had+ to be flaky.)
Wonderful! Reminds me of my own experience when first playing with monotone, when I didn't know anything about VCS beyond "cvs checkout", "cvs up", "cvs commit". For a long time I thought I must _really_ be stupid and missing things, because not only did everything I understood seem unrealistically simple, I couldn't even figure out where the gaps in my understanding were. There were obviously gaps, after all, because the scary complex VCS stuff had to be hiding _somewhere_! Or, well, no, turns out all you need is a DAG of tree snapshots and some metadata. Weird, huh? > And I would include the tutorial in that. Don't change it. Sure it's > linear - the written word pretty much has to be: you need to start at the > beginning, go on until the end, and then stop. That would only be a > problem if it was overly long. It gets it just right, teaching you all > the basics. Sure -- but, say, many people who use monotone will not set up a server (and certainly not before they even run 'pull'). Possibly that part would better go into a separate discussion (which could then be expanded to discuss the topic more fully, e.g., talk about how to use runit.) Or maybe not, but that kind of thing. > What the manual needs is a better discussion of the more complex issues, > with examples. Broken up into topics, as they are now. Right, exactly. > I mean, look at > the section on the trust model. It's one paragraph long. Frankly I'm > +still+ not sure how to implement trust. Err, well...... umm. Look, a monkey, over there! ----------> (We're not sure either.) More seriously, it's just not known very well yet -- we've been focusing on building the tools to let you do cool workflow stuff, but the pieces aren't quite all there yet, and (AFAIK) no-one has sat down and actually built a cool workflow system, with tool support, etc., that we can point people to as an example. We'd _definitely_ be interested in hearing whatever you come up with, if you decide to go this way. Don't get hung up on 'testresult', 'approve', 'disapprove', though -- there isn't any Deep Plan behind them, they were just some guesses, made long long ago, as to what sort of thing might be useful, sorta, someday. (Actually, 'disapprove' has useful functionality, but IMO should be rolled into the 'revert' command; the name is not very helpful.) Focus on the basic language of certs, and how you could use them to express useful things. Check out the 'automate' interface; pretty much any of the fancy UI stuff like 'mtn update respects testresult certs' could be scripted up using 'mtn automate' -- and anything that could be scripted up like that could be moved into mtn proper, if that turned out to be the right place to put it. The main missing piece to handle trust is a way to delegate decisions about it -- some way for a _group_ to say "here's who we trust", instead of every individual having to manage things for themselves manually. This is what the VersiondPolicy thing tries to get at... hopefully that will become more concrete soon. For most workflow stuff, though, trust pre se is not really that important -- you just need a way to keep track of which patches need to be reviewed, which are ready to be merged, etc. Sure, it's nice sometimes to have some enforcement underneath that people aren't lying and saying that their change has been reviewed when it hasn't, but the actual tracking of workflow state should totally be possible now. -- 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
