# 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?

Unlimited private and public hosted repositories. Free for small teams!