[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?

[Karunamon]

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.

[_kst_]

CVS still has its uses.

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

[raverbashing]

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.

[_kst_]

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.

[1ris]

I seems almost like the bsd people prefer minimalist tooling.

[rat87]

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

[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?

[oskdfjgfgg]

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.

[panzi]

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.