OpenBSD Journal

Subversion Control and Use

Contributed by jose on from the cvs-replacement dept.

Along with OpenCM , Subversion is another CVS replacement for versioning control. The Subversion project is designing a high quality replacement product that is quickly becoming favored by many. Two recent OnLamp articles cover subversion and are worth checking out. The first covers Single User Subversion , great for projects you want to maintain for yourself. The second and most recent article covers Multiuser Subversion , great for projects and team development.

A port of Subversion to OpenBSD has been put on hold because of the required dependencies (they break other things), but it should be possible to build it manually.

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    "A port of Subversion to OpenBSD has been put on hold because of the required dependencies (they break other things), but it should be possible to build it manually."

    What things ?
    And where is the port ? Or is there some draft available ?

    Comments

    1. By Anonymous Coward () on

      dependence on Apache is what is making subversion put on hold.

      Comments

      1. By pixel fairy () on

        sure about that? openbsd comes with apache (though chrooted out of the box now) but the article on single user subversion doesnt even mention apache. multiuser maybe,

        Comments

        1. By apache-department () on

          It's dependant on Apache 2.0

          Comments

          1. By Anonymous Coward () on

            So (for what i read here) it doesn't actually breaks things does it ?
            And so the port is on hold because an apache2 port
            wasn't done/commited yet, is it not ?
            Or maybe there was no clue that apache2 was needed, therefore is "on hold".

            So jose, is it still on hold because it breaks things ? What does it break after all ? Please
            document yourself before doing such posts.

            Comments

            1. By Srebrenko Sehic () haver@insecure.dk on mailto:haver@insecure.dk

              I believe it also need Berekely DB 4.X and a lot of ports depend on 3.XX version.

    2. By Anonymous Coward () on

      dependence on Apache is what is making subversion put on hold.

    3. By jose () on http://monkey.org/~jose/

      subversion would need a few things: db 4.x, gnu diff utils, apache 2.x, at least. i think there were other things. no one has offered a satisfactory apache 2.x port. db 4.x would break some db dependent ports (backwards compat is ... not easy with berkley db). diff utils also breaks a few things. ask lurene, i'm sure she'd love to have some help on it.

  2. By Karel Gardas () kgardas@NO_SPAMobjectsecurity.com on mailto:kgardas@NO_SPAMobjectsecurity.com

    I wonder if you have seen Arch? It's quite good now and IMHO it's more advanced in feature support than any other free/open software revison control. For more information please look at http://www.fifthvision.net/open/bin/view/Arch/WebHome.
    Cheers,
    Karel

    Comments

    1. By Janne Johansson () on

      One of the "problems" with Arch was the coders
      inability to state where Arch is "expensive" in
      comparison to other versioning systems. It is sort
      of impossible to have a system which is optimal in
      all cases, and the cases where the common versioning
      systems in use today have their problems are mostly
      known so that you may select one based on what type
      of use you will experience. When asked, the Arch
      guy couldn't answer, leading many people (including me)
      to believe that he hasn't researched it enough.

      This in turn might lead to conclusions about the
      overall quality of Arch in itself. Perhaps not true
      and correct conclusions, but you know how people
      are... First impressions kind of lasts.

      When choosing between 3DES and Blowfish for your
      ssh, you can make a decision based on if you want
      speed or extra security, but if one of the cryptos
      were marked (only by the coder) as best in all
      possible cases, some people will tend to disbelieve
      such claims straight away.

      I am FULLY aware of that I can't either prove nor
      disprove anything on how Arch actually performs in
      regard to branching, tagging, storing efficiently
      and all other factors that versioning systems face,
      but I do know that I was dissapointed when he wouldn't
      state any "facts" on which direction Arch had chosen
      to optimise for, and what the consequences would be
      based on that decision. Systems (filesystems, VM
      systems, databases and so on) always optimise for
      speed or space or time or some other factor, and
      almost every time as a tradeoff for something else.
      I wouldn't want to import a large project from a
      known versioning system into Arch just to be the
      first to find out that it starts to suck when some
      part of it (the diff-list, whatever) is 1% over my
      internal memory or some weird factor like that.
      Suddenly I'm "stuck" with a system that requires me
      to buy more memory or switch machine just when the
      system started to grow largish, meaning that I'm
      growing INTO the current VS. Sure, this might happen
      to all VS'es, but sometimes you need to play it
      safe if you expect to have your project grow.
      And to play it safe sometimes means to disregard
      notions of "new and all-improved systems" that claim
      to have no negative parts at all.

      Of course, all this might be provably wrong, perhaps
      the Arch website has all the info, perhaps someone
      has tested Gbyte historyfiles, but the impression
      I got THEN lead me to this decision. Informed persons
      may enlighten me (and us all!) at any time. =)

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