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

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

On Fri, Oct 31, 2025 at 01:44:35PM -0700, Greg A. Woods wrote:
> At Mon, 27 Oct 2025 17:11:24 -0700, Elliott Mitchell <ehem+netbsd%m5p.com@localhost> wrote:
> Subject: Re: irt: Re: Core statement on version control systems
> >
> > On Thu, Oct 09, 2025 at 12:51:07AM -0700, Greg A. Woods wrote:
> > >
> > > Now don't get me wrong -- I don't really care what kind of repository
> > > the official NetBSD sources are managed with, and what the core NetBSD
> > > developers want to use to do that work, just so long as there's a way to
> > > use Git as a third-party to both access the source and to collaborate
> > > with NetBSD developers.  It could even stay in CVS if everyone promised,
> > > to stop messing with the CVS repository internals such that the hashes
> > > in the continuously migrated Git DAG were GUARANTEED to remain stable
> > > forever more.
> >
> > To be truly stable, you'll need to wait for the move to the Git
> > repository format.  If stable for 2-5 years is good enough then waiting
> > for the move to Mercurial should be sufficient.  If you want stable in 10
> > years, you will need to wait for the Git transition.
> 
> I'm not sure why you say that.
> 
> All that's needed to stabilize the DAG in a scenario where CVS remains
> the authority is for the CVS repository to be off-limits from human
> interventions and for the continuous migration algorithm to be frozen
> such that it can never rewrite any part of an existing DAG.  Then it
> shouldn't matter which format is the primary target.

A promise by everyone with CVS access not to modify the CVS repository in
ways which result in changes to downstream hashes won't be worth the
paper it is written on.

The first issue is does everyone with CVS access actually know which
CVS commands are safe?  Everyone may have an inkling, but everyone will
need to experiment to truly identify the boundaries.  Until *everyone*
knows there *will* be problems.  Until something non-CVS is the primary,
there *will* be mistakes.

You're placing a great deal of faith in git-cinnabar.  While it may have
been reliable, with its maintainer disappearing is it truly safe to place
that level of faith in it?

I'm also rather concerned about a different use of the DAG.  If I mention
"3651888182ec381f95d90efbd564a207e5e17670" and "OpenZFS", you will be
able to find what I'm referencing.  In fact even the shorter
"3651888182e" is sufficient for that purpose.  The hashes are frequently
mentioned inside commit messages so Git and Mercurial disagreeing
(since their data formats/layouts are different) is a problem.

I see transitioning from Mercurial repository format to Git repository
format as inevitable.  The network effects are simply too powerful at
this point.  When that happens, any hashes derived from Mercurial will
become unusable.


> > The one trick is, why were shenanigans being done in CVS?  Similar
> > shenanigans are quite possible with Git and Mercurial, the term is
> > "rebasing".  The one trick is due to their peer-to-peer nature if enough
> > rebasing is done some prominent fork might take over...
> 
> Often the fiddling in the CVS repo seems fairly innocent on the surface
> -- sometimes it's just to fix up something like an incorrect import.
> However it seems that all too often the result can still perturb the
> hashes in the DAG and then of course it is indeed equivalent to some
> idiot doing a force-push after rebasing the main branch that everyone
> else has already previously pulled from.

Which points to the above, in order to keep the DAG stable while
continuing use of CVS, everyone *must* have a level of knowledge and
experience which no one has.

In turn this points back to the main advantage of Git and Mercurial.
They allow you to do your changes *locally* and then test before pushing
to the main repository.


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