[Kikawala]

From the README:

Development is done in the upstream OpenBSD codebase. A github clone of the official repositories is kept at: https://github.com/libressl-portable We update this repository from the OpenBSD respositories semi-frequently, so changes may not show up in GitHub immediately. The GitHub repository should be used for informational purposes only.

[raverbashing]

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

Really, not having atomic commits is a pain

[forgottenpass]

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

[Karunamon]

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.

[LukeShu]

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.

[Karunamon]

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.

[LukeShu]

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.

[vezzy-fnord]

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?

[panzi]

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?

[forgottenpass]

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

[JoshTriplett]

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.

[pling]

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.

[hobarrera]

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.

[clarry]

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

[steveklabnik]

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

[tedunangst]

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

[Natsu]

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

[stal]

they use a shitty BSD clone called Open CVS

[tedunangst]

Or not.

[stal]

yes they do