On Mon, Jul 22, 2019 at 10:58:50AM -0400, Австин Ким wrote: > Hi, > > As someone completely new to OpenBSD the one immediate first impression that > most peculiarly sticks out like a sore thumb to me is the Project’s use of > CVS for source code management. In the class I’m taking (the one for whose > class project I just recently downloaded OpenBSD/macppc for the first time to > install on IBM PowerPC 970/970MP-based Apple G5 hardware), we all use git for > SCM which I think is typical at most universities nowadays (at least in the > U. S.). I am curious why the Project continues to use CVS and/or if > developers have in the past considered migrating the codebase to a > distributed SCM system like Mercurial which IMHO might make branching and > merging easier on developers, especially more recent developers coming out of > universities. Is it because the Project prefers using a centralized versus > distributed SCM system? Or is it just because that’s just the way it has > always been done and why change that? And would migration to something like > hg be a possibility in the future that might possibly lower the psychological > barrier of entry for newer developers? (And btw this is meant as a sincere > question with no intention to start a contentious debate; really just asking > out of curiosity because seeing CVS diffs in the mailing lists was what > visually jumped out most prominently to me for the first time; I’m sure after > spending more time with OpenBSD it could be something I could just get used > to.) > > Thanks for all the wonderful responses to my previous post which really > helped me gain a better understanding of the Project! > > All the best, > Austin > > “If you want to change the future, start living as if you’re already there.” > —Lynn Conway >
CVS is good enough for the project for various reasons: - CVS runs on old platforms with very low resources - CVS scales reasonably well enough to the size of the source tree - CVS allows updating individual subdirectories or files; this feature is used by machines building snapshots 24/7 across several CPU architectures from a single source tree - CVS allows developers and users to update their source trees to -current - CVS allows bad commits to be reverted - CVS can cherry-pick commits to -stable branches - Theo would know how to quickly fix a broken CVS repository if needed - Assuming the version control system should be part of base (I would say it should): CVS is GPLv2 and has been in base since the beginning but new GPL software is not allowed in base. The only well-known system with a BSD licence would be fossil which doesn't scale to the size of the source tree. Finding another version control system that satisfies all the above without demanding changes in the environment and processes presently surrounding CVS would not be trivial. Migrating to a different system would be very time-intensive and costly in any case as it would disrupt active developers, build machines, mirrors, and the release process. That said, OpenBSD developers aren't only using CVS. Many are using some complementary version control system locally to keep track of their own changes. They then mail out patches which get committed to CVS and synced back to their private version control systems in some way. There are various workflows developers have come up with to manage their changes: some simply save diffs generated with CVS; some use hg, git, fossil, etc. If your university class prefers using git, I'd recommend the repository at https://github.com/openbsd/src. This should be good enough for educational purposes, even though, officially, it is not supported and could break at any given moment.
