Note:
This page is primarily intended for developers of Mercurial.
5.6 Sprint
Contents
- Date and location
- Attendance
-
Possible Topics
- Tags
- Releases
- Shelve using archived phase
- Replication-friendly repository format
- Combined revlog
- More command "namespace"
- Google's --changeset-as-wdir feature
- Demo of Martin's experimental VCS
- Dropping Python 2
- State of Rust
- Mercurial layered architecture
- Testing systems
- Using MMap More
- General performance discussion
- --auto-shelve flag (similar to --autostash in git) for write commands
- Packaging / TortoiseHg
- Who is interested in which topics?
- Sprint Notes
Subscribe to this page so you don't miss updates!
1. Date and location
This sprint will be held online using Google Meet. It will start on Nov 5 at 15:00 UTC (07:00 US West Coast, 10:00 US East Coast, 16:00 CET, 20:30 India, 24:00 Japan). Instructions for connecting to the VC will be added here before the sprint starts.
The schedule is available in https://docs.google.com/spreadsheets/d/1-PhQvYRmUk2LRrpKZg32fktAsfBRN93WC1GKCnDK7YY/edit?usp=sharing.
The Google Meet link for Saturday is https://meet.google.com/ybp-fjhd-hwp The Google Meet link for Sunday is https://meet.google.com/mvi-ogxh-ytw
1.1. People Availability
Please also indicate your interests in the table at the bottom if you add yourself here.
Name |
Time Zone |
Nov 5 |
Nov 6 |
Nov 7 |
Nov 8 |
Notes |
Martin von Zweigbergk |
US West Coast |
|
|
|
|
|
Jeff Sipek |
US East Coast |
|
|
|
|
|
Augie Fackler |
US East Coast |
* |
|
* |
|
* Monday and Wednesday I'm unlikely to be able to focus until around 1400 America/New_York. Other days all easy. |
Jörg Sonnenberger |
Central Europe |
|
|
|
|
|
Matt Harbison |
US East Coast |
|
|
|
|
|
Rodrigo Damazio Bovendorp |
US West Coast |
|
|
|
|
|
Danny Hooper |
US West Coast |
|
|
|
|
|
Manuel Jacob |
Central Europe |
|
|
|
|
|
Pierre-Yves David |
UTC+1 |
|
|
|
|
|
Raphaël Gomès |
UTC+1 |
|
|
|
|
|
Antoine Cezar |
UTC+1 |
|
|
|
|
|
Georges Racinet |
UTC+1 |
|
* |
|
|
I have a consultancy on Nov 6, will try and play with time zones |
Pulkit Goyal |
UTC+5:30 |
|
|
|
|
Timezone differences, but can try to join a meeting or two |
Yuya Nishihara |
UTC+9 |
|
|
|
|
I can't wake up early |
Gregory Szorc |
US West Coast |
|
|
|
|
|
Sushil Khanchi |
UTC+5:30 |
|
|
|
|
Timezone differences, but can try to join meetings acc. to the timings |
Valentin Gatien-Baron |
US East Coast |
|
|
|
|
|
Charles Chamberlain |
US East Coast |
|
|
|
|
|
Mathias De Maré |
UTC+1 |
* |
* |
* |
* |
* Will try to join where possible/relevant |
Anton Shestakov |
UTC+8 |
|
|
|
|
Available as a fly on the wall ~15:00-19:00 UTC |
2. Attendance
fill me when dates have been picked
3. Possible Topics
Important things we want to discuss: (add your own)
3.1. Tags
Multiple large users have their own overwrite of Mercurial tag system. It is worth reviewing what and why they do it and maybe make plan to improve the situation accordingly.
3.2. Releases
Right now durin42 is doing all the releases, and has some help doing release notes. It'd be nice to have others start rolling releases. Is anyone interested? Can we automate this more?
3.3. Shelve using archived phase
What needs to be done to get this to replace current shelve?
3.4. Replication-friendly repository format
durin42 is interested in (and has a handwave of a design for) a storage layer that would be replication-friendly. Basically, "how could we restructure repo storage so that it would be safe to put in {Dropbox,CIFS,etc}"?
3.5. Combined revlog
(added by Pierre-YvesDavid, this is orthogonal to the previous format proposal)
Storing multiple files history into the same filelog could help our disk footsprint and performance.
It "just" mean to add an extra "key" to address content, logic to find the right filelog and some logic adjustement through the code.
I have no hard plan yet, but I wanted to discuss that more broadly.
3.6. More command "namespace"
Right now we have the normal namespace and the "debug" namespace. It would be useful to have a couple more explicit namespace with their own guarantee. For example one dedicated to maintenance command (debugupdatecache, debugrebuildstate, debugupgraderepo, etc…) and one for other tooling (eg: debugcompletion)
3.7. Google's --changeset-as-wdir feature
Multiple contributors from google are trying to have various existing commands being able to consider a revision in place of the working copy. This is an interesting and powerful idea that is worth discussing in greater length. See plan page.
3.8. Demo of Martin's experimental VCS
Martin von Zweigbergk: I have been working on an experimental VCS roughly since the last sprint (mostly in my spare time). It's not compatible with Mercurial, but maybe it will still be interesting to for Mercurial developers to see.
3.9. Dropping Python 2
When do we do it? Do we drop everything compat that is not 3.5.4+? Are we waiting on PyOxidizer?
3.10. State of Rust
- Discuss the current state of the project and what the features underway will become in a few months. - Discuss merging or not merging rhg/chg/hg with the help of PyOxidizer
3.11. Mercurial layered architecture
Alphare: slowly refactoring Mercurial into a two-layer codebase is something I've been thinking about over the past few months since the Rust implementation has adopted this split of core + consumer from the get-go. This is not a call to change everything right now but more of a "what do you think about this as a general direction in the next few years?".
3.12. Testing systems
gracinet: I've been experimenting with Python integration tests for extensions. I'm really satisfied with the results. I'd like to share the experience with the project, and I think it could be really useful in the core as well. Will give more details in IntegrationTestsPlan as a basis for discussion.
3.13. Using MMap More
Mostly things discussed in https://www.mercurial-scm.org/wiki/MMapPlan. What kind of format do we need to move toward to use more of mmap, and do we agree to get there.
3.14. General performance discussion
Exchanging around current performance bottleneck and what kind of option we have to solve them
3.15. --auto-shelve flag (similar to --autostash in git) for write commands
A flag to automatically perform "hg shelve; hg actual_command; hg unshelve"
3.16. Packaging / TortoiseHg
mharbison: Maybe this is at least partially covered by the release and py2 topics. Can we get Windows and macOS signing certificates, and sign the installers/*.app? Can we get automated release builds when it's finally ported to py3? Any interest in helping to port to py3? Can we get the tortoisehg.org domain when it expires?
4. Who is interested in which topics?
People are ordered by time zone.
|
MvZ |
RDB |
DH |
GS |
JSi |
AF |
MH |
VGB |
JSo |
MJ |
MD |
PYD |
RG |
AC |
GR |
PG |
SK |
YN |
Tags |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Releases |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Shelve using archived phase |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Replication-friendly repository format |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Combined revlog |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
More command "namespace" |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Google's --changeset-as-wdir feature |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Demo of Martin's experimental VCS |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dropping Python 2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
State of Rust |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Mercurial layered architecture |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Testing systems |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Using MMap More |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Performance |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--auto-shelve |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Packaging / TortoiseHg |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5. Sprint Notes
General overview:
The table below is an attempt to gather written summary of discussion
Session theme |
notes/result |
People who know what happened |