Re: irt: Re: Core statement on version control systems

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

On Wed, Sep 24, 2025 at 01:47:07PM -0700, Greg A. Woods wrote:
> At Mon, 22 Sep 2025 18:20:30 -0700, Elliott Mitchell <ehem+netbsd%m5p.com@localhost> wrote:
> >
> > On Mon, Sep 22, 2025 at 09:53:31AM +0200, Martin Husemann wrote:
> > > On Mon, Sep 22, 2025 at 04:31:07AM +0000, David Holland wrote:
> > > > On Mon, Sep 15, 2025 at 08:07:25PM -0700, Elliott Mitchell wrote:
> > > >
> > > >  > I was going to suggest the only way for Mercurial to have a future was to
> > > >  > adopt Git's file formats and network protocol.
> > > >
> > > > You can't adopt Git's file format and data model without also adopting
> > > > its core design defects and inherent problems. Nonstarter.
> > >
> > > Indeed.
> >
> > My primary concern is security.  CVS got security updates after its
> > development branch stalled.  For Mercurial this means NetBSD will need to
> > track updates.  This also allows for updating Python which has its own
> > updates.
> 
> I think that's an important point, but perhaps it's only a longer-term
> issue.

Since NetBSD has been on CVS for 30 years rather long term thinking seems
appropriate here.  I fully expect the Mercurial project to deprecated its
repository format within a decade.  At which point NetBSD will be forced
to use a Git repository as the primary.

> Personally I think there's another "nonstarter" aspect here that's been
> missed or ignored or at least not widely enough addressed.  I talked to
> Cryo about this at the last two BSDcan conferences, but I've been lax at
> moving forward on his suggestions to discuss it more widely, so maybe
> this is a good point to jump in.
> 
> That's the git(hub) "pull request" issue.

I agree with this view.  There are multiple public Git servers which have
similar functionality.  This is an excellent way to attract new
developers.  I will state GitHub's pull request review system is less
than wonderful (perhaps even terrible), but it does bring in more
contributors.

There might be a few equivalents for Mercurial, but those are tiny
compared to smaller Git-based servers.  The real issue is network effects
have strongly kicked in for Git, and the lead is insurmountable.

What may displace the Git repository format in the future is some drastic
change in version control software.  The change from client-server
(CVS/Subversion) to peer-to-peer (Git/Mercurial) was a massive change.
Now I wonder what the next such dramatic change will be?  *That* is when
something could displace Git.


On Wed, Sep 24, 2025 at 04:10:11PM +0000, David Holland wrote:
> On Mon, Sep 22, 2025 at 06:20:30PM -0700, Elliott Mitchell wrote:
>  > > > You can't adopt Git's file format and data model without also adopting
>  > > > its core design defects and inherent problems. Nonstarter.
>  > > 
>  > > Indeed.
>  > 
>  > So the thing documented here:
>  > https://wiki.mercurial-scm.org/GitExtension
>  > 
>  > Is a fantasy since such is impossible?
> 
> That's a converter. Converters are a different proposition entirely.

Insisting on different terms doesn't help discussion.

Without a doubt it is correct to call this a converter.  It is converting
back and forth between Mercurial's Python-based in-memory representation
of repository data and Git's repository format.

This is similar to the supportted backend which converts back and forth
between Mercurial's Python-based in-memory representation of repository
data and Mercurial's repository format.

As noted by Josef 'Jeff' Sipek the interface point for this wasn't
originally designed for this purpose.  As a result the performance isn't
great and may resemble a repository conversion tool.  As time goes on
the interface will evolve to better fill this purpose and performance
will increase.

> Also, perhaps you should read up on what the issues are before
> spouting off. It's all been hashed out a bazillion times before
> because new git advocates appear regularly.

Constantine A. Murenin already brought up one issue with this statement.

Beyond that though, could you read your own statement?  Realizee it
should seem quite concerning.

"new git advocates appear regularly"

Most people who didn't want to touch elderly CVS would simply avoid
NetBSD development.  Only people who care ebout NetBSD will bother
calling out NetBSD should be moving away from CVS.  If you're noticing
so many people advocating Git, you're stating most people who join
the NetBSD project already know how to use Git and none understand
Mercurial.

In turn this means everyone who prefers Mercurial is already with NetBSD.
Everyone joining almost certainly pefers Git or at least already knows
how to use it.  In different terms it seems you're glossing over an
overwhelming majority who prefer Git over Mercurial.


Another way to think of the situation is this.  Think of the time period
of around 2000-2005.

The Git repository format seems to be in SMTP's position of 2000-2005.
There are dozens, if not hundreds of implementations which are completely
independent of Git itself.

Git might be comparable to Sendmail's position in 2000-2005.  It is the
first implementation, but there are many viable alternatives.

I guess Mercurial's repository format might be UUCP's position in this
time-frame.

I'm unsure where to place Mercurial itself though.  I think there is a
good chance Mercurial itself will survive, as a front-end for use with
Git-format repositories.



Having typed all this I wonder how much it is worth advocating for moving
to Git as the primary repository.  I wonder whether it might be better to
stay out of the way and simply let Mercurial terminating support for its
repository format to force the move to Git.  Certainly this would be
simpler, but it means 2-10 years of commit hashes will be unusuable in
the future (references in commit messages will be invalid).

It doesn't take a prophet to forsee this.  Looking at the use curves make
it pretty clear what the future will be.


-- 
(\___(\___(\______          --=> 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