Mercurial > jhg
comparison design.txt @ 197:3a7696fb457c
Investigate optimization options to allow fast processing of huge repositories. Fix defect in StatusCollector that lead to wrong result comparing first revision to empty repo (-1 to 0), due to same TIP constant value
author | Artem Tikhomirov <tikhomirov.artem@gmail.com> |
---|---|
date | Tue, 19 Apr 2011 03:49:29 +0200 |
parents | 8c8e3f372fa1 |
children | 33a7d76f067b |
comparison
equal
deleted
inserted
replaced
196:e2115da4cf6a | 197:3a7696fb457c |
---|---|
58 ??? http://mercurial.selenic.com/wiki/Manifest says "Multiple changesets may refer to the same manifest revision". To me, each changeset | 58 ??? http://mercurial.selenic.com/wiki/Manifest says "Multiple changesets may refer to the same manifest revision". To me, each changeset |
59 changes repository, hence manifest should update nodeids of the files it lists, effectively creating new manifest revision. | 59 changes repository, hence manifest should update nodeids of the files it lists, effectively creating new manifest revision. |
60 | 60 |
61 ? subrepos in log, status (-S) and manifest commands | 61 ? subrepos in log, status (-S) and manifest commands |
62 | 62 |
63 ? when p1 == -1, and p2 != -1, does HgStatusCollector.change() give correct result? | |
63 | 64 |
64 Commands to get CommandContext where they may share various caches (e.g. StatusCollector) | 65 Commands to get CommandContext where they may share various caches (e.g. StatusCollector) |
65 Perhaps, abstract classes for all Inspectors (i.e. StatusCollector.Inspector) for users to use as base classes to protect from change? | 66 Perhaps, abstract classes for all Inspectors (i.e. StatusCollector.Inspector) for users to use as base classes to protect from change? |
66 | 67 |
67 >>>> Effective file read/data access | 68 >>>> Effective file read/data access |
90 | 91 |
91 * defects | 92 * defects |
92 + ConfigFile to strip comments from values (#) | 93 + ConfigFile to strip comments from values (#) |
93 | 94 |
94 <<<<< | 95 <<<<< |
96 Performance. | |
97 after pooling/caching in HgStatusCollector and HgChangeset | |
98 hg log --debug -r 0:5000 and same via Log/HgLogCommand: approx. 220 seconds vs 279 seconds. Mem. cons. 20 vs 80 mb. | |
99 after further changes in HgStatusCollector (to read ahead 5 elements, 50 max cache, fixed bug with -1) - hg4j dumps 5000 in | |
100 93 seconds, memory consumption about 50-56 Mb | |
101 | |
102 <<<<< | |
95 | 103 |
96 Tests: | 104 Tests: |
97 DataAccess - readBytes(length > memBufferSize, length*2 > memBufferSize) - to check impl is capable to read huge chunks of data, regardless of own buffer size | 105 DataAccess - readBytes(length > memBufferSize, length*2 > memBufferSize) - to check impl is capable to read huge chunks of data, regardless of own buffer size |
98 | 106 |
99 ExecHelper('cmd', OutputParser()).run(). StatusOutputParser, LogOutputParser extends OutputParser. construct java result similar to that of cmd, compare results | 107 ExecHelper('cmd', OutputParser()).run(). StatusOutputParser, LogOutputParser extends OutputParser. construct java result similar to that of cmd, compare results |