Re: [Monotone-devel] Re: linus talk on git

[Derek Scherger]

Graydon Hoare wrote:
> In practice it's heuristic, same as the "movement inference heuristics"
> in mercurial. This is the road we initially went down. We eventually
> gave up. The misery is archived in the history of a dead file called
> change_set.cc if you go looking for it (and patch_set.cc before that).

Oh I remember that rather well... or at least I remember staring at it
and wondering "wtf does this do?" I also remember thinking that we were
transforming data between several various representations and wondering
why that was.

> Basically we had to synthesize an inode-tree-like representation of the
> manifest, on the fly, in order to deal with "all combinations" of
> directory rearrangement and file lifecycle events. We never really got
> them all, nor managed to figure out how to differentiate "got it right"
> from "guessed wrong and presently auto-merging under flawed assumptions".

The one thing that git has that we didn't was the commit object. Early
monotone's ancestor certs were certainly not the right solution and the
,git commit object seems like a reasonably nice representation
conceptually at least. I haven't looked into the details though.

> Maybe the git or mercurial teams are better at writing such heuristics
> than us. Or maybe they don't care since their users don't move files
> and/or directories as much as our difficult users :)

> > I am not trying to cozy up to git by saying this, as I think overall
> we've done a good thing moving in the direction we did, but: monotone
> initially tracked even simpler structures than git. We didn't even store
> a chained history DAG, just snapshots of the world via a single global
> manifest file that was textually identical to the output of sha1sum. It
> was an initial design choice that "sha1sum --check" would verify your
> workspace, or "sha1sum *.* >MT/manifest" to rebuild a corrupt workspace.
> 
> Jerome came up with the chained history DAG half way through our release
> series (see the entries in the Changelog about enabling changesets).
> Before then you could tangle our history graph into cycles if you
> wanted; it was stored externally as certs. This was a design misfeature
> that took much pain to see through and undo.
> 
> Initially many monotone commands were quite workable without a database
> at all: it just compared the workspace to the cached textual manifest in
> the MT/manifest directory.

The roster representation we have now was quite an enlightening thing
when going through and refactoring various things to use it. It makes
the problems *much* more obvious than any of the previous
representations ever did.

I'm still not convinced that we shouldn't be communicating in terms of
rosters (or at least parts of them) actually. I'll agree that maybe we
don't want to exchange markings in case we decide to change things and
use some other derived information for merging. We could consider
exchanging paths and (stable) node ids (rosters are the monotone
equivalent of git tree objects afaict) rather than revisions with
changesets though. I haven't given this a lot of but internally we
generate new rosters by applying changesets to old rosters and we
generate changesets by comparing pairs of rosters. This feels a bit like
we're still flipping between representations and maybe we could avoid
that and just stick with rosters (tree objects) and revisions (commit
objects) that simply link them together.

Yeah, this would be another big, history rewriting change and no I don't
personally have time to do much of the work but I wonder if it would
simplify things and maybe help speed things up a bit more. Food for
thought if nothing else.

Cheers,
Derek