Hacker News Reader

Comment by raverbashing | Hacker News Reader

Makes me wonder why is OpenBSD still using CVS for their things.

Really, not having atomic commits is a pain

Works for them so who cares? No reason to bikeshed tools of a project you're not sending patches to anyway.

Windows XP works for some people. There are legitimate costs to operating in the past, moreso when it's a project other people rely on.

-2 for an absolutely true fact? Wow. I'm not normally one to complain about downvotes but.. seriously.

There are also significant migration costs.

They likely have a toolchain built around CVS that would have a very challenging time being migrated to git.

They also have a workflow that involves tracking file IDs as the import/export files from other projects. Git doesn't do this well.

Every change (for significant values of, err.. significant) breaks someone's workflow.

Again, XP works for many. That doesn't mean there aren't vanishingly few reasons to use it anymore. For CVS, there's the whole non-atomic changes thing, the whole no renaming files thing, no binary file support, no amending commits, no bisect (a feature which I believe sells the software even if everything else sucked), it's harder to collaborate with other users..

Holding onto objectively inferior tools due to a lack of desire to migrate because "it works for me!" is a huge plague on technology.

I think there is a much more important feature in git for OpenBSD: cryptographic hashes of all commits that depend on the parent commit (=> cryptographically hashed history). Combine that with commit signing and detecting tampering gets easy. There are reported cases where this helped the Linux kernel project detect tampering.

Or have they implemented something like this on top of CVS?

OpenBSD combines two seldom used techniques. First, not having millions of lines of code written by random untrusted people. This allows them to use the second technique, which is to actually read their code.

Well, that is not good enough. How can you proof that already read (audited) code wasn't tampered afterwards by a hacker? If you don't use cryptographic hashes you can't.

You can't really compare Windows XP and CVS. It's disingenuous.

CVS isn't deprecated. You can't say that it's fundamentally obsolete, either. It's just really primitive, compared to modern DVCS like Git and Mercurial.

But if the primitive functionality fulfills their use case, why should they switch?

Why not?

* Both are perfectly working versions of software

* Both have been obsoleted by newer, more fully featured, and more secure replacements (git cryptographically hashes its commits, cvs does not)

* Both have users that refuse to migrate from them because "it works for them", despite the benefits and impact on everyone else.

I seems almost like the bsd people prefer minimalist tooling.

CVS still has its uses.

http://stackoverflow.com/a/7871646/827263

Humm, let's see

"Unlike Git, you can check out only a subset of the repository."

Maybe useful, you can do that in SVN, also checkouts in GIT are very fast, the point may be moot.

"So I find CVS (and sometimes even RCS) convenient when the repository is a collection of largely unrelated files, and I'm more interested in tracking changes on individual files"

Ok, I guess it makes sense in this strict case (for example, a collection of config files). Apart from that, if you're wondering with version of file A works with which version of file B you lost.

"At least once, I've had to manually reconstruct a saved CVS file that had become corrupted. I'm not sure how I could have done that with SVN or Git."

They wouldn't have corrupted the file in the first place more likely... And yes there are ways to recover it.

Valid points; I never claimed that CVS is better than Git in general. I still use it for some things mostly out of habit and the fact that it's not really worth the effort of migrating (again, this is mostly for collections of files that don't depend on each other).

As for the (rare) corrupted files, I don't know what caused that. They were single-bit errors that I could correct by manually editing the *,v files. I know of no reason to assume that such errors are more or less likely with Git vs. CVS.

> CVS isn't deprecated.

Isn't it? I thought SVN was designed to be a similar but better system? Also cvs(the gpl one, not opencvs) seems to not have had any commits for several years.

Perhaps "workflow" was the wrong word. What I am talking about is fundamental to how the project manages sources.

And again, they likely also have tools built around CVS. From my understanding of OpenBSD's build system, it would ALSO require significant effort to divorce it from CVS and marry it to git.

Similarly, Arch Linux switching from SVN to git for the packages repositories is very unlikely to happen. They've discussed it a number of times, but besides all the tooling that has been written around the SVN setup, it isn't well-suited to their use case. That isn't to say that switching to git wouldn't have benefits, or that SVN is perfect, but: It would take substantial development and testing effort to make it happen, as well as ALL contributors having to change how they work (not "learn git" (all of the other repositories for Arch are git anyway), but "re-learn all the Arch-specific tools that were built around SVN, but are now built around git").

> Holding onto objectively inferior tools due to a lack of > desire to migrate because "it works for me!" is a huge > plague on technology.

That's a broken argument.

Sure, it is in the case where an organization is hanging onto SVN because none of the developers want to take the effort to switch, and that is a drag on development. But, at the same time, if it is what the developers actually chose; it's not a drag. (The "users refusing to upgrade" is also a drag on technology because of support costs; that is irrelevant here, but is a cause of much of the "must upgrade" feelings among developers)

But the opposite is also true, switching to the latest thing without actually evaluating why is also a HUGE plague on technology. Git in most aspects is a far better tool than CVS. But, there are still things that CVS and SVN are better at (managing subprojects is the biggest one). These are things that I know in Arch mostly outweigh git's benefits, and I presume the same is true of OpenBSD.

-2 for an absolutely true fact?

It's probably because, true or not, not the best argument. Other than the fact Microsoft ended support Windows XP is fine. It does the job. It's not the latest and greatest, but right to the end it was better than acceptable or tolerable, it was downright decent.

A hardware refresh at work gave me a 7 box, but I've still got my old XP box in a corner somehwere, heavily firewalled ofc now that support has ended, I remote desktop into it 5-10 times a month now for the few straglers I haven't migrated off, and its fine.

Yeah legacy does have support costs, but as I said, you're not building openbsd from source nor would you be if they were on a trendy vcs. That's why they mirror libressl on github, this is a case where they know outsiders might care. And one vcs or another you're going to the mailing list to submit a patch to them, so until you're in it, don't really matter.

I'm all for migrating to git, but at least one aspect of the OpenBSD workflow would take some serious thought to migrate: CVS supports having one giant repository containing everything (at least, as well as it supports anything else), even including project source code, whereas git really wants smaller per-project repositories that share common history with the corresponding upstreams. In light of that, migrating to git would require some non-trivial workflow changes, making it understandable that it hasn't happened in a hurry.

It depends how you work and how stable your product is. I think they are patch heavy i.e the CVS tree is used to apply patches to and that is that. CVS has some advantages then as you can pin individual file versions on a tag rather than having to fuck around merging things. Individual files might be ethernet drivers, scheduler etc because TBH the BSD codebase is a hell of a lot better decoupled and modular than most things out there.

CVS works because they didn't fuck it up.

License is one of the reasons. OpenBSD uses the BSD license, and has a strong preference for it when it comes to the base system, base tools, etc. There's no chance they'll move something so critical to GPL-licensed software.

  $ uname
  OpenBSD
  $ cvs -v

  Concurrent Versions System (CVS) 1.11.1p1 (client/server)

  Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn, 
                          Jeff Polk, and other authors

  CVS may be copied only under the terms of the GNU General Public License,
  a copy of which can be found with the CVS distribution kit.

  Specify the --help option for further information about CVS

Unfortunately CVS isn't the only GPL-licensed piece of software in OpenBSD. But slowly, one by one, these things seem to get replaced with free and better alternatives. I can imagine a future in which we're free of GPL tentacles.

My understanding is that it's BSD licensed, and works well enough.

No, it's GNU CVS, but it does work well enoughish...

they use a shitty BSD clone called Open CVS

Or not.

yes they do

You do realize who Ted Unangst is, right?

If he says "we use GNU CVS" you might consider believing him.

You might consider cross-referencing the authors of commits to the LibreSSL project with the authors of comments in this thread. You might be surprised.

Just curious, but why don't you use git?

Reply on news.ycombinator.com