On Sat, Jul 25, 2009 at 12:39 AM, Patrick Georgi<[email protected]> wrote: > Yes, but look how it's done. It's in roster_delta.cc, > make_roster_delta_t(...): > It creates a datastructure containing information about _all_ files in the > roster (ie. all 50000 in my case), and then loops over them and notes the > differences. > The cset already contains a list of all changes between the two revisions, > so the code could walk a changeset to figure out which roster entries to > handle. As most changesets are rather small, that should give a nice speed > up.
Yeah, that'd probably work -- loop over the cset, convert the paths into node_id's, then just loop over those. The trick is making sure you look up all the correct paths in the correct rosters so you never miss any modified nodes -- this will take some groveling over the exact definitions of the various cset operations and probably some additions to the Giant Roster Tests to make sure the results are the same with/without the optimization. The other way would be to teach the roster+cset -> new roster code to keep a list of dirtied nodes, but that might be tricky for merges, I forget. -- Nathaniel _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
