[Monotone-devel] A few thoughts...

[Ori Berger]

Hello everyone.

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

I haven't been able to compile or use it myself yet, but it just 
feels like "the right thing" in many respects. An issue I had with 
just about _every_ version control system I used, is that, at one 
point or another, I split a file into two. Sometimes, neither file 
has the same of the parent, and sometimes one of the files does.

All version control systems, except monotone, would either ignore 
this relationship entirely, or artificially make one of the files 
appear out of nowhere, and the other look like half of it was 
deleted. While monotone can't detect this automatically (but, read 
on ...), it can encode this info into certs, and it's the natural 
thing to do.

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.

The fact that it's mostly a monolithic binary is a big plus in my 
book - modularity should come at higher levels (the depot, possibly).

There are a few things I would have done differently:

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.

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.

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.); The conflict editor can somehow 
certify a user-assisted reconciliation (e.g., by leaving a specific 
file in the same directory, or some other way). Later, monotone can 
use that "certified" answer, when it is next run (possibly by the 
conflict resolution).
Long running processes that halt waiting for input are much harder 
to automate / GUIfy; Consider an IDE that includes conflict 
resolution, that tries to check a change in and discovers a 
conflict. It's much easier to handle "statelessly" than 
"statefully". It's also much easier to automatically test stateless 
behaviour than stateful behaviour.

Storage; I'll describe an alternative in another post once I have my 
thoughts better laid out.

Things I think should be kept in the back of the head for future 
versions - you've probably thought of these before, but 
just-in-case, I'll put my thoughts on record:

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.

Friendly Names; It's possible to encode SHA1 codes into phrases 
which can easily be uttered through the phone and easily (?) 
memorized - see, e.g. Oren Tirosh's work on 
http://tothink.com/mnemonic . This makes out-of-band communication 
of versions and trust much more feasible.
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". Without a 
local name assignment, the same branch would be named 
"monotone-0.5/sha1:123f87861e27b6178d6289376189237" or
"monotone-0.5/mnemonic:magic-slang-crimson--inch-calypso-ibiza--candle-studio-domino--chance-fiction-spider--harvard-gorilla-madonna"
(using Oren's mnemonic encoder. Neither is easy to memorize or 
communicate over the phone, but the latter is much much easier).

"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 will also detect rename + edit as long as 
the edit is less than 10% of the file; It would even detect a copy + 
edit or a cross rename ("mv a t; mv b a; mv t b"), which I think 
only ClearCase does today and that's only because it IS the 
filesystem. 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).

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.

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

That's it for now; Unfortunately, I won't have enough time in the 
forthcoming month to contribute myself, but I hope I'll be able to 
contribute soon.

For the record, once more: *monotone rocks!*.

Thanks,
Ori.