tikhomirov@1: FileStructureWalker (pass HgFile, HgFolder to callable; which can ask for VCS data from any file) tikhomirov@1: External uses: user browses files, selects one and asks for its history tikhomirov@1: Params: tip/revision; tikhomirov@1: Implementation: manifest tikhomirov@1: tikhomirov@1: Log --rev tikhomirov@1: Log tikhomirov@2: HgDataFile.history() or Changelog.history(file)? tikhomirov@2: tikhomirov@2: tikhomirov@2: Changelog.all() to return list with placeholder, not-parsed elements (i.e. read only compressedLen field and skip to next record), so that tikhomirov@2: total number of elements in the list is correct tikhomirov@1: tikhomirov@1: hg cat tikhomirov@2: Implementation: logic to find file by name in the repository is the same with Log and other commands tikhomirov@2: tikhomirov@2: tikhomirov@2: Revlog tikhomirov@4: 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? tikhomirov@4: tikhomirov@4: tikhomirov@4: ---------- tikhomirov@6: + support patch from baseRev + few deltas (although done in a way patches are applied one by one instead of accumulated) tikhomirov@4: + command-line samples (-R, filenames) (Log & Cat) to show on any repo tikhomirov@6: +buildfile + run samples tikhomirov@9: *input stream impl + lifecycle. Step forward with FileChannel and ByteBuffer, although questionable accomplishment (looks bit complicated, cumbersome) tikhomirov@4: tikhomirov@9: calculate sha1 digest for file to see I can deal with nodeid tikhomirov@4: delta merge tikhomirov@6: Changeset to get index (local revision number) tikhomirov@6: tikhomirov@9: tikhomirov@9: tikhomirov@9: >>>> Effective file read/data access tikhomirov@9: ReadOperation, Revlog does: repo.getFileSystem().run(this.file, new ReadOperation(), long start=0, long end = -1) tikhomirov@9: ReadOperation gets buffer (of whatever size, as decided by FS impl), parses it and then reports if needs more data. tikhomirov@9: This helps to ensure streams are closed after reading, allows caching (if the same file (or LRU) is read few times in sequence) tikhomirov@9: and allows buffer management (i.e. reuse. Single buffer for all reads). tikhomirov@9: Scheduling multiple operations (in future, to deal with writes - single queue for FS operations - no locks?) tikhomirov@9: tikhomirov@9: File access: tikhomirov@9: * NIO and mapped files - should be fast. Although seems to give less control on mem usage. tikhomirov@9: * Regular InputStreams and chunked stream on top - allocate List, each (but last) chunk of fixed size (depending on initial file size) tikhomirov@9: tikhomirov@9: <<<<<