Mercurial > hg4j
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 |
