General

Topics

  • obsmarker
    • perf
  • manifest sharding & lightweight clones
  • largefiles
  • “remote bookmarks”/remote tracking
  • “labels”
  • many heads
  • rollback/caches/locking
  • subrepo caches
  • bid merge
  • mq (and what it does that nothing else does)
  • general deprecations
  • windows performance
  • in-memory merge
  • evolve ui
  • interrupted commands
  • default ui and other great debates
  • bundle2
  • obliterate: when it absolutely, positively, has to be removed from history overnight
  • kallithea
  • bug triage
  • advocacy
    • updating the book
    • website
  • http2
  • inbox/patchbot
  • automated builds/packaging
  • chg/hglib
  • infrastructure
  • machine readable output
  • linkrevs (cache on the side)
  • histedit

Bug triage

  • When a (regular) contributor files a bug, move it immediately to CONFIRMED.
  • When a contributor reads a bug, move it CONFIRMED or NEED_EXAMPLE.
    • Make sure necessary data is there.
    • Try to quickly reproduce.

Great debates

http://mercurial.selenic.com/wiki/mpm/moot

Enabling progress/color/pager by default: mpm agrees that we should turn progress on by default. There’s a stupid WSGI bug that blocks us doing that for now.

MQ deprecation plan

http://mercurial.selenic.com/wiki/MqDeprecationPlan

Need to get some workflows discussed on that page: map MQ-based workflows to Evolve-based workflows, in addition to just a command-to-command mapping.

Deprecatable review

Bunch of stuff I haven’t captured.

“Friendly HG” config flag

UI config option that we can propose on

Bid Merge

Doesn’t help in as many cases as we’d like, because we need to do some merging between manifestmerge and filemerge.

Patch to come to turn it on by default.

Draft Defaults

Talk about switching default to non-publishing. Concern about accidental non-publishing on servers.

Idea: add UI to hgweb to identify publishing settings and what that means

Idea: Add a banner to hgweb indicating whether a repository is publishing.

Manifest sharding, see manifest sharding.

Obliterate

Use cases: legal requirements to excise data (PII, licensed data, keys).

Tombstone data replaces revlog content, metadata in .hgobliterates -> Need to rewrite delta chains starting after obliterated revision

  • V0 impl: command performing local rewrites, core doesn’t explode
  • V1 impl: servers can eagerly propagate obliterates to clients

Patchbot improvements

Flowbot: looks at Matt’s backlog, number of patches in flight by an author, &c and notifies contributors (privately) to back off when their queue is too deep. Point them to the backlog graph and show contributors what they personally have in-flight.

check-commit-bot: notify contributors that

Advocacy

  • Web site
    • Front page to have news
    • Simplify download flow on web site
      • 1 installer per OS
      • Mac installer (with optional config help)
    • Facebook and Mozilla to ask about webdev love
  • [smf] Create repo for new book and give us access
  • Helping Git users migrate
  • Add Sphinx for hg repo
    • Encourage more rst magic in docstrings?
  • How do we surface hg-git on website?
  • Website needs common extension guide
  • Answer “how to host Mercurial repo” question
  • Integrate pull request commands into hgit and/or hg-git
  • Look into Kuma

Transactions

Use cases:

  • Stripping while pushing
  • Push races seeing inconsistent data

Transaction Reader Flow

  1. read .hg/store/txn -> <id1> + list of files [offset]
  2. open all files (from the list) in txn.<id1>/ directory to obtain handles
  3. if all files opened -> done, else re-read txn and try open again
  4. vfs read FILE only to offset (when offset was available)

Transaction Writer Flow

  1. obtain write lock
  2. copy all files from txn.<id1> to txn.<id2> (with hardlinks)
  3. look for old locations of files (e.g. obstore) and copy into txn.<id2>
  4. write updated content to txn.<id2>, using atomictemp
  5. write .hg/store/txn.active -> <id2> + list of files [offset]
  6. invoke shell hooks to use txn.active (on transaction close)
  7. rename .hg/store/txn.active -> txn
  8. copy relevant files to old locations (if necessary)
  9. release write lock

Open Issues

  • Format of txn file. Multiple append-only files?
  • How do extensions declare txn-relevant files

Reader/Appender/Destroyer Locks

Three lock types:

  1. Reader Lock
readers (many) -> appenders (1) -> destroyers (1)

Lockless streaming clones (requires reader locks):

  1. Read the tip changelog rev
  2. stat all the filelogs for their sizes
  3. Read the tip changelog rev again
  4. if oldtip != newtip:
    1. read new changelog entries to figure out which files changed
    2. read files that have changed to figure out the offset of the linkrev read in step #1
  5. stream revlogs up to the known offsets

“subrepo cache” (a.k.a. out of working copy subrepo storage)

  • Extend hg shares by adding options (upon share creation) to share bookmarks and mq queues

  • When cloning subrepos, clone them into the parent repo’s .hg/subs folder, and then create a “full share” (i.e. share history, bookmarks and mq queues) on the expected working dir location

    • use a unique but human readable naming convention:

      e.g. given: foo/bar/baz = SOURCE_URL
use: .hg/subs/baz_HASHOF(foo/bar/baz = SOURCE_URL)

  • If a subrepo must be removed from the working dir, simply remove the share