Slashdot Mirror
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.
already aware of this?
/ 11 54242&tid=8&tid=7
http://bsd.slashdot.org/article.pl?sid=04/12/06
That was back on December 6th!
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
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.
The Army reading list
isn't just the fact that it's a dupe.
5 /1936218 - I imagine this will be changed once the admins notice . . . well, probably.
It's that the posted link, to the article that this is a dupe of, is a link into the admin interface. For the curious, right now it's https://slashdot.org/admin.pl?op=edit&sid=04/12/1
Breaking Into the Industry - A development log about starting a game studio.
And the GNU people have run to Arch with the usual zealot flair. A good comparison can be found here.
Some will always be above others. Destroy the equality today, and it will appear again tomorrow. --Ralph Waldo Emerson
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.
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.
I think your information is a bit old.
Point for point:
* Subversion deliberately uses a lot of working-copy disk space, because it's optimized for network use. (that is, it assumes that network is scarce, and disk is cheap.) It caches pristine copies of files so that lots of commands ("diff", "revert", "status") all work offline. It's a deliberate choice. Someday the developers hope to make this tradeoff configurable.
* Subversion is slower than CVS, yes, but not unusably slow. And it's faster than CVS at some things, like branching and tagging. The speed tradeoffs are amortized over the overall lifecycle of using the software. For example: it takes longer to checkout a working copy (because more data is being created on disk), but then after that, some common commands are faster than CVS as a result.
* Subversion has exposed BerkeleyDB's brittleness to end users, which is admittedly a mistake. But the Subversion team is now working closely with Sleepycat to fix these problems. And besides, there's now a whole non-database repository alternative that you can use. You can choose to avoid BDB altogether.
* You seem to be unaware that Subversion is not only able to use http://, but https:// as well, complete with server and client certificate negotiation. You can also tunnel the custom server protocol over ssh, using svn+ssh:// urls; no apache required at all, if you'd just prefer to use existing ssh accounts.
Hope this clarifies things.
Weird. My experience has been the exact opposite -- Subversion being significantly faster (but apparently partly due to increased disk usage, using local full copies; not requiring network access for doing status etc), and that with actual source code. And with binaries... well, CVS barely even works with binaries (plus big binaries can just bring down the CVS server -- needs at least twice the size of the binary on server side, contiguous memory); whereas Subversion has no trouble whatsoever.
I can't comment on ssh part, as the repositories I use are (I guess) properly configured so I just use svn+ssh indicator and things work smooth. I'm not sure if it's reasonable to blame scm on people don't configure it properly, however.
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
- 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...http://www.ie.openbsd.org/faq/faq6.html#OpenNTPD
Or if you read it, you would realize it makes rediculous patent stipulations. A license is a grant of copyrights, apache is trying to make a contract, which is a very untested and likely to be non-binding legal grey area.
CVSNT http://cvsnt.org/wiki is actively maintained and has many improvements compared to standard CVS. It is definitely worth having a look at if standard CVS does not give you what you want.
And before you start complaining: it runs on Linux as well as Windows (don't know about other *nix'es).
Unfortunately it has got a bizarre release cycle which makes it hard to figure out which versions are stable, but if you use a conservative approach and monitor the development mailinglists it can be acceptable. I have been using it successfully in a production environment for over a year without any serious problems. And we were very happy with the extended functionality, especially the improvements regarding merging between branches.
Not sure if I've understood correctly, but tunnelling as follows works ok for me:
$ ssh -N me@remotebox -L8080:svn-server:80 &
$ svn co http://localhost:8080/my-project
perl -e 'fork||print for split//,"hahahaha"'
You seem to still be complaining about configuration issues within subversion rather than subversion itself.
I am not sure what environment you live in but in mine we only have 100Mbs and everyone has 120GB HDs. The server has 1TB of raid storage with 4 network adaptors each with its own svnserve bound to it. Our project has 55,000 source files with 120 active developers. No problems here. We moved off a proprietary system that cost 750k a year to this which costs 120k a year (one devs salary). Compared to our old system, this is fast as hell. A checkout of a 4000k module takes about a minute. We even run a change request management system on the same server...
Webdav is and always will be slow, its just not an efficient protocol. You may have had problems with subversion but this sounds completely specific to the setup you work in. A properly implemented system should run very smooth. I am not jabbing, just showing subversion can be successful with the right setup.
Are you intolerant of intolerant people?
As to taking up more space than CVS, well, yes it does, but that's because it stores more information that lets the user do basic operations like rename a file - operations that are not present in CVS and are hacked around.
As to being slow compared to CVS, it is slower on some operations (such as the initial get) because it retrieves more information than the server, but consequently other operations are quicker because it already has the information.
As to database corruption and an alternate backend, there's been an alternate backend for months now.
Eh? cvs uses ssh for connecting to the server, or
l ibexec/ anoncvssh/
operates locally.
What? You're using pserver/kserver? Don't.
You can even use anoncvs to make non-anynomous
read/write accounts for users to access the CVS
repository by means of cvs server, preventing them
from directly writing into the repo.
http://mirbsd.bsdadvocacy.org/cvs.cgi/src/
My Karma isn't excellent, damn it! (And
"Even Linus doesn't use it?" He never used it.
On the other hand, large projects such as GCC and all of the *BSDs do use it, have used it for quite a while and it works quite well for them.
No, he means using CVS with the :ext: protocol which uses ssh to run a CVS process on the server and pipe data between the two.
This is similar/equivalent to using the svn+ssh:// protocol.