Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems Programming BSD IT Technology

OpenBSD Project Will Release OpenCVS 287

Posted by timothy from the they're-big-on-that-open-thing dept.
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.
This discussion has been archived. No new comments can be posted.

OpenBSD Project Will Release OpenCVS More

OpenBSD Project Will Release OpenCVS

Comments Filter:

  • Ummm.. I had to read that a few times.... (Score:5, Funny)

    by GameGod0 ( 680382 ) on Wednesday December 15, 2004 @03:17PM (#11096154)
    The OpenCVS CVS repository?

    lol

  • I'll have to "Check It Out" (Score:5, Funny)

    by lottameez ( 816335 ) on Wednesday December 15, 2004 @03:17PM (#11096160)
    hahahahahahaha. I kill me.

  • This Article is Redundant (Score:3, Insightful)

    by Nimrangul ( 599578 ) on Wednesday December 15, 2004 @03:18PM (#11096167) Journal
    There was already an article regarding OpenCVS, and it is fairly obvious that it will be getting released, or it would not be given a Open* title and it's own site.

    Not that I mind mind you, I just didn't see why there have been to articles on OpenCVS starting up. At least this one isn't saying it was because OpenBSD hates the GPL and are trying to replace a GPL CVS system.

  • Were we not... (Score:5, Informative)

    by jwthompson2 ( 749521 ) on Wednesday December 15, 2004 @03:18PM (#11096170) Homepage
    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!

  • A great idea... (Score:2, Funny)

    by holzp ( 87423 )
    Merge the userfriendlyness of OpenBSD with the userfriendlyness of CVS!

  • What is wrong with subversion? (Score:5, Insightful)

    by Yaa 101 ( 664725 ) on Wednesday December 15, 2004 @03:19PM (#11096185) Journal
    What is wrong with subversion [tigris.org]?
    • I was about to ask the same question; the Subversion license seems to be BSD-like enough, and Subversion is a joy to use..
    • What is wrong with subversion?

      nothing. unless, of course, you already have a major project that's been using cvs. then, if you want to switch to subversion you have to retrain your development team and switch over your repository with the cvs2svn.py tool which, according to the subversion site "is still under development... only use it on a copy of your CVS repository and double check your results"

      if you're in a major production environment, that's a no go.

      • 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.
        • Not necessarily. Switching off of ipf doesn't affect -every- developer. In fact it likely affected only the developers that went off to work on a replacement.

          Assuming OpenBSD uses CVS today, then moving to a new toolset instead of mirroring the functionality of the existing tool affects -every- person who developes on OpenBSD.

          That is a far far far more acute impact. One that I know I wouldn't want to be in charge of handling. This is the kind of thing that gives IT folks nightmares ... and developers can
          • In this line of work there is always changes, new products replace old products, new unproven technologies. Otherwise we would not have innovation. That's why we have plans and QA.
            I really don't see the point of redoing CVS. It's time to grow. Better to start planning a migration to something better. CVS has way too many limitations. This isn't a tech problem but a people problem.
        • It's not just devolopers who who would be affected by the changes. Both OpenBSD and FreeBSD use cvsup [openbsd.org] to distribute updates to users.

      • Re:What is wrong with subversion? (Score:5, Informative)

        by fitz ( 2205 ) on Wednesday December 15, 2004 @03:56PM (#11096644) Homepage
        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.
      • if you want to switch to subversion you have to retrain your development team and

        Yeah, that's SUCH a HUGE effort. Instead of 'cvs update', you need to use 'svn update', instead of 'cvs commit' you do 'svn commit'... you get the picture. Subversion was specifically designed to be pretty much just drop-in replacement of CVS; its design (even beyond CLI) is pretty similar to CVS (some consider such 'compatibility' to be a bad thing, as it prevents doing some more radical improvements).

        Really, from comman

    • 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
      • I remember that old PVCS POS. It was what we used on windows 3.0 in '91-2 if I remember correctly.

        But I was wondering if you had used MKS. Obviously there is no comparision to the old PVCS, but I think it is the worst VCS in common usage.

        If I ever want to go find an example of how to make a really bad UI, I can go to MKS.
      • PVCS on Windows 3.1, circa 1995 Thanks, I had put that out of my mind
      • 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 CV
      • Subversion is slow

        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 wha

      • 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 u
        • 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, the
      • And the new PVCS is better how? It's just as bloated, horrific and impossible to use in the latest versions as it was back then.

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

        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

      • Re:What is wrong with subversion? (Score:4, Interesting)

        by rudedog ( 7339 ) <<gro.godedur> <ta> <evad>> on Wednesday December 15, 2004 @06:15PM (#11098084) Homepage
        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.
    • Well, the big problem is that there are hundreds of legacy projects and update mechanisms that currently depend on cvs. (For example, FreeBSD's cvsup.) This means that there is still a need for a secure re-write of cvs.
    • OpenCVS isn't trying to improve version control techniques, it's trying to provide an alternate implementation of CVS.

  • Mainstream (Score:2, Insightful)

    by Manan Shah ( 808049 )
    What will really put this into a mainstream enviornment is if there are some good GUI clients available for it. If an easy to use, and perhaps more importantly, cross platform GUI client is released, you can bet that the popularity will go up. Visual Source Safe (Microsoft) isn't all that great, but people still use it because CVS doesn't have a robust windows GUI client. Or at least it didn't early on and so the first impressions were not very friendly from companies looking at products where they would
    • It's not directly tied to the main CVS project, but what about TortoiseCVS [tortoisecvs.org]? Of course, there's a subversion client of the same as well, TortoiseSVN [tortoisesvn.org].

      Of course, even with the clients in a GUI form, it would still be nice to have a GUI tool for setting up and maintaining repositories as well.
      • The nicest version control GUI I have ever used is SCPlugin [tigris.org], which is a plugin for the OS X finder. It overlays a small icon in the corner of the icon of every file under version control indicating its status, and provides a context menu for performing SCM operations. There are still a few rough edges, but the integration with the finder really makes it a joy to use - SCM operations and standard file operations can be done in exactly the same way.
      • With tortoise CVS I have found, the only additional training needed to get fair CVS use from team members is that merging clashes takes time and careful thought and can't be done automatically.

        I highly recommend tortoise cvs - hey I use tortoise cvs under windows on a samba share from my colinux box (one day there will be linux CVS shell integration); and I use eclipse to edit the files.

        Sam
    • MS isn't going to sell only VSS forever, you know...check this out: Visual Studio Team System [microsoft.com]

      Xentax
    • CVS ties into pretty much any programmers IDE/Editor out there, usually as part of the stock config.

      Oh, you mean it should integrate with Microsoft's tools? Yeah, that'll happen...

  • Development has stagnated? (Score:5, Informative)

    by tcopeland ( 32225 ) * <tom@NoSPaM.thomasleecopeland.com> on Wednesday December 15, 2004 @03:21PM (#11096207) Homepage
    Hm. Well, maybe. There have been a couple releases [cvshome.org] this year, and the mailing list remains active.

    I kind of feel that the torch is being passed on to Subversion [tigris.org], 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 [cougaar.org] of various CVS releases if anyone needs them.
    • And the GNU people have run to Arch with the usual zealot flair. A good comparison can be found here [gnuarch.org].
    • "Stagnant" development is probably as much of a red-herring as "security" in this context. Either problem is addressed with far less work by contributing updates to CVS. No, I suspect that CVS was replaced because of the fact that it is distributed under the GPL, and BSD people find that somehow distasteful.

      Whatever. I'm past license wars, and the OpenBSD people can do whatever they like. Meanwhite, I'm off to learn subversion.

      • Re:Development has stagnated? (Score:2, Insightful)

        by Anonymous Coward
        Look, you posted the exact same shit the last time this was on /. and was told that it's not about licensing, it's about a critical tool (OpenBSD developers rely on CVS to get their job done) that's not secure enough. Do you understand that? If the replacement tool is being done by an OpenBSD developer, it's only natural that the chosen license is BSD.

    • Re:Development has stagnated? (Score:4, Interesting)

      by Saeger ( 456549 ) <farrellj@nOSPam.gmail.com> on Wednesday December 15, 2004 @04:07PM (#11096786) Homepage
      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.
  • Welcome to two weeks ago.

  • The best part (Score:3, Informative)

    by ZorbaTHut ( 126196 ) on Wednesday December 15, 2004 @03:22PM (#11096236) Homepage
    isn't just the fact that it's a dupe.

    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/15 /1936218 [slashdot.org] - I imagine this will be changed once the admins notice . . . well, probably.
  • ...they enable tag/update/diff/etc. by date on a branch, add a special tag like HEAD but for a given branch, and keep track of when branches have merged so that you can actually keep 2 slightly different versions in sync.
  • I like subversion [tigris.org]. why don't they? I found it easy to install the server, and the client is easier to use than cvs.

    • Re:subversion? (Score:3, Interesting)

      by TheRaven64 ( 641858 )
      Because a lot of existing infrastructure still uses CVS? In the long term, transitioning this to SVN is a good idea, and I certainly wouldn't recommend that a new project use CVS. In the mean time, however, I think the OpenBSD people feel that it would be nice to have a CVS implementation that was secure and maintainable.
    • why don't they?

      I don't care for Subversion because it is immature. I also find their ideas about a whole slew of different database backends will be a source of endless problems (who'd ever thunk that XYZ had endianness issues or that QRS can't talk to ABC). Subversion is certainly very neat, but I'd still consider commercial VC software if my business depended on having really good VC in a project.

      • I don't care for Subversion because it is immature.

        Hmmh? Care to elaborate how is it immature? (it went to 1.0 a while ago; and I haven't seen too many problems being reported).

        a whole slew of different database backends will be a source of endless problems

        Well... designing modular systems make sense, and also allow for more optimal systems for specific needs. Sometimes it's useful to have simple file system based repository (easier to debug, do low-tech integration, etc), DB-based one may be more

        • Care to elaborate how is it immature?

          Subversion is far enough along to be useful to some people, but I'm not sure if I would put a very large amount of money on the line with it. I've seen way to many new fashionable tools get adopted by overly-optimistic people only to have them come back and bite them hard. Additional layers of abstraction obscuring troubleshooting, new cure-all frameworks obscuring troubleshooting, ambitious roadmaps that will probably never be implemented, etc. are all the hallmarks
          • You're right to be cautious, but Subversion has been officially stable for a number of years now. If the benefits don't justify making a change right now, then I wouldn't bother, but if you're starting a new project, its worth considering.

            Also, such tools are a dime a dozen. How many free alternatives to CVS have come out in past few years? At least three. Most are merely academic exercises, some a little bit more than that, none have withstood the test of time, yet. If I set up a Subversion repository, n

  • Standard Disclaimer (Score:3, Funny)

    by Ann Elk ( 668880 ) on Wednesday December 15, 2004 @03:27PM (#11096299)
    This project was mentioned briefly the other day, too.

    Maybe this disclaimer should appear at the end of every article summary...

  • CVS and subversion are plauged with security vulnerabilities. I was beginning to wonder if it was ever going to stablize like apache 1.3.

    I'm extremely happy to see that the open(bsd) team is doing what it's best at.
  • No thanks, I prefer visual source safe.

  • I guess that means it still sucks compared to 95% of VC systems out there (the remaining 5% being RCS and nightly backups).
  • I just use the Open~ project to make backups whenever I edit a file.
  • ...and I'm not just talking SVN (which is quite successful at its "better CVS" goal, though I prefer Arch with its "better revision system" intent): CVSNT [cvsnt.org]

    Why it's so rarely used (with the exception of being packaged with the major CVS client GUIs on Windows), and why so few Linux distributions package it, has always been a mystery to me.

  • More power to them... (Score:3, Interesting)

    by psykocrime ( 61037 ) <mindcrime@cpphacker . c o .uk> on Wednesday December 15, 2004 @04:55PM (#11097377) Homepage Journal
    I personally think it's something of a waste to write yet another replacement for CVS, but if they feel they need it, then great. It's open-source, it's volunteer, so nobody has any business telling these people *not* to write OpenCVS.

    That said, I (and many others) consider Subversion to be the logical successor to CVS, and it seems to me that any effort spent on revision control would be better spent contributing to Subversion (or Arch maybe) instead of writing yet another version of something that's essentially obsolete.

    OTOH, if they have major disagreements with the fundamental architecture of Subversion (and I understand that some people do) then maybe it would be better to just start from scratch, and design their own vision of an ideal revision control system?

    Either way, it probably means more quality open source code, and in the long run, everybody ultimately benefits.
    • That said, I (and many others) consider Subversion to be the logical successor to CVS, and it seems to me that any effort spent on revision control would be better spent contributing to Subversion (or Arch maybe) instead of writing yet another version of something that's essentially obsolete.

      I think the core problem is that CVS has become something of a legacy tool like sed, awk, grep and sh. Many of these tools may be "obsolete" but that does not mean that we don't need secure and trustworthy versions of

  • IPv6? (Score:2)

    by isj ( 453011 )
    Does this mean that there is a chance that we will get a CVS implementation that supports IPv6 out-of-the-box? I am getting tired of patching it.

    • Re:IPv6? (Score:3, Informative)

      by mirabilos ( 219607 )
      Eh? cvs uses ssh for connecting to the server, or
      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/l ibexec/ anoncvssh/

Slashdot Top Deals

If you have a procedure with 10 parameters, you probably missed some.

Close