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
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel