At Mon, 3 Nov 2025 14:58:20 -0800, Elliott Mitchell <ehem+netbsd%m5p.com@localhost> wrote: Subject: Re: irt: Re: Core statement on version control systems > > On Fri, Oct 31, 2025 at 01:44:35PM -0700, Greg A. Woods wrote: > > > > 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? IIUC it's not usually normal CVS commands which are the problem (though using them incorrectly by accident is often a root cause of the problem). "cvs admin" is the one potentially risky one, though many of its dangers can be controlled by restricting which users are in the "cvsadmin" group -- i.e. limiting its use to experts who should know better. The problem, as I understand it, is that people go into the CVS repository directly, behind CVS' back, and use filesystem commands, and maybe raw RCS commands, to muck with (supposedly to "fix") things. In the early days of testing the conversion from CVS it did make sense to muck about directly in the repository because there were artifacts in there, usually the result of previous mucking about, that made a clean conversion more difficult than it should be. However that should have stopped several years ago. > Until something non-CVS is the primary, > there *will* be mistakes. [[....]] > 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. Ultimately of course the usual problem is that it *is* too easy to make mistakes with CVS, and usually those mistakes are published to the world immediately. Most(all?) DVCS do indeed help eliminate this problem. > 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? Software that is stable for some specific use doesn't necessarily need a maintainer -- and indeed something responsible for a continuous migration of this sort probably shouldn't ever be upgraded unless it suffers some insufferable bug, and maybe then it should just be very carefully patched and maintained as a fork. Having an external maintainer, and some emotional need to keep up with releases, just increases risk of perturbation in the process. Anyway that's neither here nor there, nor my place to comment really. Hopefully NetBSD's use of CVS does end, sooner than later. I agree it is not _really_ tenable to continue with continuous migration from CVS to a DVCS -- it arguably wasn't even wise to let it go on this long. > 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. Hmmm.... I had not thought about that, but yes, that is a very important consideration. If I'm not mistaken something very similar was one of the major issues the FreeBSD folks had to sort out (especially since they became overly reliant on the SVN "commit number" for a wide variety of uses). There is some reliance on RCS Ids by NetBSD's development processes (e.g. how patches are specified in releng pullup tickets), but that probably has less public impact, and as such can probably withstand multiple conversions without too many headaches -- just flag days. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpgfG3PON7lo.pgp
Description: OpenPGP Digital Signature