OpenBSD Journal

GNU RCS being replaced with OpenRCS

Contributed by marco on from the ungnu dept.

Joris just committed the code to replace GNU RCS with our home grown OpenRCS. This is great news for all the folks that have been enjoying GPL licensed code being removed from the tree.

Next stop... OpenCVS...

(Comments are closed)


Comments
  1. By Anonymous Coward (134.58.253.131) on

    cool!

    I didn't realize OpenCVS was making progress that fast.

    Haven't tried OpenCVS yet (maybe I should give it a go on some noncritical data sometime). How hard is it to migrate a GNU CVS repository to OpenCVS once it's ready for production use? Will the OpenCVS clients work seamlessly with GNU CVS on the server, and vice versa?

    Comments
    1. By jasper (80.60.145.215) on

      from OpenCVS.org:
      It aims to be as compatible as possible with other CVS implementations, except when particular features reduce the overall security of the system.

  2. By Matthias Kilian (84.134.10.253) on

    That's great. A small "thank you" donation's on the way (via the europe bank transfer).

  3. By Zack (68.107.130.168) on

    Is there a reason that Subversion isn't being considered instead? It has a BSD style license already.

    Or is this more of an CVS already has intertia issue?

    Comments
    1. By Nate (65.95.124.63) on

      It's already been covered, google could tell you all about it, the reader's digest version is that they want to stick with what works, but since the GNU CVS is crummy, they want to do it anew - and that random alternatives don't maintain the history of the files, something the developers don't want to lose.

    2. By Anonymous Coward (143.166.255.16) on

      And why get rid of something that works just fine?
      Why introduce a new tool that doesn add anything?
      Why make developers learn a new tool while it doesn't add anything?
      Etc etc.

      This is really a boring argument. Let's replace it! WHY?

      Comments
      1. By Anonymous Coward (70.27.15.123) on

        Subversion adds lots of stuff. Hell, CVS can't even handle renaming files, nevermind things like files being removed and replaced with directories of the same name.

        Comments
        1. By Anonymous Coward (67.64.89.177) on

          Yawn, yeah renaming is very important. Let me think about how often I have done that... Oh I remember, NEVER.

          Comments
          1. By Anonymous Coward (64.231.20.114) on

            You obviously haven't worked on many large scale projects. People who make complaints about SVN haven't given it a serious run... we made the switch about a year ago and haven't looked back since. Honestly... I couldn't ever imagine trying to work with the absolute $%^& that is CVS/RCS again. I support the effort of an unencumbered RCS/CVS clone for those who are interested in that sort of thing, I guess.

            Comments
            1. By Anonymous Coward (67.64.89.177) on

              boooooooooooring

          2. By Anonymous Coward (128.171.90.200) on

            Unfortunatly he's right, renaming happens, as does deletion of directories.

            Atomic commits would be a nice feature too, all things CVS currently lacks.

            Moving CVS trees to SVN is fairly easy as there are tools available just for that purpose, they should preserve history too, unless they are b0rked, then you just write your own.

            Trouble is I use CVS every day, have done for years, what I want is a clean and coherent versioning system, something safe and secure, then I can look at atomic commits, directory removal, file renaming etc. unless anyone can think of a reason not to add these features ?

      2. By Justin Forest (212.48.194.124) justin.forest@gmail.com on http://hex.mirkforce.net/

        You mean learning SVN takes more effort than reimplementing CVS from scratch? Are you OK? Why get rid of something that just works -- this applies to GNU CVS as well. It's all about whether you waste your time reinventing the wheel or you spend it learning (surprise: it's good for brain).

        Comments
        1. By Anonymous Coward (83.147.128.114) on

          GNU CVS is horribly broken in many ways. Have you ever even read the GNU RCS or GNU CVS source code? It's truly disgusting. Thats why there is a new implementation. Subversion does not meet the needs of the project. How many times do you people need to be smacked upside the head before you understand that? If you want to use Subversion, go right ahead. Just don't preach to other people about what tools they should be using.

          Comments
          1. By Anonymous Coward (84.160.190.54) on

            Nobody told anyone to use any tool. There is only the question, why not to use subversion. What is bad about subversion?

            Comments
            1. By Anonymous Coward (193.1.172.166) on

              As has been stated repeatedly, it doesn't suit the needs of the project. Thats whats wrong with it.

              Comments
              1. By Anonymous Coward (66.219.139.194) on

                Thanks for the very specific feedback on exactly what problems there were with it. That was immensely helpful.

                Comments
                1. By jfb (69.70.32.10) on

                  First of all, you're talking about an effort put up by about 5 people (new CVS development) versus an effort that has to be put up by EVERY developer (learning svn). Those really aren't the same. It all comes down to "if it ain't broken, don't fix it". I'm talking about the CVS system, not the GNU implementation (which is broken in many respects). OpenBSD has been using CVS for years to manage the source tree, and it has done the job fine up to this point.

                  Second of all, the main reason why we started rewriting CVS was because a bunch of security holes had been found in the GNU version. It NEVER had anything to do directly with the license (I'm really not that much of a masochist), but it is a serious bonus. Now stop whining for a second and go take a look at the Subversion code and the amount of dependencies it has. They may have started a whole new project with a bunch of "awesome" features (most of which would be useless in OpenBSD development) but the code is already starting to look like a mess.

                2. By Chris (24.76.100.162) on

                  Thanks for being able to use Google.

          2. By Anonymous Coward (156.34.213.240) on

            OpenCVS is an important project that will reverberate well beyond the OpenBSD project, IMHO. Many projects still use CVS and will continue to do so (migration == change and bother), and the GNU version has become virtually unmaintainable. Thus, even if OpenBSD switched to subversion, OpenCVS would still be a project that needed to be done. If nothing else, proactively closing opportunities to compromise codebases by some future exploit of a 'difficult to find' security problem in GNU CVS is a security-boon for all. Work on UTF8 support would be a good thing, but it is unlikely to have that much significance. The license change is merely icing.

    3. By Sacha Ligthert (83.160.140.70) on

      I'm using SVN for private use and it just works...

      Still have to read the documentation properly any time soon ;-)

  4. By Anonymous Coward (84.188.242.124) on

    Well it tries to stay compatible...

    So what neat stuff is OpenCVS only?
    Do you still have to tell CVS if you wanna commit a binary or can cvs figure out this (maybe using file..) now? (Just as example..) :-))

    So what extensions are planed or already made?! :)

    Comments
    1. By Anonymous Coward (24.226.124.161) on

      "<I>So what extensions are planed or already made?!</I>"

      I doubt that there are going to be any significant extentions in the near future. Its more important to get the basics working and working right than to frivilously start adding bells and whistles before its even ready to replace the crufty GNU version.

      Comments
      1. By Ted Walther (142.179.111.243) on http://lists.reactor-core.org/realmilk.html

        I agree that having sound, solid fundamentals are important. However, to have mass conversions to your software, it helps to have at least one nifty feature that noone else has. Possibly file renames is such a feature.

        Personally I am using darcs. It is mind-bogglingly simple and effective for the types of things I do. It will be interesting to see how much of darcs simplicity will be available under OpenCVS, eventually.

        Comments
        1. By Ted Walther (142.179.111.243) on http://lists.reactor-core.org/realmilk.html

          Apropos to OpenRCS, perhaps updating the RCS file format to include information about file ownership, permissions, symlinking, and so on would be another killer feature that people would make the switch for.

          Comments
          1. By Anonymous Coward (128.171.90.200) on

            You cannot have file ownerships and permissions stored as the files will be checked out all over the place.

            Comments
            1. By Ted Walther (142.179.111.243) on http://lists.reactor-core.org/realmilk.html

              It is true that when you check out a file you can't predict what the file ownership and permissions will be. However, knowing what the file ownership and permissions are on the developers box may be very useful in debugging, especially permissions. The information wouldn't be there to be slavishly followed, but to show their state in a working source tree. I think putting ownership, permissions, and symlinking info into the RCS file format would be useful.

              Comments
              1. By jfb (69.70.32.10) on

                It is possible, as the RCS format allows for extensions (although it was very poorly designed) to be added, but I don't see the point for ownership. But yes, it is possible to extend the RCS format without losing compatibility with other well-behaved CVS to add features.

              2. By Janne Johansson (130.237.95.193) jj@inet6.se on

                Then again, what type of ownership/permissions are we talking about?

                I mean, in this very specific case it's obviously unix perms and uids, but
                the svn folks get this kinds of questions all the time and everyone there
                always assume $my-type-of-perms whereas the source or destination might
                be either NTFS, AFS, DFS or some other not-yet-dead-fs which do not have
                the same idea on ownership, permissions and other flags.

                Comments
                1. By Anonymous Coward (128.171.90.200) on

                  Doesn't matter, it's completely redundant.

              3. By Anonymous Coward (128.171.90.200) on

                I completely disagree, file permissions and ownership does not really become an issue until build time.

                Ok, ok, scripts ...

        2. By ben (66.92.16.226) on

          > However, to have mass conversions to your software, it helps to have at least one nifty feature that noone else has.

          Why does everyone assume that the goal of every software project is "mass conversion" ?

          What about just making a nice tool that works for you?

    2. By Anonymous Coward (203.100.230.217) on

      OpenCVS will have an optional module to telepathically detect whether you want the file checked in as binary.

      This module will, of course, be named OpenMind.

      Comments
      1. By Anonymous Coward (84.188.251.76) on

        But you know that the "file" command was developed, or?

        if %file != ascii -> commit as binary... wouldn´t be that hard, or? .-)

        Comments
        1. By jfb (69.70.32.10) on

          You understand that the binary flag is a means to tell CVS not to do expansion on keywords (and other things)? It means that in some cases, the file could be considered as text by `file' but you'd still want keyword expansion turned off, and the opposite is also true. You could invent a binary format that doesn't croak when expansion is performed in it. Basically, just because a file is binary doesn't mean that you automatically want the binary treatment on it, and vice-versa, so we'll let that choice to the user.

  5. By misher (212.19.145.216) misher@hrenosoft.net on hrenosoft.net/

    Thank you very mutch, great job, I hate /gpl/ licenses.
    I hope that many people will use that (also linux peoples),
    and may be bsd software will grow fuster...

    Comments
    1. By Justin Forest (212.48.194.124) justin.forest@gmail.com on http://hex.mirkforce.net/

      Sorry to disappoint you, but a change in the licensing of an internal tool in no way helps "BSD software" grow. Most people don't give a damn about CVS and, reading the changelog, many of them say: "for fuck's sake, couldn't they work on UTF-8 instead?!"

      Comments
      1. By Anonymous Coward (128.171.90.200) on

        It can do, BSD projects can take scraps of code without having to worry about licensing issues.

        Of course it can also be argued by growing a larger BSD code pool, BSD grows.

      2. By Anonymous Coward (66.11.66.41) on

        Kinda like how if UTF-8 work were done, people would read the changelog and say "for fuck's sake, can't they work on _insert_whining_here_ instead?"?

      3. By jfb (69.70.32.10) on

        > Most people don't give a damn about CVS and, reading the changelog,
        > many of them say: "for fuck's sake, couldn't they work on UTF-8
        > instead?!"

        Maybe most developers don't give a damn about UTF-8 and, reading this thread, many of them say: "for fuck's sake, couldn't he submit a patch instead of whining?". It's all about perspective...

    2. By Luiz Gustavo (200.164.165.23) on

      Sorry, but there's no place for hate here.

    3. By Constantine (217.12.147.5) mureninc@gmail.com on

  6. By pete gilman (67.82.48.99) pete with p3t3 point net on


    why?

    1) apache sucks, has always sucked, and will always suck
    2) OpenBSD is stuck with an old version of apache since apache's license changes
    3) apache is under the GPL; it would be great to have a (full-featured, actively developed) BSD-licensed httpd

    imagine an httpd, not slapped together and crufty, but completely redesigned from the ground up in OpenBSD's "The Right Way To Do It" style...

    please note that this is not a complaint or a demand. i'm not trying to tell anybody what to do. it's just a wish that i wanted to share with the community; i just think it's a great idea, and wanted to see what you guys think...

    (and, for the record, i'm not a coder, just a humble SA; i do buy the cds and t-shirts; and i do donate to the project.)

    Comments
    1. Comments
      1. By Anonymous Coward (70.27.15.123) on

        Litespeed isn't free, and lighttpd is incredibly buggy, has had numerous obvious security problems, which tend to get fixed without security announcements, and has no indication that it is going to ever improve.

        Comments
        1. Comments
          1. By Anonymous Coward (68.100.130.21) on

            You're probably being intentionally stupid, but "free" does not mean without cost. Please reread http://www.openbsd.org/goals.html

            Comments
            1. By Anonymous Coward (63.255.174.162) on

              It is free [as in beer, which is obvious considering my context:] for personal and commercial use. Have you ever read the other types of free (e.g. F[L]OSS) with that phrase?

          2. By Anonymous Coward (70.27.15.123) on

            lightspeed is not free. At all. For anything. You can get it without paying money, but you can't get the source at all.

            And lighttpd has had random people do a quick 5 minute grep and find obvious, incredibly stupid buffer overflows. These get fixed in CVS, and no notification is made of a possible security problem. An no effort has been made to ensure that similar problems aren't elsewhere in the code. The lighttpd author does not code securely, he simply puts "secure" in the feature list of his software. And what kind of idiot does he have to be to allow appending a NULL byte to a file to send the source of the file instead of executing it?

    2. By veins (82.234.175.151) veins@skreel.org on

      yay !
      i'm working on one during my free time :)

    3. By Anonymous Coward (70.27.15.123) on

      1) sucks how? People bitch and moan about apache, yet they can never say whats wrong with it.

      2) Who cares? The "old version" works just fine. Do you really need a threaded worker mode for no reason?

      3) No its not, its under the apache license.

      Comments
      1. By pete gilman (67.82.48.99) pete with p3t3 point net on


        > 1) sucks how? People bitch and moan about apache, yet they can never say whats wrong with it.

        that's a topic for a different thread. you're certainly welcome to disagree, but even you concede that "people bitch and moan about apache" - plenty of people agree with me. i'm not looking to convert anybody; if *you* like apache, by all means keep using it. lots of people don't, and i'd love to see a better way.

        > 2) Who cares? The "old version" works just fine. Do you really need a threaded worker mode for no reason?

        my point is just that new development on the OpenBSD version is extremely unlikely; the only work likely to be done on it is bugfixes. the existing version is basically frozen in time.

        > 3) No its not, its under the apache license.

        i forgot; i stand corrected. thank you. this doesn't change my point, though, that it would be great to have a BSD-licensed httpd.


        all i'm trying to say is that every time these guys (the openbsd team) turn their attention to something, out comes something great. i'd love to see their amazing talents brought to bear on an http daemon; i can only imagine how awesome the result would be.

        peace,

        pete g

        Comments
        1. By Anonymous Coward (68.100.130.21) on

          And yet, their time is finite, so their amazing talents can only be devoted to so many things. This is why there will probably never be OpenHTTPD, OpenCC, etc. (As long as we're dreaming about things that won't happen, I'd really like a usable, BSD-licensed or better C compiler. But yeah. It won't happen, unless I write it myself sometime.)

        2. By Anonymous Coward (70.27.15.123) on

          Yeah, vague "apache sucks but I can't tell anyone why or what sucks about it" is certainly convincing. I bet people will get right on making another webserver that solves all those problems you can't even name. Dumbass.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]