Re: [Monotone-devel] A few thoughts...

[graydon hoare]

Ori Berger <address@hidden> writes:

> I'd like to start by saying that *monotone rocks*.
> And again, *monotone rocks!*.

thanks, with all the negative discussion yesterday, it's nice to hear
someone likes it :)

> The tight public key integration is definitely the right thing to
> do; If it's not part of the system, no one will use it.

I'm glad, too, that someone else believes this. I've seen gpg and
openssl sitting in /usr/bin for some time without most of my tools
adopting them in any sensible or interoperable fashion. it's a touch
sad, but it's the way things seem to be.

> Lua; IMHO Python would be a better choice, because of being better
> known, and having more libraries. It's just as easy to statically
> embed.

I did investigate this, as I agree it's more widely known and equally
simple to code. I stuck with lua for a couple reasons:

  - despite your belief, I did find it "harder" to embed. the python
    interpreter prefers to be in control of the runtime: signals,
    allocation, control transfer, file descriptors. I am amenable to
    arguments indicating that this situation has changed, but when
    last I looked, it had not.

  - python is a "bigger" language, and I want to keep the use of
    extension language relatively small and light. if the issue is
    important enough to require "big" language features (modules,
    exceptions, objects) I would prefer to "cast it in stone" as part
    of monotone, in C++.

  - related to being bigger, python is more of a moving target. python
    installations vary more. python is generally going to cost me more
    time supporting it, as people try building monotone against all
    the pythons in the world. I considered TCL over lua for similar
    reason, and only rejected TCL due to the widespread loathing of
    it, and prefix syntax.

> Boost; I'm close to temporarily suspend my principle of building
> everything from source - I've spent an hour and a half and while I
> made great progress, I couldn't properly build it because of
> boost. I'll try that again tomorrow.

yes, boost is hard to build. I'm sorry about that, but I got too much
out of it to consider dropping it as a requirement. I may relieve some
of your pain by pointing out that debian provides packages of it, as
does a colleague at redhat (unofficially):

  http://people.redhat.com/bkoz/Red_Hat_Linux_9/i386/

> Plug ins; I "stateless", in the sense that, e.g. a merge conflict
> doesn't run a script and wait for it to finish; Rather, it creates
> an environment in which a conflict editor can be run (e.g., a temp
> dir with three file versions, etc.);

I think this is doable with the current setup. the default merge
handler is in std_hooks.lua, and can (unless I misunderstand) be
overridden with something such as you describe.

> Issue Tracking; It's probably beyond the scope intended for monotone
> now, but every version control system eventually needs to integrate
> with an issue tracking system. The right kind of hooks in the
> version control system will make it much easier to integrate. I
> don't think I know of an issue tracking tool that works well with
> CVS's branching. I don't know what the right hooks are, though.

agreed. it's crossed my mind several times to try extending monotone
in this direction, but, y'know, there's things like "making it work
right" to deal with first. I see playing with bug tracking as a sort
of "post-1.0" item, though if you want to hack on it go ahead.

> Friendly Names; It's possible to encode SHA1 codes into phrases
> which can easily be uttered through the phone and easily (?)
> memorized -

eh.. we've certainly considered it. we dealt with this on IRC
recently, but I didn't post to the list detailing the results. what I
wound up doing is implementing SHA1 comlpletion. so for example you
can type "monotone checkout a62 ."  and it will expand to the full
40-character manifest SHA1 a623c265cdc9a1b17508a5819173b17ce73b780e.
if you only typed "monotone checkout a6 ." it would tell you that this
is ambiguous, and print out the ambiguous completions
a623c265cdc9a1b17508a5819173b17ce73b780e and
a6ddee209d47b99779e881e9e4723cd2952fb4a8.

so far I think this is a simple enough compromise, as it seems most of
the time a handful of digits is enough. humans can reliably memorize
about seven digits, which is enough to likely disambiguate amongst 268
million tree states.

I don't really want to introduce multiple naming schemes if I can
avoid it. for now, download what's in CVS (or the monotone depot) and
try out the completion. if you still dislike it, we can revisit this.

> Also, it could be useful if you can assign a local name to a trusted
> cert. For example, if I assign the name "graydon" to graydon's
> public key, I'd like "monotone-0.5/my:graydon" to refer to a branch
> which graydon's key certified has the name "monotone-0.5".

hm. perhaps at a UI level, but I don't see a pressing need, and such
extended syntaxes often lead to endless new extensions (eg. filtering,
sorting, selecting). I'll keep the case in mind, but I don't wish to
implement this at the moment.

> "intelligent" history detection; Consider, for example, the example
> I gave above, of a file split into two. It's possible to detect this
> automatically by a rule such as: "if 90% of X is found in Y, then Y
> is ancestor of X".

this is very touchy territory. I agree it's a compelling notion, but
the potential for it to go wrong seems at least as large as the
potential for it to go right (eg. guess ancestry in the wrong order,
notice "unimportant" commonality or difference). I might be willing to
make this a hookable point, where you can plug in such an
ancestry-inference strategy, but not make it the default policy.

> It's not a common occurrence, of course, but I think it's possible
> with a few simple content sensitive rules to correctly infer the
> metadata (Including, e.g., renaming of a directory).

directory renames, yes, I think are important enough to include a
heuristic for. I've backed off my position yesterday in favour of an
explicit directory representation, I think the heuristic will be
enough, and intend to implement it in the primary manifest merging
logic.

> Central repository; by that, I mean to let several users share the
> same store. It might even work today, as sqlite has support for
> simultaneous access to a database (assuming proper remote locking
> semantics, which unfortunately older NFS versions lack). But it's
> something that is easy to break.  In the common setting of a group
> working in the same building and having access to the same LAN, I
> think it's easier to manage / set-up / backup, etc.

interesting! hadn't considered it. I suspect it would actually work
today, yes. I don't think I want to encourage it, at this stage,
simply because I have no idea whether there would be negative
consequences. if you want to try it out and check, please let me
know.

> Automation; It's important to make sure that monotone output can
> easily be parsed by IDEs and the like.

yeah, I hope to make this more of a theme. I've been sifting through
things which talk to stdout/stderr and cleaning them up recently,
making a centralized UI policy object, etc. feel free to submit
patches if you find irregularities.

thanks for your comments! if you're interested in discussing things
further, you can also try irc.oftc.net #monotone.

-graydon