On 1/26/20 8:57 PM, Joerg Sonnenberger wrote:
On Wed, Jan 15, 2020 at 05:53:06PM +0100, Raphaël Gomès wrote:
Right now I can see the following high level steps
- Update the core code to be able to deal with multiple hashing
functions
- Update the network protocol to deal with multiple hashing functions
- Update the on-disk format to deal with larger hashes
- How to deal with backwards and forwards compatibility with regards to
both repositories and client/server (wire protocol changes, etc.)
- How changing hashing functions impacts the user experience (from
additional steps to UI getting broken)
- Help extensions to migrate if need be
- Actually select a new hash function
Am I missing anything? How do you all feel about this?
I'd like to take a step back and start from the needs to be supported.
(1) It must be possible to create a new repository that uses a modern
cryptographic hash function both on-disk and when communicating with
other servers.
(2) It must be possible to migrate an existing repository without
invalidating references to commits. It should allow as much
interoperability with old wire clients as possible, at the very least pull
support and optionally write support. It should not be necessary to
support direct repository access from old clients. It must be possible
to schedule the migration on the timeframe of the user, not enforced as
part of an update.
The most important implication is that we need to get support for
secondary identifiers. That's the one big part currently missing in
revlog. With that in place, a lot of the other things follow as they can
transparently convert old and new node references.
I think it is important to not try to solve this questions while setting
up a grant request. The grant request should prepare time to think and
solves these questions, but that grant need to be finalized by Friday
(and Raphaël is Off today, (happy birthday Raphaël)). So we should plan
to solve theses questions, but not make it a pre-requires.
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
