Notes captured from the sprint titanpad
Topics
======
* obsmarker
* perf
* manifest sharding & lightweight clones
* largefiles
* "remote bookmarks"/remote tracking
<https://titanpad.com/hg-remotebookmarks>
* "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 <http://mercurial.selenic.com/wiki/GenericTemplatingPlan>
* linkrevs (cache on the side)
* histedit
<https://titanpad.com/mercurial32-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 https://titanpad.com/mercurial32-manifest-sharding (moved to wiki as http://mercurial.selenic.com/wiki/ManifestShardingPlan)
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)
8) rename .hg/store/txn.active -> txn
9) copy relevant files to old locations (if necessary)
10) 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:
4.a) read new changelog entries to figure out which files changed
4.b) 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