OpenBSD Project Will Release OpenCVS

thequbemaster writes "The OpenBSD project, responsible for OpenSSH, OpenBGPD, and OpenNTPD, has created OpenCVS, a BSD licensed implementation of CVS client and server. From the site: 'It aims to be as compatible as possible with other CVS implementations, except when particular features reduce the overall security of the system. The OpenCVS project was started after discussions regarding the latest GNU CVS vulnerabilities that came out. Although CVS is widely used, its development has been mostly stagnant in the last years and many security issues have popped up, both in the implementation and in the mechanisms.' No releases are available yet. The README in the OpenCVS CVS repository states that the server is not ready yet, but looks like the client is usable." Update: 12/15 20:18 GMT by T : This project was mentioned briefly the other day, too.

Comments

Ummm.. I had to read that a few times....

[GameGod0]

The OpenCVS CVS repository?

lol

I'll have to "Check It Out"

[lottameez]

hahahahahahaha. I kill me.

Re:I'll have to "Check It Out"

[wowbagger]

I think you need to be committed.

Were we not...

[jwthompson2]

already aware of this?

http://bsd.slashdot.org/article.pl?sid=04/12/06/ 11 54242&tid=8&tid=7

That was back on December 6th!

What is wrong with subversion?

[Yaa 101]

What is wrong with subversion?

Re:What is wrong with subversion?

[chroot_james]

This is the OpenBSD team. Not a bunch of louts. They could learn SVN overnight and write an open replacement for it in a week. Remember when they decided they didn't like ipf? They designed and implemented a new packet filter that was _better_ in barely any time at all.

With their vigilance, they'd clearly go with which ever they thought was better.

Re:What is wrong with subversion?

[Phred T. Magnificent]

Damn, where to start? In no particular order:

• Subversion uses too damn much disk space, particularly on the client (not that it's good on the server, either, but when the client is an older laptop with a 9 GB hard drive, you really notice the problem)
• Subversion is slow
• The server-side database is too easily and far too frequently corrupted or left locked by an aborted client request, resulting in ridiculous slowdown on the client side and increased administrative overhead on the server side
• Most Subversion installations are configured to work over HTTP (only). This provides all kinds of nice anti-benefits, like:
  • Eliminating key-based SSH authentication and replacing it with weak password-based HTTP "basic" authentication
  • Replacing a nice, encrypted SSH transport with plain-text HTTP
  • Making it so that in order to use Subversion over an SSH tunnel, you first have to shut down your local Apache server, modify /etc/hosts and set up the tunnel as root, because, of course, a non-root user can't tunnel port 80

The list goes on and on and on, but I'm not interested in continuing it just now. Subversion hasn't managed yet to be the worst version control system I've ever seen: that title is still held by PVCS on Windows 3.1, circa 1995. It's getting to be a close race, though.

Re:What is wrong with subversion?

[fitz]

I've just corrected the project FAQ page to no longer reflect that cvs2svn is still under development. It's now stable, under maintenance and has been used to convert many many CVS projects, including Apache HTTP Server, Mono, and more.

Re:What is wrong with subversion?

[Ragica]

I'm by no means a subversion expert, or even a daily user (i have use CVS for my daily work; but i keep my personal projects that i rarely get a chance to play with in subversion), but even I can answer most of your points.

• It isn't the most disk space efficient system; but as you point out, the laptop you are using is rather limited. For the vast majority of cases these days this is not an issue.
• Slow compared to CVS? I find just the opposite. It's very much faster for most operations. Perhaps we are using it on different types of repositories.
• The database corruption/locking is a point I will give you. In my fairly casual reading on the subject it seems even the Subversion developers will give you this point. The good news is that the underlying architecture should be portable to other storage types, and this is supposedly going to be coming eventually. On the other hand, while there have been some annoying storage issues with subversion, and I've had to fix and manually unlock the database a few times, i've never lost data.
• The fact that most "installations" work over http only is not subversion's fault. It has many methods that can be used. Personally I like https via Apache webdav. It's much more flexible for my usage. But one can set things up to use ssh transport (and you don't have to do it via apache as you seem to be).

I'm just amazed no one more knowledgeable than me has responded to these points yet. Perhaps the more hardcore users weary of answering these constant misconceptions...

Re:What is wrong with subversion?

[rudedog]

Subversion uses too damn much disk space

So what. Disk space is too cheap to develop to edge cases like your laptop.

Subversion is slow

Because it's doing a lot more things than CVS ever did. Those things are useful.

The server-side database is too easily and far too frequently corrupted or left locked

I rarely run into locked databases (on the scale of only 1 or 2 a year) and I have never seen database corruption.

Most Subversion installations are configured to work over HTTP (only).

And how is it Subversion's fault that admins don't set the installation up to use a more secure transport. We use subversion over https with a self-signed certificate. The weak point in that chain is not with subversion, it's with the local machine, and if the local machine is compromised, both subversion/https and cvs/ssh are both equally vulnerable.

The list goes on and on and on, but I'm not interested in continuing it just now

In other words, I can't think of anything other than "it won't fit on my 9GB disk", and "some people don't set it up securely".

Lamer.

Development has stagnated?

[tcopeland]

Hm. Well, maybe. There have been a couple releases this year, and the mailing list remains active.

I kind of feel that the torch is being passed on to Subversion, with no hard feelings between anyone. Lots of folks are converting over and most folks seem pretty happy with it. But CVS is still widely used and there are a bunch of of gurus who hang out on the list and answer questions.

Oh, and here's a mirror of various CVS releases if anyone needs them.

Re:Development has stagnated?

[Saeger]

Funny coincidence, but today I recieved a message from the Mambo CMS devs asking for community input on switching from CVS to Subversion:

Greetings,

We don't do this often, but it is time for a major decision to be made; and we need your input.

With the migration of MamboForge to the new server, we have the opportunity to change the source code management back-end from cvs to subversion.

Which one do you prefer? You can place your vote on the forums at:

http://forum.mamboserver.com/showthread.php ?t=24861

Regards,

The MamboForge Administration Team

The current poll results favor switching to Subversion by a wide margin.

Re:We need a new one?

[MassacrE]

"Any remaining problems"?

You obviously are unfamiliar with the CVS dungpile, err.. codebase. For instance, there is no access provider mechanism - they copied and pasted the code from the filesystem tree to make the pserver tree, then nobody thought "hey, maybe this will be a maintainability problem later?"

There is also no application-level interface to CVS. CVS tools typically use regexp or other parsing techniques to invoke the CVS command-line and parse its contents.

If this causes a slower transition to Subversion, it will be because people don't need to run away from the existing CVS implementation screaming anymore. A good implementation of CVS will put the emphasis of subversion right where it should be - adding compelling features which will convince people to move to it.

As far as 'less interoperability between operating systems' is concerned, I do not see why this would be restricted to BSD systems, any more than openssh was.

Re:In related news...

[upsidedown_duck]

The OpenBSD folks would re-implement GCC in a heartbeat, if they could afford the man-years to do so.

Re:Berkley db?

[ishmalius]

This is no longer a necessity. There is a filesystem-oriented repository format now. We have been using it for over a month now with no problems.