7 ms·

It is simple, they know it well and it works. Just like C89.

by w8rbt 8y ago

ksec 8y ago
That was my first thought as well, then I realise CVS is not maintained for more then a decade. I know not everyone likes Git but wouldn't SVN be a better solution.
- toast0 8y ago
  > CVS is not maintained for more then a decade Have you considered CVS may have been finished for over a decade? OpenBSD has been using it for a long time, and it clearly meets their needs, or they'd chose from one of the many other choices. In my own experience, it's nice to use finished software, step off of the upgrade treadmill, and get to the end of the learning curve.
  - atonse 8y ago
    Are you suggesting that there is nothing about CVS that frustrates its users? Surely there is always room for improvement, even if for performance reasons. Feature bloat, totally agree. But even for bug fixes and performance improvements, I have a hard time believing this is truly finished.
    - toast0 8y ago
      I suspect that any remaining user frustrations are either issues with fundamentals of the design, impossible to fix without frustrating other users, or don't rise up to the level of a bug report, let alone a patch. Based on the timeline of CVS, I doubt there are that many large performance issues that can be fixed without significant risk of breaking. In my experience, CVS was primarily limited by network and disk I/O, both if which ate generally much improved since the time of active CVS development. Keep in mind that the effective scope of CVS is also shrinking as many users move on to other software; that means any issues are less likely to surface.
  - deleted 8y ago
    [deleted]
- krylon 8y ago
  I vaguely remember the OpenBSD people started a rewrite of CVS at one point. I am not sure where that went, but looking at other things they have rewritten (NTP, SMTP, HTTP, ...), I would be surprised if that did not work out.
  - foodstances 8y ago
    https://www.openbsd.org/opencvs/index.html https://www.openbsd.org/opencvs/index.html
- hoistbypetard 8y ago
  The OpenBSD project maintains its own fork: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cvs/ https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cvs/ It's not especially active, but you can see the last change sets were in the past year, so "not maintained for more than a decade" doesn't apply to what they're using.
  - foodstances 8y ago
    That is not a fork, that is OpenCVS which is a brand new, from-scratch implementation. It's not yet being used to host the OpenBSD code (but some AnonCVS mirrors use it). The CVS that OpenBSD uses is still GNU CVS - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/cvs/ https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/cv...
    - hoistbypetard 8y ago
      Looking at my local system, you're exactly right. /usr/bin/cvs is still GNU CVS, and you have to explicitly use /usr/bin/opencvs to get this. I thought I remembered -current moving to opencvs some time ago, but either I mis-remembered or they moved back.

It is simple, they know it well and it works. Just like C89.

by w8rbt 8y ago

It is simple, they know it well and it works. Just like C89.

ksec 8y ago

That was my first thought as well, then I realise CVS is not maintained for more then a decade. I know not everyone likes Git but wouldn't SVN be a better solution.

toast0 8y ago
> CVS is not maintained for more then a decade Have you considered CVS may have been finished for over a decade? OpenBSD has been using it for a long time, and it clearly meets their needs, or they'd chose from one of the many other choices. In my own experience, it's nice to use finished software, step off of the upgrade treadmill, and get to the end of the learning curve.
- atonse 8y ago
  Are you suggesting that there is nothing about CVS that frustrates its users? Surely there is always room for improvement, even if for performance reasons. Feature bloat, totally agree. But even for bug fixes and performance improvements, I have a hard time believing this is truly finished.
  - toast0 8y ago
    I suspect that any remaining user frustrations are either issues with fundamentals of the design, impossible to fix without frustrating other users, or don't rise up to the level of a bug report, let alone a patch. Based on the timeline of CVS, I doubt there are that many large performance issues that can be fixed without significant risk of breaking. In my experience, CVS was primarily limited by network and disk I/O, both if which ate generally much improved since the time of active CVS development. Keep in mind that the effective scope of CVS is also shrinking as many users move on to other software; that means any issues are less likely to surface.
- deleted 8y ago
  [deleted]
krylon 8y ago
I vaguely remember the OpenBSD people started a rewrite of CVS at one point. I am not sure where that went, but looking at other things they have rewritten (NTP, SMTP, HTTP, ...), I would be surprised if that did not work out.
- foodstances 8y ago
  https://www.openbsd.org/opencvs/index.html https://www.openbsd.org/opencvs/index.html
hoistbypetard 8y ago
The OpenBSD project maintains its own fork: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cvs/ https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cvs/ It's not especially active, but you can see the last change sets were in the past year, so "not maintained for more than a decade" doesn't apply to what they're using.
- foodstances 8y ago
  That is not a fork, that is OpenCVS which is a brand new, from-scratch implementation. It's not yet being used to host the OpenBSD code (but some AnonCVS mirrors use it). The CVS that OpenBSD uses is still GNU CVS - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/cvs/ https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/cv...
  - hoistbypetard 8y ago
    Looking at my local system, you're exactly right. /usr/bin/cvs is still GNU CVS, and you have to explicitly use /usr/bin/opencvs to get this. I thought I remembered -current moving to opencvs some time ago, but either I mis-remembered or they moved back.