Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions

[Tom Lord]

    > From: Tom Tromey <address@hidden>

    [point by point discussion elided]

So, how deep to you want to get into this?

Monotone has some neat stuff and some stuff that, from my perspective,
looks not quite right.  (I.e., it's a mixed bag and to belabor the
hopefully obvious point I'm confident that you'd feel the same way
about arch (at least if I'm understanding your goals correctly).)

The technology-of-trust foo looks potentially cool --- I think I'd do
it a little bit differently.  I have to hold up my personal
unauthoratitive yellow card and say that I'm highly suspicious of some
of the uses of it you seem to have in mind (if I'm understanding the
envisaged uses correctly, you would be increasing, not decreasing
vulnerability in really serious ways).

The idea of an NNTP transport looks very cool.

I've started to think through how those things would map onto arch.
It seems not hard and the real question is cost/value.  I'd presume
that it's not _necessarily_ a _welcome_ suggestion -- but, y'know --
you could achieve these goals, probably with less work, by hacking
arch -- and you'd get to leverage a bunch of other stuff that arch has
in the process.

The monotone patching/merging foo, the manifest mechanism -- those are
sort of mixed (from what I've seen so far).  The rename-detection
heuristics Graydon described have some uses, certainly -- but those
uses are limited.  It sounds (Tromey's reply) like there will be no
principled separation of patching from history that's stored only the
meta-data of repositories -- that's a big mistake, from what I've seen
and I encourage you to avoid it (arch's mkpatch/dopatch are separable
from the most of the rest of the design and is the best solution I've
seen in this area).  A comparison of two manifests (at least as
documented in the .info file) can never (accurately) yield "directory
FOO was renamed" which I think is a significant omission.  Etc.

Overall -- it's a relatively monolithic design in a design space that
factors nicely and usefully into independent parts.


    > Tom> As consequences of this, I don't see how inexact patching or
    > Tom> out-of-band patching can work except in a limited subset of cases.  
By
    > Tom> inexact patching, I mean the application of a changeset between two
    > Tom> arbitrary revisions to a third tree.

    > For inexact patching, do you have some specific set of cases in
    > mind?

Yes.  See the first question in my reply :-)

    > I would expect that the typical developer will have a fairly complete
    > set of history (at least back to the branch points of the branches he
    > is interested in).

Relying on history that way has significant operational drawbacks
(i.e., _slow_) and semantic drawbacks (i.e., too many intertwingled
factors).

But against my opinions and experience -- well, you have momentum of
your own and so forth -- so I'm not sure where, if anywhere, to
"iteratively deepen" the analysis.  



-t