OpenBSD Journal

GNU RCS removed from source tree

Contributed by niallo on from the cvs-rm-is-good dept.

Today Theo prompted us to remove GNU RCS from the source tree. Our replacement, Open RCS, has been linked into the build for close to a year now. OpenBSD 4.0 shipped with Open RCS as its RCS implementation and we have had only a few relatively minor bugs. Roughly 25,000 lines of ancient, poorly maintained GNU code has been replaced with around 13,000 lines of modern, clean BSD code.

In related news Open CVS has been making great progress recently - people should feel free to check out the source, build it, use it and most importantly send us bug reports!

Here is the removal commit message:
CVSROOT:	/cvs
Module name:	src
Changes by:	niallo@cvs.openbsd.org	2007/02/14 10:54:16

Removed files:
	gnu/usr.bin/rcs: COPYING CREDITS ChangeLog INSTALL INSTALL.RCS 
	                 Makefile.bsd-wrapper Makefile.in NEWS README 
	                 REFS configure configure.in install-sh 
	                 mkinstalldirs rcs.ms rcs_func.ms 
	gnu/usr.bin/rcs/man: ChangeLog Makefile.in ci.1 co.1 ident.1 
	                     merge.1 rcs.1 rcsclean.1 rcsdiff.1 
	                     rcsfile.5in rcsfreeze.1 rcsintro.1 
	                     rcsmerge.1 rlog.1 
	gnu/usr.bin/rcs/src: ChangeLog Makefile.in TAGS ci.c co.c 
	                     conf.heg conf.sh ident.c maketime.c 
	                     maketime.h merge.c merger.c partime.c 
	                     partime.h rcs.c rcsbase.h rcsclean.c 
	                     rcsdiff.c rcsedit.c rcsfcmp.c rcsfnms.c 
	                     rcsfreeze.sh rcsgen.c rcskeep.c rcskeys.c 
	                     rcslex.c rcsmap.c rcsmerge.c rcsrev.c 
	                     rcssyn.c rcstest rcstime.c rcsutil.c rlog.c 
	                     version.c 

Log message:
remove GNU RCS implementation from the tree.  Open RCS has been used for over
a release now.

prompted by deraadt@, ok joris@

(Comments are closed)


Comments
  1. By Anonymous Coward (129.127.96.27) on

    Can someone please explain the relationship between RCS and CVS?
    I read the online man pages for both, but was not really enlightened - RCS only works on one file at a time, while CVS may work on many? Does CVS use RCS?
    I wouldn't mind looking at the opencvs man page, but its not hooked in at http://www.openbsd.org/cgi-bin/man.cgi

    Comments
    1. By niallo (82.195.149.9) on

      > Can someone please explain the relationship between RCS and CVS?
      > 
      > I read the online man pages for both, but was not really enlightened - RCS only works on one file at a time, while CVS may work on many? Does CVS use RCS?
      > 
      > I wouldn't mind looking at the opencvs man page, but its not hooked in at http://www.openbsd.org/cgi-bin/man.cgi
      

      An Undeadly.org article I wrote about a year ago covers most of this.

    2. By Chas (147.154.235.51) on

      We are running ancient HP-UX 10.20 systems with a large code base in PVCS (originally the Polytron Version Control System, now owned by Merant). We continue to be stuck with this because of some PowerBuilder code. PVCS archives are similar to RCS in that they use reverse deltas unlike SCCS.

      A couple of years ago, a few developers asked for a large fragment of this code to be broken off and converted to CVS. I found a perl script that would convert a PVCS archive into RCS (preserving all version history, ownership, and comments). Once each archive was converted, I just populated the CVSROOT directory tree with the RCS archives, and immediately CVS just worked, and the desktop tools are light years beyond the old PVCS Version Manager.

    3. By Morsello (201.52.221.25) morsello@gmail.com on

      > Can someone please explain the relationship between RCS and CVS?
      >
      The original CVS uses the GNU RCS tools and archive format (,v files),
      addind directory and tree processing.

      Current CVS mantain the the ,v archive format but uses his own
      implementation of the tools.

      OpenRCS was a complete rewrite and cleanup of GNU RCS under BSD licence.

      OpenCVS (I think) is using the same OpenRCS code to maintain this archive of versions and rewrite a new CVS compatible tool.

  2. By Anonymous Coward (24.37.236.100) on

    Had been developed with portability in mind? ie, portable 'goop' I think the term is? Similar to OpenSSH.

    Not that I use or have need for Linux anymore (as of yet - personally speaking), but I'm just curious as it would be nice to see more great OpenBSD code ported to other OS's too, and credit given where credit is due...

    Comments
    1. By Nate (Nate) on

      > Had been developed with portability in mind? ie, portable 'goop' I think the term is? Similar to OpenSSH.
      >
      > Not that I use or have need for Linux anymore (as of yet - personally speaking), but I'm just curious as it would be nice to see more great OpenBSD code ported to other OS's too, and credit given where credit is due...

      OpenSSH isn't developed with portability in mind, portability is added after-the-fact by a mostly seperate team of developers.

      Comments
      1. By Chris (194.193.52.253) chriswareham@chriswareham.demon.co.uk on

        > > Had been developed with portability in mind? ie, portable 'goop' I think the term is? Similar to OpenSSH.
        > >
        > > Not that I use or have need for Linux anymore (as of yet - personally speaking), but I'm just curious as it would be nice to see more great OpenBSD code ported to other OS's too, and credit given where credit is due...
        >
        > OpenSSH isn't developed with portability in mind, portability is added after-the-fact by a mostly seperate team of developers.

        I understand that there's been some interaction between the core SSH developers and the people who produce the "portable" versions that has seen changes made to make the core more portable. I can't find a reference, but I seem to recall that it was in response to another article on this site.

        As for the RCS replacement, I'd expect it to be more easily portable than something like OpenSSH as on the face of it there's less reason for it to be grovelling around in more system dependent parts of the OS.

        Comments
        1. By Ben (mouring) on http://eviladmin.org

          > > > Had been developed with portability in mind? ie, portable 'goop' I think the term is? Similar to OpenSSH.
          > > >
          > > > Not that I use or have need for Linux anymore (as of yet - personally speaking), but I'm just curious as it would be nice to see more great OpenBSD code ported to other OS's too, and credit given where credit is due...
          > >
          > > OpenSSH isn't developed with portability in mind, portability is added after-the-fact by a mostly seperate team of developers.
          >
          > I understand that there's been some interaction between the core
          > SSH developers and the people who produce the "portable" versions that
          > has seen changes made to make the core more portable. I can't find a
          > reference, but I seem to recall that it was in response to another
          > article on this site.
          >

          The relationship is most of the "portable" team are also OpenBSD commiters. However, the goal of the portable is an attempt to take clean OpenBSD code and either write a compatibility layer for OSes missing features. Or change function calls to more commonly used (still safe calls).

          Majority of the "portable 'goop'" is actually for old old Operating systems, working around multiple PAM implementations, or tying into advance security features of other operating systems.

          Comments
          1. By niallo (82.195.149.9) niallo@openbsd.org on

            > > > > Had been developed with portability in mind? ie, portable 'goop' I think the term is? Similar to OpenSSH.
            > > > >
            > > > > Not that I use or have need for Linux anymore (as of yet - personally speaking), but I'm just curious as it would be nice to see more great OpenBSD code ported to other OS's too, and credit given where credit is due...
            > > >
            > > > OpenSSH isn't developed with portability in mind, portability is added after-the-fact by a mostly seperate team of developers.
            > >
            > > I understand that there's been some interaction between the core
            > > SSH developers and the people who produce the "portable" versions that
            > > has seen changes made to make the core more portable. I can't find a
            > > reference, but I seem to recall that it was in response to another
            > > article on this site.
            > >
            >
            > The relationship is most of the "portable" team are also OpenBSD commiters. However, the goal of the portable is an attempt to take clean OpenBSD code and either write a compatibility layer for OSes missing features. Or change function calls to more commonly used (still safe calls).
            >
            > Majority of the "portable 'goop'" is actually for old old Operating systems, working around multiple PAM implementations, or tying into advance security features of other operating systems.
            >

            Should not be hard to port OpenRCS or OpenCVS. The code does not do anything especially unportable. Could probably get it running on Linux for example with minimal changes.

  3. By Randal L. Schwartz (75.214.202.12) merlyn@stonehenge.com on http://www.stonehenge.com/merlyn/

    Well, I hope you still keep GNU RCS in ports, because OpenRCS isn't compatible with GNU Emacs vc modes. I discovered this the hard way when upgrading my system from 3.9 to 4.0, and GNU Emacs was barfing as I was trying to edit some RCS-controlled files in /etc. Very frustrating. The workaround was to install the GNU RCS from ports, and point my "ci" and "co" at "gci" and "gco" to get the old behavior.

    I believe it's because OpenRCS is more verbose when it shouldn't be, or more upset about read-only files when it shouldn't, or something like that. Sorry, it's been a couple of months since the upgrade, and I wasn't keeping score when it happeend.

    Comments
    1. By Nate (Nate) on

      > Well, I hope you still keep GNU RCS in ports, because OpenRCS isn't compatible with GNU Emacs vc modes. I discovered this the hard way when upgrading my system from 3.9 to 4.0, and GNU Emacs was barfing as I was trying to edit some RCS-controlled files in /etc. Very frustrating. The workaround was to install the GNU RCS from ports, and point my "ci" and "co" at "gci" and "gco" to get the old behavior.
      >
      > I believe it's because OpenRCS is more verbose when it shouldn't be, or more upset about read-only files when it shouldn't, or something like that. Sorry, it's been a couple of months since the upgrade, and I wasn't keeping score when it happeend.

      Should have submitted a bug report.

    2. By niallo (64.142.92.182) on

      > Well, I hope you still keep GNU RCS in ports, because OpenRCS isn't compatible with GNU Emacs vc modes. I discovered this the hard way when upgrading my system from 3.9 to 4.0, and GNU Emacs was barfing as I was trying to edit some RCS-controlled files in /etc. Very frustrating. The workaround was to install the GNU RCS from ports, and point my "ci" and "co" at "gci" and "gco" to get the old behavior.
      >
      > I believe it's because OpenRCS is more verbose when it shouldn't be, or more upset about read-only files when it shouldn't, or something like that. Sorry, it's been a couple of months since the upgrade, and I wasn't keeping score when it happeend.

      It would be nice if OpenRCS worked with Emacs.

      If you could debug this a little and mail us some details, that would greatly expedite a fix.

      I don't use Emacs with OpenRCS myself.

    3. By Xavier Santolaria (xsa) xsa@openbsd.org on http://consulting.santolaria.net/xsa/

      > Well, I hope you still keep GNU RCS in ports, because OpenRCS isn't compatible with GNU Emacs vc modes. I discovered this the hard way when upgrading my system from 3.9 to 4.0, and GNU Emacs was barfing as I was trying to edit some RCS-controlled files in /etc. Very frustrating. The workaround was to install the GNU RCS from ports, and point my "ci" and "co" at "gci" and "gco" to get the old behavior.
      >
      > I believe it's because OpenRCS is more verbose when it shouldn't be, or more upset about read-only files when it shouldn't, or something like that. Sorry, it's been a couple of months since the upgrade, and I wasn't keeping score when it happeend.

      Please mail us (ray, niallo, joris and myself) more information about the wrong behaviours you are seeing.
      The goal of OpenRCS is certainly not to break things that worked before...

      Comments
      1. By Randal L. Schwartz (66.214.252.122) merlyn@stonehenge.com on http://www.stonehenge.com/merlyn/

        >
        > Please mail us (ray, niallo, joris and myself) more information about the wrong behaviours you are seeing.
        > The goal of OpenRCS is certainly not to break things that worked before...

        Yeah, it wasn't until I saw this announcement that i remembered my troubles. I'll try to get a proper bug report submitted. Where should I send it? "email us" when there's no email addresses linked here doesn't help me. :)

        Comments
        1. By Xavier Santolaria (xsa) on http://consulting.santolaria.net/xsa/

          > >
          > > Please mail us (ray, niallo, joris and myself) more information about the wrong behaviours you are seeing.
          > > The goal of OpenRCS is certainly not to break things that worked before...
          >
          > Yeah, it wasn't until I saw this announcement that i remembered my troubles. I'll try to get a proper bug report submitted. Where should I send it? "email us" when there's no email addresses linked here doesn't help me. :)

          Oh, c'mon... read inside the ( ).

        2. By chl (195.68.31.231) on

          > > Please mail us (ray, niallo, joris and myself) more information about > "email us" when there's no email addresses linked here doesn't help me. :)

          add "@openbsd.org" to the people inside the ( ), and the "myself" is "xsa".

        3. By Randal L. Schwartz (209.131.61.1) merlyn@stonehenge.com on http://www.stonehenge.com/merlyn/

          > >
          > > Please mail us (ray, niallo, joris and myself) more information about the wrong behaviours you are seeing.
          > > The goal of OpenRCS is certainly not to break things that worked before...
          >
          > Yeah, it wasn't until I saw this announcement that i remembered my troubles. I'll try to get a proper bug report submitted. Where should I send it? "email us" when there's no email addresses linked here doesn't help me. :)

          As a followup, here's the essence of the "bug" (also emailed, thank you for writing me privately):

          Playing around with it for a few minutes, it appears that OpenRCS
          is overly cautious (perhaps rightfully so) when I have xyz (readonly)
          and RCS/xyz,v (readonly), and type "co -l xyz". It asks me if I want
          to delete the existing "xyz". GNU RCS just blindly overwrites the file,
          and this is the behavior that Emacs is expecting.


          blue.stonehenge.com:/tmp % co -l xyz
          co -l xyz
          RCS/xyz,v --> xyz
          revision 1.1 (locked)
          xyz exists; remove it? [ny](n): ^C

          blue.stonehenge.com:/tmp % gco -l xyz
          gco -l xyz
          RCS/xyz,v --> xyz
          revision 1.1 (locked)
          done
          blue.stonehenge.com:/tmp %

          So, you've probably done the thing that GNU RCS should have done, but this
          makes it not backward compatible, and therefore not a drop-in replacement.

          Comments
          1. By niallo (82.195.149.9) niallo@openbsd.org on

            > > >
            > > > Please mail us (ray, niallo, joris and myself) more information about the wrong behaviours you are seeing.
            > > > The goal of OpenRCS is certainly not to break things that worked before...
            > >
            > > Yeah, it wasn't until I saw this announcement that i remembered my troubles. I'll try to get a proper bug report submitted. Where should I send it? "email us" when there's no email addresses linked here doesn't help me. :)
            >
            > As a followup, here's the essence of the "bug" (also emailed, thank you for writing me privately):
            >
            > Playing around with it for a few minutes, it appears that OpenRCS
            > is overly cautious (perhaps rightfully so) when I have xyz (readonly)
            > and RCS/xyz,v (readonly), and type "co -l xyz". It asks me if I want
            > to delete the existing "xyz". GNU RCS just blindly overwrites the file,
            > and this is the behavior that Emacs is expecting.
            >
            >
            > blue.stonehenge.com:/tmp % co -l xyz
            > co -l xyz
            > RCS/xyz,v --> xyz
            > revision 1.1 (locked)
            > xyz exists; remove it? [ny](n): ^C
            >
            > blue.stonehenge.com:/tmp % gco -l xyz
            > gco -l xyz
            > RCS/xyz,v --> xyz
            > revision 1.1 (locked)
            > done
            > blue.stonehenge.com:/tmp %
            >
            > So, you've probably done the thing that GNU RCS should have done, but this
            > makes it not backward compatible, and therefore not a drop-in replacement.
            >

            Are you using OpenRCS from -current? If not, please try that.

          2. By Xavier Santolaria (xsa) xsa@openbsd.org on http://consulting.santolaria.net/xsa/

            > > >
            > > > Please mail us (ray, niallo, joris and myself) more information about the wrong behaviours you are seeing.
            > > > The goal of OpenRCS is certainly not to break things that worked before...
            > >
            > > Yeah, it wasn't until I saw this announcement that i remembered my troubles. I'll try to get a proper bug report submitted. Where should I send it? "email us" when there's no email addresses linked here doesn't help me. :)
            >
            > As a followup, here's the essence of the "bug" (also emailed, thank you for writing me privately):
            >
            > Playing around with it for a few minutes, it appears that OpenRCS
            > is overly cautious (perhaps rightfully so) when I have xyz (readonly)
            > and RCS/xyz,v (readonly), and type "co -l xyz". It asks me if I want
            > to delete the existing "xyz". GNU RCS just blindly overwrites the file,
            > and this is the behavior that Emacs is expecting.
            >
            >
            > blue.stonehenge.com:/tmp % co -l xyz
            > co -l xyz
            > RCS/xyz,v --> xyz
            > revision 1.1 (locked)
            > xyz exists; remove it? [ny](n): ^C
            >
            > blue.stonehenge.com:/tmp % gco -l xyz
            > gco -l xyz
            > RCS/xyz,v --> xyz
            > revision 1.1 (locked)
            > done
            > blue.stonehenge.com:/tmp %
            >
            > So, you've probably done the thing that GNU RCS should have done, but this
            > makes it not backward compatible, and therefore not a drop-in replacement.
            >

            This particular bug has been fixed by millert@ ~3 months ago.
            Although, we have spotted another bug that might affect Emacs users.
            We are working on it.

          3. By Magnus Holmberg (mho) on


            > Playing around with it for a few minutes, it appears that OpenRCS
            > is overly cautious (perhaps rightfully so) when I have xyz (readonly)
            > and RCS/xyz,v (readonly), and type "co -l xyz". It asks me if I want
            > to delete the existing "xyz". GNU RCS just blindly overwrites the file,
            > and this is the behavior that Emacs is expecting.

            IIRC, not blindly. It will only overwrite silently if the file is the same as the checked in version...

            - mho

  4. By Igor Sobrado (sobrado) on

    Excellent work! OpenRCS is a superb tool. I am sure, OpenCVS will be another great one too. Nice to see that this tool (OpenRCS) is so nicely designed and is smaller. It is currently an excellent choice, and a good replacement for GNU RCS (there are some compatibility problems outlined in the replies to this history, but I know that OpenRCS developers are working really hard to fix even the smallest bugs!)

    Just a question: how are the relationship between *OpenRCS* and *OpenCVS*?

    Some wording will be required to understand the question, though. I see that there are some OpenRCS related files in the OpenCVS directory (for example, rcs.[ch]). Will these files be merged with the OpenRCS ones once OpenCVS is ready for production? I see that both software packages are in different directories in the OpenBSD source repository, and I suppose that duplicated files should be avoided if possible.

    Again, an excellent tool. Nice to know that GNU RCS has been finally removed from the source tree.

    Comments
    1. By Igor Sobrado (sobrado) on

      > Some wording will be required to understand the question, though. I see that there are some OpenRCS related files in the OpenCVS directory (for example, rcs.[ch]). Will these files be merged with the OpenRCS ones once OpenCVS is ready for production? I see that both software packages are in different directories in the OpenBSD source repository, and I suppose that duplicated files should be avoided if possible.

      I ask this question because I see that there are different patches applied to ~/src/usr.bin/cvs/rcs.* and to ~src/usr.bin/rcs/rcs.*, the code is not the same. How will be these files (rcs.[ch]) managed when both OpenRCS and OpenCVS are in production releases of OpenBSD?

    2. By niallo (82.195.149.9) niallo@openbsd.org on

      > Excellent work! OpenRCS is a superb tool. I am sure, OpenCVS will be another great one too. Nice to see that this tool (OpenRCS) is so nicely designed and is smaller. It is currently an excellent choice, and a good replacement for GNU RCS (there are some compatibility problems outlined in the replies to this history, but I know that OpenRCS developers are working really hard to fix even the smallest bugs!)
      >
      > Just a question: how are the relationship between *OpenRCS* and *OpenCVS*?
      >
      > Some wording will be required to understand the question, though. I see that there are some OpenRCS related files in the OpenCVS directory (for example, rcs.[ch]). Will these files be merged with the OpenRCS ones once OpenCVS is ready for production? I see that both software packages are in different directories in the OpenBSD source repository, and I suppose that duplicated files should be avoided if possible.

      There is indeed some divergence between the RCS code in OpenRCS and OpenCVS. Most of the changes in OpenCVS are not urgently needed in OpenRCS because you typically only operate on a single or very small number of files, whereas you can easily operate on thousands in a single OpenCVS operation.

      Merging the OpenCVS rcs.c code back into OpenRCS would still be a nice thing to do for completeness' sake, though. Nice little project for someone who'd like to start hacking :)

      >
      > Again, an excellent tool. Nice to know that GNU RCS has been finally removed from the source tree.

      Thanks!

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