4 ms·

CVS may be "bad", but it's clearly working for the OpenBSD project and they have released roughly every six months like clockwork.

oblio 7y ago
Things can go on for very long periods of time until they suddenly burst. What happens when the current developers retire? I doubt there's any software dev born in 1990 and later that wants to touch CVS, especially for a hobby project.
- busterarm 7y ago
  Except OpenBSD gets new contributors all the time. A decent number are in uni or grad school, which basically contradicts your suggestion entirely. We contribute to OpenBSD because we care about the goals of the project and that motivates learning and dealing with CVS.
- Crinus 7y ago
  You make it sound like CVS kills children. People worked with CVS just fine for decades and OpenBSD has made their own tools for CVS to improve their development experience and, frankly, if a developer - regardless of age, lets not get into age discrimination here - finds CVS a roadblock to working on OpenBSD, they are simply not a good developer.
  - microcolonel 7y ago
    > If a developer - regardless of age, lets not get into age discrimination here - finds CVS a roadblock to working on OpenBSD, they are simply not a good developer. While we're at it, if a developer finds ed (the standard text editor) a roadblock to working on OpenBSD, they are simply not a good developer. Why is somebody "not a good developer" if they don't want to work with tools which are an insult to the priorities and humanity of the user†, for no good reason, when they could go to Linux and have 99% of what's good about OpenBSD, without the cult of GCC 4.2-justifying, CVS masochists? I love OpenBSD, but the self-defeating goober decisions clearly reduce the number of people willing to become the experts needed to push the project forward. So much of OpenBSD is user-friendly, as long as that user reads the manual; but CVS is among the most user-hostile version control systems any living developer remembers using, and even if you know exactly what you're doing CVS is still an inconvenience because of centralization, and because of the amount of clerical work required to get it to operate properly. † In the context of a world full of spectacular alternatives; obviously this doesn't apply to a time when CVS was a cut above.
    - Crinus 7y ago
      User friendliness is not binary but a spectrum and CVS is way above being "usable", even if it isn't the most user friendly VCS out there (hint: git isn't either). It certainly is not "insult to whatever of the user". As for ed, even though i realize you're not serious, screen oriented editors replaced ed as soon as Unix could use them and Unix developers at AT&T used ed mainly because they lacked the hardware to use anything else. It should be obvious that the difference between the user friendliness of a program that shows you a real time window of the text you are editing with immediate feedback and a command line interface based editor designed for slow teletypes is much greater than the difference between two slightly different sets of commands that will be the majority of one's VCS use will be.
      - rauhl 7y ago
        > It should be obvious that the difference between the user friendliness of a program that shows you a real time window of the text you are editing with immediate feedback and a command line interface based editor designed for slow teletypes is much greater than the difference between two slightly different sets of commands that will be the majority of one's VCS use will be. I think that anyone who is familiar with CVS & Git and with ed & vi/emacs will agree that there is a similar leap forward in capability. The move from CVS to SVN is a bit like the move from vi to emacs, but the move from CVS to Git really is like the move from ed to vi, vim or emacs. I suspect that this is probably another example of the Blub effect, this time applied to VCS: the CVS user looking up at Git thinks, ‘Why would I ever need that? Besides, if I ever did I’m sure that I could roll something that was good enough,’ while the Git user looking down on CVS thinks ‘There but for the grace of God go I.’
        anjbe 7y ago
        You’re still missing what’s been stated elsewhere in the thread: that OpenBSD’s review process is VCS‐agnostic, that the project officially mirrors to GitHub, and that many developers and external contributors use the Git mirror for their work (just look on the tech@ list for how many mails have “diff --git” in the patch). Myself, I’m crazy about local branches and rebase -i. But it’s no skin off my back if the final command I run winds up being “cvs ci”.
brianpgordon 7y ago
Something can be harmful to the project without totally sinking it. "Disease may be 'bad,' but it's clearly working for humans and the population continues to skyrocket exponentially like clockwork."
- busterarm 7y ago
  Where is the proof that CVS is harming OpenBSD? As far as I know there is none. People talk about moving it to git like there is no cost to doing so and that it will provide only benefits, but as far as I've seen there's been very little justification that's a motivation more than maintaining the status quo. I mean, I personally prefer git. I've used it at work for years and I'm quite good at it. If the project is hitting its targets while on CVS, I think that's fine.
  - microcolonel 7y ago
    The cost is in opportunity. I know a number of competent developers who wanted to add something to OpenBSD (and had a good chance of succeeding), but were so put off by CVS (which is especially inconvenient if you're not already an OpenBSD maintainer) that they either stopped right there, or didn't continue after getting CVS "working". It's not that people can't use CVS, it's that nobody in their right mind would willingly suffer the personal insult of being required to use CVS, because it has basically nothing going for it, and there are so many other options. I think this is a bit of survivorship bias: CVS is working fine for the people it works fine for, but who knows? Maybe out there somewhere, there's somebody who was put off by CVS, who would otherwise have gone on to finally update the Radeon drivers for GPUs from the last five years.
    - toast0 7y ago
      Honestly, I don't see how choice of VCS matters to outside contributors. The process is almost universally get a recent checkout, make modifications and test them, then send a patch. Sending a patch with github seems more convenient for about the first 5 minutes, but you have to be really careful, because the pull requests aren't frozen like a patch in email would be (this could be good or bad, but it was unexpected to me) Certainly, version control approaches make a big difference if you're committing, but to decide not to start contributing because you wouldn't like being a committer doesn't make sense to me. Chances are, you won't become a comitter.
syntheticnature 7y ago
The biggest problem in CVS is the lack of integrity checking. A repository can have individual files go bad and have it be non-obvious for some time. Long ago, it was desired to preserve all history for a CVS->Subversion move I was involved with, and it turned out there was corruption that meant that one file could not be accessed before a certain point in the history. We wound up just doing a repository scrape instead.

oblio 7y ago

Things can go on for very long periods of time until they suddenly burst. What happens when the current developers retire? I doubt there's any software dev born in 1990 and later that wants to touch CVS, especially for a hobby project.

busterarm 7y ago
Except OpenBSD gets new contributors all the time. A decent number are in uni or grad school, which basically contradicts your suggestion entirely. We contribute to OpenBSD because we care about the goals of the project and that motivates learning and dealing with CVS.
Crinus 7y ago
You make it sound like CVS kills children. People worked with CVS just fine for decades and OpenBSD has made their own tools for CVS to improve their development experience and, frankly, if a developer - regardless of age, lets not get into age discrimination here - finds CVS a roadblock to working on OpenBSD, they are simply not a good developer.
- microcolonel 7y ago
  > If a developer - regardless of age, lets not get into age discrimination here - finds CVS a roadblock to working on OpenBSD, they are simply not a good developer. While we're at it, if a developer finds ed (the standard text editor) a roadblock to working on OpenBSD, they are simply not a good developer. Why is somebody "not a good developer" if they don't want to work with tools which are an insult to the priorities and humanity of the user†, for no good reason, when they could go to Linux and have 99% of what's good about OpenBSD, without the cult of GCC 4.2-justifying, CVS masochists? I love OpenBSD, but the self-defeating goober decisions clearly reduce the number of people willing to become the experts needed to push the project forward. So much of OpenBSD is user-friendly, as long as that user reads the manual; but CVS is among the most user-hostile version control systems any living developer remembers using, and even if you know exactly what you're doing CVS is still an inconvenience because of centralization, and because of the amount of clerical work required to get it to operate properly. † In the context of a world full of spectacular alternatives; obviously this doesn't apply to a time when CVS was a cut above.
  - Crinus 7y ago
    User friendliness is not binary but a spectrum and CVS is way above being "usable", even if it isn't the most user friendly VCS out there (hint: git isn't either). It certainly is not "insult to whatever of the user". As for ed, even though i realize you're not serious, screen oriented editors replaced ed as soon as Unix could use them and Unix developers at AT&T used ed mainly because they lacked the hardware to use anything else. It should be obvious that the difference between the user friendliness of a program that shows you a real time window of the text you are editing with immediate feedback and a command line interface based editor designed for slow teletypes is much greater than the difference between two slightly different sets of commands that will be the majority of one's VCS use will be.
    - rauhl 7y ago
      > It should be obvious that the difference between the user friendliness of a program that shows you a real time window of the text you are editing with immediate feedback and a command line interface based editor designed for slow teletypes is much greater than the difference between two slightly different sets of commands that will be the majority of one's VCS use will be. I think that anyone who is familiar with CVS & Git and with ed & vi/emacs will agree that there is a similar leap forward in capability. The move from CVS to SVN is a bit like the move from vi to emacs, but the move from CVS to Git really is like the move from ed to vi, vim or emacs. I suspect that this is probably another example of the Blub effect, this time applied to VCS: the CVS user looking up at Git thinks, ‘Why would I ever need that? Besides, if I ever did I’m sure that I could roll something that was good enough,’ while the Git user looking down on CVS thinks ‘There but for the grace of God go I.’
      - anjbe 7y ago
        You’re still missing what’s been stated elsewhere in the thread: that OpenBSD’s review process is VCS‐agnostic, that the project officially mirrors to GitHub, and that many developers and external contributors use the Git mirror for their work (just look on the tech@ list for how many mails have “diff --git” in the patch). Myself, I’m crazy about local branches and rebase -i. But it’s no skin off my back if the final command I run winds up being “cvs ci”.

brianpgordon 7y ago

Something can be harmful to the project without totally sinking it. "Disease may be 'bad,' but it's clearly working for humans and the population continues to skyrocket exponentially like clockwork."

busterarm 7y ago
Where is the proof that CVS is harming OpenBSD? As far as I know there is none. People talk about moving it to git like there is no cost to doing so and that it will provide only benefits, but as far as I've seen there's been very little justification that's a motivation more than maintaining the status quo. I mean, I personally prefer git. I've used it at work for years and I'm quite good at it. If the project is hitting its targets while on CVS, I think that's fine.
- microcolonel 7y ago
  The cost is in opportunity. I know a number of competent developers who wanted to add something to OpenBSD (and had a good chance of succeeding), but were so put off by CVS (which is especially inconvenient if you're not already an OpenBSD maintainer) that they either stopped right there, or didn't continue after getting CVS "working". It's not that people can't use CVS, it's that nobody in their right mind would willingly suffer the personal insult of being required to use CVS, because it has basically nothing going for it, and there are so many other options. I think this is a bit of survivorship bias: CVS is working fine for the people it works fine for, but who knows? Maybe out there somewhere, there's somebody who was put off by CVS, who would otherwise have gone on to finally update the Radeon drivers for GPUs from the last five years.
  - toast0 7y ago
    Honestly, I don't see how choice of VCS matters to outside contributors. The process is almost universally get a recent checkout, make modifications and test them, then send a patch. Sending a patch with github seems more convenient for about the first 5 minutes, but you have to be really careful, because the pull requests aren't frozen like a patch in email would be (this could be good or bad, but it was unexpected to me) Certainly, version control approaches make a big difference if you're committing, but to decide not to start contributing because you wouldn't like being a committer doesn't make sense to me. Chances are, you won't become a comitter.

syntheticnature 7y ago

The biggest problem in CVS is the lack of integrity checking. A repository can have individual files go bad and have it be non-obvious for some time. Long ago, it was desired to preserve all history for a CVS->Subversion move I was involved with, and it turned out there was corruption that meant that one file could not be accessed before a certain point in the history. We wound up just doing a repository scrape instead.