3.6 Sprint

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

1. Date and location

The sprint took place from Friday October 23rd (9am) to Sunday 25th evening.

The location is

  Facebook London
  10 Brock St,
  London NW1 3FG,
  United Kingdom

2. Attendees

3. Sponsors

We will probably need to find some funds to get flights and hotel for a few independent contributors.

4. Possible Topics

Important things we want to discuss:

• Book (Mathiasdm, marmoute)
• Mandatory discussion about putting extensions in core (marmoute)
• upgrading store requirements during clone (indygreg, durin42)
• cg3 format (durin42, spectral)
• feature branch workflow (ryanmce, durin42, marmoute, smf)
• "packed revlog" repositories (indygreg, durin42)
• SHA-1

• CommitSigningPlan

• Improving blame (indygreg)

5. Bulk Bikeshedding

Name and details we want to fight over:

• changing default destination for various commands [update, rebase] (marmoute)

6. Notes

The sprint has happened.

Here is a raw copy of the sprint etherpad.

Prioritized list for Sunday
===========================

    Handling tree conflicts (mads, sid0, foozy, mpm, ryanmce iff no sid0)

    case collision for files/directories (issue4892, issue29, etc)

    updating across symlink changes

    Notes: https://titanpad.com/hg36sprint-colliSions

    Working copy sync (sid0, wez, adgar)

    https://docs.google.com/document/d/1cCr21ICMwllg7AonQig1yLWmjmlnyXOivJRY_k1bXFk/edit?usp=sharing

    general delta on by default (indygreg, mads, spectral)


proposed morning agenda:

CommitSigningPlan || TreeConflicts
Histedit || Working Copy Sync || GeneralDelta

Topics:

Discussed:

    Book (Mathiasdm, marmoute, mpm, indygreg, foozy) 

    CommitSigningPlan // secondary user/date (marmoute,indygreg,mpm,durin42,adgar)

    history editing UI needs (ryanmce, durin42, marmoute, mitrandir77)

    upgrading store requirements during clone (indygreg, durin42, mads)

    allow upgrade on empty repo (more allowed later) (AI: durin42)

    cg3 format (durin42, spectral, indygreg, mads)

    moving to revlog part in bundle2 instead (AI: durin42)

    "packed revlog" repositories (indygreg, durin42, mads, Mathiasdm)

    SHA-1

    drop the last nybble of sha256 and use that to flag hash version

    allows room for eventual sha3/whatever

    changing default destination of update/rebase etc (marmoute,ryanmce)

    https://www.mercurial-scm.org/wiki/DefaultDestinationPlan

    Going to reconcile default destination for merge and rebase (AI: marmoute)

    feature branch workflow (ryanmce, durin42, marmoute, smf, mads, erik, ezquerra,spectral, mitrandir77)

    see summary below

    wip / smartlog / "my changesets" functionality in core / hgext (indygreg)

    Yes. (AI: indygreg? / maybe ryanmce tbd)

    in repo technical docs (indygreg, durin42)

    Yes. Part of `hg help`.

    relation operator for revsets

    Basic number bits for sure, extended syntax to be bikeshod (AI: mpm)

    Richer alias syntax (spectral, durin42, ryanmce)

    discussed on Friday, but no real result. Need for Windows users in particular acknowledged, but solution isn't immediately obvious.



Remaining topics:
=================

    (more discovery) (marmoute, mads, indygreg)

    specific context: lots of heads / branches

    Multiple data, changesets, branch, obsmarker, phases

    Improving blame (indygreg, durin42, mads, av6) 

    perhaps related: Improved support for meta (review) comments, moving as history is modified (mads,adgar)

    subrepo "cache" (ezquerra)

    tortoisehg graph improvements (ezquerra, yuya, mads)

    tortoisehg on OSX retina displays (ezquerra, yuya)

    revision "labels"(ezquerra, sean, durin42, mads)

    'hg log --removed' (Mathiasdm)

    copy tracing plan at Facebook (ryanmce)

    wheels / hackable mercurial

    obsmarker discovery (we have plans! marmoute)

    Mandatory discussion about review workflow (marmoute, ryanmce)

    Mandatory discussion about putting extensions in core (marmoute, ryanmce)

    IRC signal-to-noise ratio (mads, spectral)

    Pypy support?





Feature Branch Discussion Summary
=================================

Action Items:
* topics moving to evolve
* topics will follow wiki
* active() revset (and template)
* change 'hg up' not to move bookmarks
* 'hg up -B .' (active bookmark moves) 
* 'hg up -B foo -r HASH'
* kill (fix) divergent bookmarks on sight
* remotenames getting polished and moved to core (no ui)
  * remotename repo to split one extension into many 
       (remote branches, remote bookmarks, journal, tracking, etc.)
  * journal into remotenames
  * tracking as an extension
* more generic renaming of a branch 
      ('hg branch --change $REVSET new-name')
* core to have server hooks / example hooks
  * reject anon heads
  * reject file names
  * reject file size
  * reject file contents (eg "DO NOT SUBMIT")

Undecided:
* Warn about lack of "@" bookmark during creation of first bookmark
  * counterpoint: if users then forget to advance "@", this 
    is worse than not having it
  * deleting bookmarks and escaping from a poor tool fit becomes harder


========================================
Commit Signing and Additional Attributes
========================================

Level 0

    Committer (committed by)

    Commit date

Level 1

    rebase / graft / amend / rewriter person and date

    "Who changed it" chain

Level 2

    Cryptographic verifiability of levels 0 and 1


Workflow
1. A commits. Get user + date like today
2. Imported and modified by B
3. sig0: author=B date=XXX
4. Sent to C for review
5. sig1: author=C date=XXX reviewed=true
6. Consumed by test automation
7. sig2: author=TESTER date=XXX tested=true

We can have assertions about what the signatures mean. Marmoute can say "reviewed=true" in his signature. So "signatures" are who+date + additional metadata. The series of signatures constitute an audit/custody chain.

*Author values in signatures should use stricter / well-formed syntax "Patch Author <author@example.com>"* (mpm agrees)

(No crypto so far)

Now we add crypto. We have a commit with a hash $HASH. If initial author wants to do crypto, she does

sig0: author=alice hash=$hash gpgsig=$(sign hash)

hash contains:

    commit user

    commit date

    commit message

    commit parents

    manifest hash


Bob imports the change, wants to sign it too. He signs 
sig1: author=bob oldhash=$hash hash=$newhash gpgsig=$(sign newhash)

If Bob needs to amend the change after this, instead of putting a sig2, he replaces his sig1 with a new sig2.

sig0 is optional. It only exists in the crypto mode. sig0 author/date always match the patch.

(adgar signed up to own writing an AuditTrailPlan wiki page and work on the plumbing to make built-in commands produce signatures)

crypto assertions we may want: manifest was $blah, subtree state was $blah, etc. Mozilla in particular needs to have strong signatures on their security-sensitive code, but doesn't want to enforce signing on everything and have single point of attack for "autoland" machine that performs rebases and invalidates manifest hash.

====================
History Editing Plan
====================
Better verbosity for histedit (print line before running each aciton).
    maybe disable-able?
recover invalid rules
    better hint to tell user where the old rules are
delete a line to drop
    boolean to enable feature, mention it in abort hint
inserting a commit from outside the histedited set
    strip obsmarkers on abort
    read obsmarkers on --continue to recover start
    pick can accept hashes *only*
        option 1: don't document so it's BC-able
        option 2: abort with hint, hide behind experimental knob
    prefer option 2
exec and stop
    fix semantics, move to core and expose them iff evolve is on
abort --keep
rebase -i
    counterproposal: new "base" verb that can split stacks
    enhancement: "picks" verb that lets you use a revset to select
        things quickly (eg for splitting topics into discrete stacks)
        
        example:
        base @
        picks topic(foo)
        base @
        picks topic(bar)
        base @
        picks topic(baz)

        histedit has an internal "unused" revset that is things not 
        used. The "picks" revset has an implicit "and histedited-set" 
        on each revset?
        
        OPEN QUESTION: what happens when multiple picks match the 
        same set? Gut reaction is to drop it, but not 
        immediately clear that this is correct.
templatable histedit action lines
    (that is, the part after "verb hash")

Generaldelta
============

format.generaldelta = {true, push, accept, false} (accept default in 3.7). Dest always applies what it sees. So no re-encoding on either peer.

bundle2 output part saying "generaldelta isn't enabled on your client when server has it." Client w/ generaldelta enabled filters output part so client doesn't see it. This way 3.5 and 3.6 see warnings when server upgrades to generaldelta.

Server-side option to disable non-bundle2 responses. Locks out <3.5 clients and guarantees all clients can speak bundle2/cg2/generaldelta.

Upgrade generaldelta command: re-encodes manifest (+filelogs?). Sets generaldelta flag on manifest (+revlogs) without re-encoding.

Book
====

* License change is fine with Bryan (CC BY-SA)
* Idea: integrate the book into the hg repository under 'docs'
* Text will be converted to rst, examples to .t-tests
* Images to ASCII (to be processed with dagmatic or ascii2svg(?)
* Book to be built with Sphinx (later possibly ported to the hg internal rst parser)

---

CategoryMeetings