4.0 Sprint

Subscribe to this page so you don't miss updates!

1. Date and location

The sprint will be held at the Mozilla office in Paris, Oct 7-9. More info about the office can be found at https://wiki.mozilla.org/Paris.

Location point of contact: Gregory Szorc (indygreg) - gps@mozilla.com

If you need a formal invitation for visa purpose, contact the person above.

2. Attendance

Everyone is welcome from core developer to aspiring contributor. Attending a Mercurial sprint is usually a good way to kickstart your contributions and you'll get a large amount of help available for 3 days.

3. Travel tips

If you need a smartphone to use while in Paris, http://www.insidr.paris/ is an option.

4. Sponsors

We have funds to pay flights and hotel for a few independent contributors.

Sponsoring Company:

• Google

• Pythonian

• Please offer some sponsoring

Sponsor point of contact: Kevin Bullock <kbullock@ringworld.org>

5. Meals

Having Food delivered for Lunch is usually preferred as it help keeping the timing under control. Dinner is usually taken outside to help people cool off after a day of work.

(Don't forget vegetarian and vegan option)

Meal point of contact: Location not picked yet

6. Possible Topics

It worked well at the last sprint to devote some of the time to "unconference"-style sessions, proposed by attendees and scheduled into a grid of timeslots and rooms. Do we want to plan on that again? —KevinBullock

Important things we want to discuss:

6.1. Project infrastructure (Kevin Bullock)

I'll give a report on the current state of the project's infrastructure (server, buildbot, bugzilla, mailing lists, &c.), and walk people thru the config automation we've done via Ansible and Docker. Hoping to get some more people familiar with it so they can solve problems when they arise.

6.2. Transition

Did you knew Mercurial now had a Steering committee ? (and other question related to mpm/transition)

6.3. Topics (Sean Farley, Erik van Zijst, Pierre-Yves David anyone else)

Flesh out topics. Designing a natural and easy-to-use workflow: when should a changeset become public in an average user's workflow?

6.4. MergeDriver internals (Siddharth Agarwal, ...)

Talk (~1h) about internals of MergeDriverPlan + whatever work we end up doing next.

6.5. StreamClone and Batch wireproto enhancements (durin42, indygreg)

Seem related. Streamable and reorderable batch.

6.6. Evolution and relation topic (Kyle Lippincott, Pierre-Yves David)

It is probably worth chatting about evolution in general.

Kyle had some specific questions too:

Q: Is hg evolve --all discouraged? Should it be?

A: Yes, it is, for various temporary and fundamental reason:

Q: Frequently users at Google just run hg evolve --all instead of more focused evolves, and dislike that after hg evolve --all they are on the tip-most revision instead of the revision they started on (or potentially the successor of that revision). I'd like to discuss changing this movement behavior (via a flag and/or config option)

A: This is definitly something we would like to change. especially now that 'hg next'; have some evolution capability. However, more work on the evolution state file is needed. Anyone is welcome to send patch to make progress here.

Q: The subject is based on my (possibly flawed) recollection that the movement is happening because hg evolve --all; hg co .^^; hg amend; hg evolve --all; hg co .^; hg amend; ... is really not recommended.

A: Yes there is a potential marker explosion issue that we need to have a proper answer to.

6.7. Performance tracking suite (Philippe Pepiot)

Talk and demo about PerformanceTrackingSuitePlan

6.8. Virtual filesystems for source code (Kyle Lippincott, Durham Goode?)

Google has had this (for non-Mercurial repos) for a while and Facebook has just started working on something called Eden. It'd be great to discuss how this fits in Mercurial's overall ecosystem, whether anything should go into core and other plans going forward.

6.9. Reliability and performance in large Mercurial deployments (Rodrigo Damazio)

Many companies now have large Mercurial repositories, often hosted in a distributed server environment. I'd like to discuss implications and a few specifics (such as having exponentially-backed-off retries, request batch load-balancing and out-of-order batch replies on the client).

6.10. Code Review Tooling (Ryan McElroy)

A persistent issue for people wishing to provide a little bit of help to the community through code review (which might lead to a lot of help over time!) is the need for each person to develop their own tooling around an email-based workflow. What tools can we bring to bear to make "wading in" to the community more accessible (rather than being doused with a firehose).

Jun has a fork of the sup email client which has some nice features like Patchwork integration.

6.11. Interleaved deltas related topics (Jun Wu)

• hg absorb, which was previously known as "smartfixup", as a tool to edit a stack.
• hg absorb --edit-lines (better name, "hg collate"?) interface to edit all lines from different revisions of a file, useful to move lines between changesets
• hg fastannotate, which is a faster annotate implementation, once the cache gets built
• hg fastannotate --deleted, as a way to examine all lines ever existed in a file

6.12. Bitmap Index for hidden changesets (Durham, Jun)

Mainly to address the start-up time reading the obsstore, calculating various sets of obsoleted commits. It aims for O(1) testing if a rev is hidden or not, with O(1) start-up time. The bitmap index is better to be the source of truth so other code path can only do incremental update to it - better for performance.

6.13. Mercurial book progress (Mathias)

Anyone interested in the book is welcome to discuss progress and future plans

6.14. Random experimental ideas

Some random ideas without POCs.

• Extended linkrev store (Jun): Sometimes we do know a better linkrev for a filenode, for example "hg amend" which creates a obsolete marker, the linkrev pointing to the obsoleted changeset is less useful so we may want to change it to point to the successor instead. But we cannot rewrite revlog, so we may want to have some extra storage storing those "better linkrevs"
• On-disk radix tree index (Jun): We need to build the radix tree for hash lookup every time. What if we want it to be persistent on disk?
• Changelog graph index (Jun): group adjacent nodes which has 1 child and 1 parent together into some bigger node, to speed up changelog traversal (for testing ancestors, etc). This also allows lazy changelog in the future - if the client does not need full history.
• Hash preserving (Jun): By adding a {node: version} map to the obsstore layer, we may be able to move commit metadata like "amend_source" to that map so "hg touch" will use the old commit hash - friendly for average users. The challenging would be obsmarker exchange.

6.15. Your topic here! (Your Name)

Add your own topics here.

7. Sprint Notes

General overview (drop the anti spam part): https://public.etherpad-mozilla.org/p/sprint-hg4.0-NOSPAMREMOVETHATLASTPAST

The table below is an attempt to gather written summary of discussions

CategoryMeetings