Why are people so obsessed with getting the OpenBSD developers to move from CVS? If it works for them and do what they need there's no need to move.

Because people might be interested to review their changes, and CVS makes that very difficult.

How so? CVS do make branching and merging rather annoying, but I don't see how reviewing changes becomes difficult. It's a lot easier to track the changes to the entire OpenBSD source three, compared to the Linux kernel.

Git and Mercurial are extremely nice tools, but the flow of patches and branches quickly become rather hard to follow. CVS doesn't have most of the features that newer tools have, so there's stuff you simply can't do, but it is extremely easy to follow the code.

There's many problems that makes it very annoying to review their changes:

- CVS commits are per file. You can't see changes made by a single commit to multiple files.

- CVS cannot rename files. You have to create a new file and remove the old one. So you cannot follow history of the changes.

- CVS is really slow. You cannot clone the repository locally, so it takes a few seconds to show any change, whereas git shows you any commit and logs instantly. And you can't do it offline (for instance if you need to spend a few hours in a train).

- git log / show / diff is so much better than cvs log / diff.

- you can't use things like git blame

- they've lost all openssl.org history. If they were using git, they could have cloned the openssl git repository, and add their commits on top, keeping all history (which is often very useful when you're trying to understand why something has been done like this, or who introduced some change).

I'm not an openssl expert, so I didn't plan to review their changes anyway. But if I had to, using CVS would be the most annoying thing.

> I'm not an openssl expert, so I didn't plan to review their changes anyway

Bad excuse. Now if you said you don't know C at all, that'd be reasonable.

> But if I had to, using CVS would be the most annoying thing.

There's freshbsd, cgit on anoncvs, probably a git repo or two on github. You don't need to touch CVS to view the code and diffs. Blaming the VCS that much is a bunch of lazy excuses. Yes, CVS has its shortcomings. No it doesn't make code review difficult.

> Blaming the VCS that much is a bunch of lazy excuses.

I'm not blaming CVS as an excuse, because as I said, I didn't plan to review it anyway.

> No it doesn't make code review difficult.

It does make code review difficult, for all the reasons I gave. And I've seen several people who try review it complain about that too.

For security reasons.

It is possible with CVS and even SVN to insert bad code on their repository server - but with git thats a much harder if not impossible to do.

Can you explain how this attack works, or provide a link?

Lets assume somehow you as attacker got access to the box where their CVS process is running.

Now you can edit a file, insert a line or change a "uid != 0" to "uid = 0", you also edit the history of the CVS repistory to make it seem that this change was introduced with some patch 3 years ago by Theo. Because its CVS or SVN the history is in the server, and not on every developers computers. Next time the devs build the tar.gz for distribution your bug is in it.

This wont be allowed with Git or Mercurial, because if you try to rewrite the history, well good luck making a SHA-1 collision on source files. That stops it.

Ah that makes sense. Thanks!!

Well, we're all waiting for you to write a BSD licensed git/hg replacement that has decent performance on a VAX.

I can't speak for them, but I think if you're not sold on git/mercurial then you have CVS and SVN as obvious choices. And those two aren't that different (pros/cons explained: http://www.pushok.com/software/svn-vscvs.html ... edit: that's a very old link)

Contains stuff like "SVN not yet so widly used, as the result there are places where it support still not implemented."

Very old indeed.