Hacker News Reader

Comment by atonse | Hacker News Reader

While I didn't understand most of this, any reason why they're still using CVS? Genuinely curious, I'm sure they have good reasons.

View on HN

The developer makes the code, not the tools. Some people prefer tools different to others.

You must be jealous that we're self-hosted. ;-)

I made a program called Meta-CVS in 2002 that stores a versioned directory structure with permissions and symbolic links along with the files in an ordinary CVS repository.

http://www.kylheku.com/~kaz/mcvs.html

Meta-CVS has an import feature (mcvs grab) which detects renamed files. It fixes up symlinks pointing to moved files too and such.

Meta-CVS didn't catch on widely because by the time I had it stable, CVS itself was being side tracked by newly emerging projects like SVN.

Plus people were afraid of it being written in Common Lisp.

If you're still using CVS in 2018 and not Meta-CVS, you're ridiculously backwards though. :)

The need to secure repos was identified by Karger in MULTICS evaluation. It was a requirement in TCSEC security certification. A great summary of issues is below by David A. Wheeler:

https://www.dwheeler.com/essays/scm-security.html

On top of yours, the OpenCM and Aegis programs attempted to meet some of these requirements. Most ignore them. Big, blind spot in software security.

I actually wasn't clear at all. To me, it's more about code browseability, and I've found it much easier to splunk through codebases for fun in a GitHub-like interface. (Not much to do with the developers' workflows, I suppose)

That's really where it's coming from, wasn't really trying to be snarky or anything.

If nothing else, nobody "owns" CVS. Github (and thus, effectively git by sheer mass) is now owned by Microsoft.

Your "MS owns Git" argument is silly. By analogy, Facebook and Reddit must own HTML, because they are such popular Web sites.

OpenBSD could easily use Git if they wanted to, and they'd never have to touch MS code, or an MS Web property.

If you can say "easily" for this, you can't have tried actually importing the OpenBSD CVS repository into git. cvs2gitdump doesn't do too bad of a job, but doesn't attempt tags and branches. I haven't found another conversion tool that gets anywhere close.

I'm not suggesting that CVS to Git is easy. I'm just saying that Github doesn't present any kind of barrier to adoption of Git (in any project, not just OpenBSD).

It's a PITA for any reasonably large/old CVS repo. Partly because CVS is fundamentally broke.

Your analogy is invalid. A correct analogy is that Facebook owns your photos and posts the way github owns what you push.

No, Facebook and Reddit, big as they are, don't make their own browsers and are still individually minorities in the grand scheme of the world wide web.

Git is used by a comparatively small captive audience; most git users are invested in GitHub. MS is well positioned to run their "embrace, extend, extinguish" play if they wanted to.

It works for them. Changing would be a lot of work for little benefit.

Note that there is a mirror on github at https://github.com/openbsd and to my understanding, developers who prefer git use that, but the official source tree is in CVS.

They've managed to maintain a consistent roughly-6 month release cadence since 1995. CVS is working for them, so why switch?

You could say the same abouf most stuff OpenBSD rewrites for improved security. Many of those things aren't even critical. They just do thd rewrites as part of code maintenance. Then, they use CVS instead of a high-integrity/security VCS. It's a little strange/inconsistent if compared to the general pattern of replacing old, insecure stuff.

The security of one and security of another aren't an apples to apples comparison.

The underlying security of the operating system and user applications running in it has very different risks and benefits versus the integrity of source code commits and who gets to make them.

The latter is something they're equipped to deal with without changing tools. They've decided that the costs of making that technology change aren't worth the benefits that it provides and I mostly agree.

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

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.

> 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.

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.

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.

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.

https://www.openbsd.org/opencvs/index.html

The OpenBSD project maintains its own fork:

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.

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/cv...

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.

Reply on news.ycombinator.com