Thomas Moschny <[EMAIL PROTECTED]> writes: > Stephen Leake wrote: >> differences; roster_deltas can use node ids instead of file names, for >> example. > > Yes. Node ids are also strictly local and never travel across the net. > > Of course there are more differences, like the fact the changeset > for one revision shows differences against all parents,
Not quite; if there are two parents (in a merge), there are two changesets; they are stored in the 'edges' component of revision.hh revision_t. The result of applying the two changesets to the two parents is often not quite identical; they get "fixed up" by roster.cc unify_rosters. Which I think I have now sorted out for suture ancestors, but I'm not entirely sure. > whereas the roster delta for a revision contains the differences > against exactly one child. Right, because it's actually a "reverse delta". Changesets are used to go from parent to child; roster deltas go from child to parent. Hmm. That means there are actually two roster deltas for a merge; I'm not clear how that is managed. Ah; database.cc database_imple::get_roster_delta takes two roster ids; 'ident' and 'base'. Then theres a "roster_reconstruction_graph" which specifies the adjacent roster ids. Since roster deltas store node ids and other "local data", there is no need for a "fix up" step for merges. In other words, roster deltas are exact, while changesets are not. Roster deltas appear to be mainly a form of data compression, just as file deltas are. To retrieve an old revision, you get the latest, and apply successive deltas to it. Which will be a problem when I implement split; then there will be n children with one parent. That will be interesting! But we need split to be able to undo a suture. > Also, changesets do know nothing about markings. Right. -- -- Stephe _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
