OpenBSD Journal

OpenCM

Contributed by jose on from the alternative-to-cvs dept.

Anyone who has ever done large scale software development with CVS knows it has a few limitations. Furthermore, it has some requirements and lack of features which don't satisfy many security vigilante people. A project like OpenCM may be more in tune with what people are looking for in that situation. For a quick introduction to OpenCM, see this page on OpenCM . It was recently brought into the ports tree as /usr/ports/devel/opencm . Next time you are thinking about CVS, have a look at OpenCM and see if it meets your needs.

(Comments are closed)

Comments

  1. By Dweebster () on

    We have been using it for over a month now and are very pleased at my job. Though still in heavy development it is stable enough to actually use in a real developer environment.

    http://subversion.tigris.org/

    Comments

    1. By Anonymous Coward () on

      Yes. The problem with Subversion however is that
      the licensing is not compatible. Hopefully similar
      problems will be avoided by the OpenCM developers.

      Comments

      1. By Anonymous Coward () on

        incompatible (with what?) in what way? a quick read of the license reveals nothing offensive...

        Comments

        1. By Anonymous Coward () on

          If memory serves, it's dependent on db3 which
          is under the Sleepycat License which is not a
          BSD friendly license.

    2. By Anonymous Coward () on

      Dont think so. It uses apache and is SLOW!
      I don't want to install apache if the machine isn't going to be a webserver, so this SUX!

      Comments

      1. By Anonymous Coward () on http://dict.org

        bird brain. There is a difference between installing, and enabling Apache.

      2. By Anonymous Coward () on

        As of rev 4028 (from memory), Subversion can be accessed over the network without Apache, either directly using the server (svnserve) or over ssh or similar. I think 0.17 will be the first tarballed release including the code.

        http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=212130

  2. By Tobias Weingartner () weingart@tepid.org on http://www.tepid.org/~weingart/

    This is all IMHO of course. OpenCM will be the next never was, unless it starts to fix and change some of it's fundamental things. It is easy to talk (since I don't code), so please take these with a grain of salt.

    1 - A decent object store is absolutely essential in OpenCM. This includes a way to import and export portions (or all) of it to a portable and editable format. (In this way object stores can be imported/exported between versions, etc...)

    Of course, KISS is the best principle. If you use XML, keep it simple XML. Don't use every fancy feature in it, etc. Note, you then only need to provide a tool per CM system to import/convert to your tool. A 'la RPC...

    2 - Ability to operate on portions of a tree. I do many things within my tree, being able to commit, etc on only a portion of a tree is entirely essential. If I want to operate on the whole tree, I can always tell OpenCM to do so.

    3 - Speed. OpenCM is currently slow. Diskspace is pretty cheap, use it to get better speed and throughput.

    4 - Documentation. The documentation does not match the implementation. Either find a way to grow both in step, or write the documentation first. This will help in figuring out what you want to call commands, etc. It will help in fleshing out the overall structure of the CM system. This it seems has not been done.

    5 - Don't depend on libGC. Use standard ANSI/ISO C, and write your own libraries to keep it portable. Only use other libraries for the object store (if necessary). Keep the client as portable as you can. Don't go overboard (like CVS/apache), but code to the standards.

    6 - Organize and create development boundaries wrt API and interfaces. Define these API's, and then code to them. In this way more people can code up portions of the system. (IE: if you have a published API for the object store, someone could do a research implementation of some new idea, which could pay off in the end...)


    I'm sure there are more, but I'm drawing a blank on the rest right now.

    -T.

    Comments

    1. By Dan Weeks () danimal [AT] danimal [DOT] org on mailto:danimal [AT] danimal [DOT] org

      you had it going good until point #5. telling a developer to not use a third-party library is like saying not to use the built-in libc on any system. for standardization you should roll your own, it's more portable, right?

      putting effort into third party libs means your fixes and the fixes of other benifit many more people than just your project.

      of course you say you're not a developer, so I'll assume you might not fully understand all aspects of this. grain of salt taken.

      Comments

      1. By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org

        Heh. Toby not a developer ? you wish...
        He said that `he doesn't code', which means that he isn't
        writing code *currently*, but he certainly know what he's
        talking about.

        And, we're not talking about any other libraries. There are
        good reasons to think using a GC in opencm might be a big
        mistake (especially as this GC turns out to be a bitch to
        debug).

        All of Toby's points make sense.

      2. By Tobias Weingartner () weingart@tepid.org on http://www.tepid.org/~weingart/

        Well, there are certain libraries out there that make perfect sense to use. For example a DB library. Or a crypto library. Functionality that is not readily available within a base POSIX system.

        Now, libgc, while a worthwhile library on it's own, does not make much sense in the light of POSIX systems. Just clean up your memory already. C was not really meant for garbage collection...

        Or my favourite, glibc. Why do you need all those wrapper functions for standard ANSI/ISO C? Just code to the standards already. Exceptions (and bugs) are few and far between today. And when they do occur, make it a point to tell the vendor about it. Push the vendor to fix it. Don't settle for mediocrity in other people's software by "adapting" yours to fit.

        Again, just my $0.02.

        -T.

        Comments

        1. By Dan Weeks () danimal [AT] danimal [DOT] org on mailto:danimal [AT] danimal [DOT] org

          d'oh! thanks to Tobias and Marc for setting me straight. Had I just read the name I would have realized who it was.

          i'll agree with you on glibc, bleh. I'm just now looking at libgc and Marc's right, all of Tobias' comments make sense.

          My apologies for jumping the gun there.

      3. By James Frazer () jfrazer@shaw.ca on mailto:jfrazer@shaw.ca

        Dan, you've obviously never had the privilage of living on a dairy farm before.

        Listen to Tobi, he knows what he's talking about.

        ;-)

        Comments

        1. By Dan Weeks () danimal [AT] danimal [DOT] org on mailto:danimal [AT] danimal [DOT] org

          trust me, i've removed my head from my butt now. I'll be listening to Tobi for sure.....And Marc...etc., etc.

          :)

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