This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Failed to load latest commit information.
# 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 email@example.com or firstname.lastname@example.org. # 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?