[Monotone-devel] Re: linus talk on git

[Graydon Hoare]

Justin Patrin wrote:

> > One thing
> > Linus mentions in the talk is that a function moving from one file to
> > another would be recognized by annotate because of the fact/way that git
> > tracks content. This sounds interesting and I'm curious as to what it
> > looks like in practice.

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). 
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".

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 :)

Hard to know. It's clear that they're a bit more stubborn about sticking 
to their guns. I'm a bit of a quitter: after a few months of wasted 
evenings on heuristics, it seemed obvious that it was a dead end. I just 
wasn't clever enough to work out the merge rules needed for its 
replacement. Needed the mark-merge/revctrl research to work that out, 
which is more smarts than I have.

> Assuming my understanding of monotone is correct, monotone checks the
> sha1's on all of the history of the revision.
...
> Or maybe neither of my understandings is correct. :-/

Nope. History plays no role in status functions.

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.

-graydon