Mercurial > hg4j
comparison design.txt @ 9:d6d2a630f4a6
Access to underlaying file data wrapped into own Access object, implemented with FileChannel and ByteBuffer
| author | Artem Tikhomirov <tikhomirov.artem@gmail.com> |
|---|---|
| date | Sat, 25 Dec 2010 04:45:59 +0100 |
| parents | 5abe5af181bd |
| children | d46773d89a19 |
comparison
equal
deleted
inserted
replaced
| 8:a78c980749e3 | 9:d6d2a630f4a6 |
|---|---|
| 21 | 21 |
| 22 ---------- | 22 ---------- |
| 23 + support patch from baseRev + few deltas (although done in a way patches are applied one by one instead of accumulated) | 23 + support patch from baseRev + few deltas (although done in a way patches are applied one by one instead of accumulated) |
| 24 + command-line samples (-R, filenames) (Log & Cat) to show on any repo | 24 + command-line samples (-R, filenames) (Log & Cat) to show on any repo |
| 25 +buildfile + run samples | 25 +buildfile + run samples |
| 26 *input stream impl + lifecycle. Step forward with FileChannel and ByteBuffer, although questionable accomplishment (looks bit complicated, cumbersome) | |
| 26 | 27 |
| 27 input stream impl + lifecycle | 28 calculate sha1 digest for file to see I can deal with nodeid |
| 28 delta merge | 29 delta merge |
| 29 Changeset to get index (local revision number) | 30 Changeset to get index (local revision number) |
| 30 | 31 |
| 32 | |
| 33 | |
| 34 >>>> Effective file read/data access | |
| 35 ReadOperation, Revlog does: repo.getFileSystem().run(this.file, new ReadOperation(), long start=0, long end = -1) | |
| 36 ReadOperation gets buffer (of whatever size, as decided by FS impl), parses it and then reports if needs more data. | |
| 37 This helps to ensure streams are closed after reading, allows caching (if the same file (or LRU) is read few times in sequence) | |
| 38 and allows buffer management (i.e. reuse. Single buffer for all reads). | |
| 39 Scheduling multiple operations (in future, to deal with writes - single queue for FS operations - no locks?) | |
| 40 | |
| 41 File access: | |
| 42 * NIO and mapped files - should be fast. Although seems to give less control on mem usage. | |
| 43 * Regular InputStreams and chunked stream on top - allocate List<byte[]>, each (but last) chunk of fixed size (depending on initial file size) | |
| 44 | |
| 45 <<<<< |
