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
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel