Mercurial > hg4j
changeset 240:29231022fec8
Do not expect file history to be ordered
author | Artem Tikhomirov <tikhomirov.artem@gmail.com> |
---|---|
date | Thu, 23 Jun 2011 13:32:23 +0200 |
parents | df9d2854d3d6 |
children | d3ab16739736 |
files | src/org/tmatesoft/hg/repo/HgDataFile.java |
diffstat | 1 files changed, 10 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
--- a/src/org/tmatesoft/hg/repo/HgDataFile.java Thu Jun 16 04:23:51 2011 +0200 +++ b/src/org/tmatesoft/hg/repo/HgDataFile.java Thu Jun 23 13:32:23 2011 +0200 @@ -26,6 +26,7 @@ import java.nio.ByteBuffer; import java.nio.channels.FileChannel; import java.util.ArrayList; +import java.util.Arrays; import java.util.Collection; import java.util.TreeMap; @@ -232,12 +233,20 @@ }; content.iterate(start, end, false, insp); final HgChangelog changelog = getRepo().getChangelog(); -// changelog.range(inspector, commitRevisions); not effective when changes are sparse and far from each other + /* + * changelog.range(inspector, commitRevisions); + * Not effective when changes are sparse and far from each other. + * However, it's only single file read, unlike code below (few reads of sequential blocks) + * Need to weight tradeoffs of file read and iteration of sparse files. + */ + // final int HistoricallyCloseCommits = 50; // XXX perhaps, shall increase/decrease based on changelog.revisionCount() // (huge changelog => memory mapped files, each file re-read is more expensive than iterating over records in one read? // // try short sequences on neighboring revisions. + Arrays.sort(commitRevisions); // automatic tools (svnmerge?) produce unnatural file history + // (e.g. cpython/Lib/doctest.py, revision 164 points to 63509, 165 - to 38453) for (int i = 0; i < commitRevisions.length; ) { int x = i; i++;