irt: Re: Core statement on version control systems

[Elliott Mitchell <ehem+netbsd%m5p.com@localhost>]

NetBSD and OpenBSD had been lagging behind in repository format for a
long time and I figured it was time to get an update.  This is near the
most astonishing news possible.

My take is similar to Constantine A. Murenin's.  At this point very few
public projects aren't using Git.  I was looking at Wikipedia's
comparison of VCSs.  10 years ago most VCSs could point to at least one
large publicly known and bunches of smaller projects using the software.
5 years ago it was tilting rather heavily towards Git, but many VCSes
still had some traction.  Now almost no one uses anything besides Git.

DragonflyBSD transitioned from CVS to Git in 2009.

FreeBSD transitioned from CVS to Subversion and then to Git around 2020.

OpenBSD has not announced any plans, but the existence of "Game of Trees"
(https://www.gameoftrees.org/ https://www.gothub.org/) suggests the
OpenBSD project is thoroughly exploring the Git repository format.

pkgsrc transitioned to Git in April of 2024.  Yes, even NetBSD's own
package format uses Git.  For a building a non-trivial system from source
you already lack the option of not installing Git-compatible software.

Here is where I was going to make a prediction about the future of
Mercurial.  Turns out Josef 'Jeff' Sipek revealed what I was going to
predict was coming and made a point which I was also going to make:
https://lists.freebsd.org/archives/freebsd-hackers/2025-September/005054.html

I was going to suggest the only way for Mercurial to have a future was to
adopt Git's file formats and network protocol.  Yet if Mercurial's
developers are already working on this, it could be ready in 2 years
rather than the 5+ I was going to predict.

This though has a rather unfortunate consequence for NetBSD's use of
Mercurial.  Eventually Mercurial's traditional backend is certain to fall
into disuse and be deprecated.  Once this happens the backend is certain
to be repurposed strictly for converting to Git.

In fact there is something likely to trigger such a transition in the
near future.  Both Git and Mercurial feature hashes at their cores.
Nominally this is for integrity not security, but using a cryptographic
hash makes signing commits worthwhile.  Due to the weaknesses of SHA-160
Git announced plans to transition to SHA-256 in 2017.  The Mercurial
project announced plans to transition in January of 2025.

Git has SHA-256 repositories functioning, but hasn't yet implemented
transitioning a SHA-160 repository to SHA-256.  I think there is a good
chance Mercurial's format will never achieve SHA-256 functionality.
Instead this would serve as a good transition point for abandoning the
traditional repository format.


I am not Nostradamus and cannot see the future.  Yet here the trend is
clear.  Let me now state I was planning to make the same point Josef
'Jeff' Sipek made.  My concern is over the choice of using the Mercurial
repository format/server.  If there is a preference that strong for
Mercurial's UI, then wait 2 years for Mercurial's Git backend to be
stable.

I've noticed many people being concerned about when the hashes could be
relied on.  I must regretfully inform everyone Mercurial hashes will at
best be useful for 10 years.  They're very likely to expire in less than
5 years, but I wouldn't be certain about them lasting 2 years.

I'm rather astonished how short-sighted the decision to use Mercurial is.
If I was in the appropriate position I would be calling for a vote of
confidence.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg%m5p.com@localhost  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445