Mercurial > jhg
view design.txt @ 13:df8c67f3006a
Basic manifest parsing to analyze what's in there
author | Artem Tikhomirov <tikhomirov.artem@gmail.com> |
---|---|
date | Sun, 26 Dec 2010 03:21:17 +0100 |
parents | d46773d89a19 |
children | 442dc6ee647b |
line wrap: on
line source
FileStructureWalker (pass HgFile, HgFolder to callable; which can ask for VCS data from any file) External uses: user browses files, selects one and asks for its history Params: tip/revision; Implementation: manifest Log --rev Log <file> HgDataFile.history() or Changelog.history(file)? Changelog.all() to return list with placeholder, not-parsed elements (i.e. read only compressedLen field and skip to next record), so that total number of elements in the list is correct hg cat Implementation: logic to find file by name in the repository is the same with Log and other commands Revlog What happens when big entry is added to a file - when it detects it can't longer fit into .i and needs .d? Inline flag and .i format changes? ---------- + support patch from baseRev + few deltas (although done in a way patches are applied one by one instead of accumulated) + command-line samples (-R, filenames) (Log & Cat) to show on any repo +buildfile + run samples *input stream impl + lifecycle. Step forward with FileChannel and ByteBuffer, although questionable accomplishment (looks bit complicated, cumbersome) calculate sha1 digest for file to see I can deal with nodeid DataAccess - collect debug info (buffer misses, file size/total read operations) to find out better strategy to buffer size detection. delta merge Changeset to get index (local revision number) >>>> Effective file read/data access ReadOperation, Revlog does: repo.getFileSystem().run(this.file, new ReadOperation(), long start=0, long end = -1) ReadOperation gets buffer (of whatever size, as decided by FS impl), parses it and then reports if needs more data. This helps to ensure streams are closed after reading, allows caching (if the same file (or LRU) is read few times in sequence) and allows buffer management (i.e. reuse. Single buffer for all reads). Scheduling multiple operations (in future, to deal with writes - single queue for FS operations - no locks?) File access: * NIO and mapped files - should be fast. Although seems to give less control on mem usage. * Regular InputStreams and chunked stream on top - allocate List<byte[]>, each (but last) chunk of fixed size (depending on initial file size) <<<<<