status

hg/fs can be used (reads repositories).  the other tools, that write
to the repository, are not yet safe to use.

intro

hgfs serves the contents of a mercurial repository over styx.  see the
manual page hgfs(4) for more details.  the code for parsing the mercurial
repositories is in a separate library (though undocumented), and there
are a few more small programs that read various information from the
repositories (also undocumented).

install

first, make sure you have "util", "http", "filtertool", "web" installed.

change mkconfig if you do not have $ROOT set.  create the directory
$ROOT/dis/hg.  now "mk install" to compile and install the files.

when building from within inferno, insert SYSHOST=Inferno and ROOT=
in the mk invocations to override the values in the mkconfig.

latest version

the latest version can be found at:

http://www.ueber.net/code/r/hgfs

licence & author

all files are in the public domain.  this code has been written by
mechiel lukkien, reachable at mechiel@ueber.net or mechiel@xs4all.nl.

todo

• hg/mv, hg/cp, hg/push, hg/merge, hg/rollback, hg/bundle, hg/unbundle

• hg/update: for local modifications (as returned by hg/status),
  only refuse to update if their state is actually different from
  that in new revision.  i.e. for "add", don't complain if new revision
  has that file and it has the same contents.  for "remove", don't
  complain if new revision has that file removed.  for "update", check
  if new revision has same data for file.
  

• for dirstate, handle needmerge more like modified?  i.e. verify
  that it really changed, especially during commit.
  

• for commit,update,etc, handle dirstate with p1 & p2 (merge).

• hg/diff: allow only a single revision on command-line too.  should
  be easy with a sort & uniq on output from hg/status & hg/manifestdiff
  combined.
  

• hg/verify: verify that list of modified files in changelog entry
  matches with the files changed in the manifest.
  

• hg/pull: more verification that received data is correct.

• read up on all the formats.  dirstate, undo.dirstate undo.branch
  (for rollback), journal.dirstate, journal.branch, wlock;  lock,
  journal, fncache, etc.;  http://mercurial.selenic.com/wiki/FileFormats
  

• hg/fs: fix (revert) sizes of files in hg/fs when they have meta-data
  (cannot use entry.uncsize for that reason, i forgot).
  

• library: think about caching of revlogs per repo, caching of
  entries in repo's and perhaps try reading less to become up to date.
  

• cgi/websrv: test with various client versions

• hg/fs: "default" in the listings is ugly.  it would make sense
  to name "default-tip" just "tip", but that's confusing with standard
  mercurial practice.  better solution?
  

• library: make proper binary diffs. helps cgi/websrv.

more cpu & memory efficient:

• binary search on Manifest

• currently a big repository uses too much memory and is slow.  e.g.
  the inferno-os hg tree.  the manifest uses lots of memory.  perhaps
  hg/fs shouldn't create a Revtree in memory, but fulfil readdirs/walks
  from the manifest file on the fly.  i think the paths in the
  manifest are sorted.  so we can do a binary search for the current
  path.  then it's a matter of returning a proper qid.  with current
  gens (increase with each path), we would need to do some trick
  (some offsets with known gens) to start counting from.
  

• for cpu usage, perhaps we need a binary tree lookup of nodeid -> rev?
• prevent string formatting for debug messages in often-run code.

• perhaps we should cache Group's for revlog's?  seems more useful
  than storing raw delta's.  does require one base in memory...
  

• findgen in hg/fs currently uses lots of cpu. make more efficient.

• see how memory usage of list of int vs array of int compare.
  might be part of the high mem usage for hgfs File's.
  

• do we keep Manifest & Manifestfile in memory?  perhaps we can do
  without and save memory.
  

• should not have fixed number of rev's cached data, but one
  base+delta's?  or perhaps not the base as it's pretty big (half
  the size of the delta's i think) and can be read quickly?
  

• in hgwire, when making changegroup with changes with big manifests, it will
  help to only look at manifest changes.  now we process all path+nodeid's
  in the whole manifest.  all unchanged path+nodeid's don't even need
  looking at.  if we can make sequential manifest fetching faster
  that would help as well.
  

• use more from nsz's excellent docs in his hgc, at https://sharesource.org/hg/hgc/
• think about other tools such as pull & clone.

future

• real fncache support.  have to figure out why the fncache file
  exists (not sure why repo files are listed, they can be derived and
  you normally don't need this).  windows special files may be more
  useful to escape.
  

• local tags?
• ignore files?