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 <file>
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@14: + dirstate.mtime
tikhomirov@4: 
tikhomirov@9: calculate sha1 digest for file to see I can deal with nodeid
tikhomirov@11: DataAccess - collect debug info (buffer misses, file size/total read operations) to find out better strategy to buffer size detection.
tikhomirov@4: delta merge
tikhomirov@6: Changeset to get index (local revision number)
tikhomirov@14: .hgignored processing
tikhomirov@14: RevisionWalker (on manifest) and WorkingCopyWalker (io.File) talking to ? and/or dirstate 
tikhomirov@9: 
tikhomirov@9: 
tikhomirov@15: ??? encodings of fncache, .hgignore, dirstate
tikhomirov@16: ??? http://mercurial.selenic.com/wiki/Manifest says "Multiple changesets may refer to the same manifest revision". To me, each changeset 
tikhomirov@16: changes repository, hence manifest should update nodeids of the files it lists, effectively creating new manifest revision.
tikhomirov@15: 
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<byte[]>, each (but last) chunk of fixed size (depending on initial file size) 
tikhomirov@9: 
tikhomirov@9: <<<<<