Projects / Subversion

Subversion

Subversion is a version control system. Originally designed to be a compelling replacement for CVS in the open source community, it has far exceeded that goal and seen widespread adoption in both open source and corporate environments. The Subversion project produces Subversion's core libraries (written in C), a fully functional command line client (svn), repository administration programs, API bindings for various languages (Perl, Python, Java, Ruby, etc.), and various additional tools and scripts.

Tags
Licenses
Operating Systems
Implementation

Recent releases

  •  22 Oct 2009 02:42

    Release Notes: Some crashes and other issues have been fixed.

    •  22 Aug 2009 09:04

      Release Notes: Bugfixes.

      •  06 Aug 2009 20:14

        Release Notes: A heap overflow security vulnerability on the server and client was fixed.

        •  22 Jun 2009 13:10

          Release Notes: Performance enhancements and bugfixes were made.

          •  11 May 2009 12:00

            Release Notes: Bugfixes and improvements.

            Recent comments

            22 Jan 2008 04:07 fmdes

            Re: subversion is NOT cultural replacement of CVS. I decided NOT to migrate.
            I realize this is a fairly old post, but... pretty much everything in it is either unsubstantiated opinion or factually wrong.

            > 1. subversion is NOT cultural replacement of cvs. In their fevor to

            > improve, they broke too many things. I would not mind slight

            > changes in syntax, but the whole flavour is alien. Essentially

            > using subversion requires you to learn entirely new version

            > control system and very few lessons learned from CVS will carry

            > over.

            Unsubstantiated opinion. I used CVS for ten years before switching to Subversion and had no trouble at all adapting. The only things I needed to learn from scratch were Subversion features that CVS simply doesn't have.

            I still use CVS extensively, but I vastly prefer Subversion.

            > 2. subversion is "modern" software. This means it

            > depends on ten other projects. They do not bother

            > to document these dependencies in a comprehensible way and

            > the ./configure script fails in mysterious ways (apart

            > from taking forever to run before it fails). It also

            > seems there is good deal of bloat and needless abstractions

            > that do not serve a useful purpose.

            Building Subversion from scratch instead of using the prepackaged version provided by your OS or distribution of choice was entirely your own decision.

            The abstractions you complain about are far from useless; they make Subversion extremely portable while allowing the developers to focus on functionality rather than portability.

            > 3. subversion abandoned the CVS flat file philosophy and

            > went for BerkeleyDB. Then they noticed that people actually

            > considered flat plain text files a good thing(tm) and tried

            > to retrofit it. As such, it does not seem to be anywhere

            > near the level of stability of the BerkelyDB backend.

            Factually incorrect. The fsfs backend was written because of stability and consistency issues with the bdb backend (when accessing a repo over NFS, for instance) and because it makes repo corruption more easily recoverable. It is significantly faster and more stable than the bdb backend, and has been the preferred backend for quite a while (since 1.2).

            > But even if you wanted to use BerkeleyDB, they have added

            > gazillion dependencies to specific versions of BerkeleyDBs

            > so your standard install BerkeleyDB does not work. You will

            > need to hand craft a BerkeleyDB that is palatable to

            > subversion. Hardly portable, eh?

            Factually incorrect. The only issue is that accessing a bdb repo directly (not remotely) with a client built against a newer bdb version will automatically upgrade the repo, rendering it inaccessible to older clients. If all your users access the repo over SSH, you will never run into this problem.

            > 4. subversion ssh support seems complicated and much more bloated

            > than cvs. In effect subversion is geared towards WebDAV and

            > when you try to do ssh, it resorts to trying to emulate

            > WebDAV locally on the host where you ssh to. Frankly, cvs

            > is much easier to understand.

            Factually incorrect. CVS and Subversion implement SSH access in pretty much the same manner.

            > 5. subversion simply does not seem to be addressing the need

            > we have: ssh accessed repository. They spend all their

            > powder on snazzy remote access via WebDAV but forget the

            > home base.

            Factually incorrect. See above. SSH access works very well - far better than with CVS, in fact, because every time you update or diff a CVS working copy over SSH, CVS does a partial checkout of the corresponding parts in /tmp on the server.

            > 6. cvs is not seriously broken. It meets Symlabs needs pretty

            > well and only occacionally behaves "mysteriously". It has

            > strong culture and has widely available "googlebase" so you

            > can get your problems solved. cvs never lost a file for

            > us (though some users did by not fully understanding how

            > it works).

            Bully for you. Projects with large CVS repos that have been around for a while (FreeBSD, for instance) have experienced both repo corruption and other issues caused by changes in repo syntax over time.

            Remember, by the way, that disks sometimes fail, and even RAID controllers have been known to silently corrupt data on the way to or from disk.

            03 Aug 2007 18:02 delt

            Re: subversion is NOT cultural replacement of CVS. I decided NOT to migrate.
            Agreed. Now that i -finally- found it (dumbasses couldn't even add "svn" to the search tags) and tried to compile/run it about 10 times with different sets of libraries, dependencies, etc. i have yet to understand what this piece of junk is supposed to accomplish, other than complicating everyone's lives by adding yet another layer of red tape on top of this whole "which tool is the gospel truth" disaster.

            15 Apr 2006 18:31 sampo

            subversion is NOT cultural replacement of CVS. I decided NOT to migrate.
            Someone asked recently why Symlabs is still using cvs and not subversion.

            Well, I was provoked to try subversion out and this is what I found out.

            Comments based on subversion-1.3.1.

            1. subversion is NOT cultural replacement of cvs. In their fevor to

            improve, they broke too many things. I would not mind slight

            changes in syntax, but the whole flavour is alien. Essentially

            using subversion requires you to learn entirely new version

            control system and very few lessons learned from CVS will carry

            over.

            2. subversion is "modern" software. This means it

            depends on ten other projects. They do not bother

            to document these dependencies in a comprehensible way and

            the ./configure script fails in mysterious ways (apart

            from taking forever to run before it fails). It also

            seems there is good deal of bloat and needless abstractions

            that do not serve a useful purpose.

            3. subversion abandoned the CVS flat file philosophy and

            went for BerkeleyDB. Then they noticed that people actually

            considered flat plain text files a good thing(tm) and tried

            to retrofit it. As such, it does not seem to be anywhere

            near the level of stability of the BerkelyDB backend.

            But even if you wanted to use BerkeleyDB, they have added

            gazillion dependencies to specific versions of BerkeleyDBs

            so your standard install BerkeleyDB does not work. You will

            need to hand craft a BerkeleyDB that is palatable to

            subversion. Hardly portable, eh?

            4. subversion ssh support seems complicated and much more bloated

            than cvs. In effect subversion is geared towards WebDAV and

            when you try to do ssh, it resorts to trying to emulate

            WebDAV locally on the host where you ssh to. Frankly, cvs

            is much easier to understand.

            5. subversion simply does not seem to be addressing the need

            we have: ssh accessed repository. They spend all their

            powder on snazzy remote access via WebDAV but forget the

            home base.

            6. cvs is not seriously broken. It meets Symlabs needs pretty

            well and only occacionally behaves "mysteriously". It has

            strong culture and has widely available "googlebase" so you

            can get your problems solved. cvs never lost a file for

            us (though some users did by not fully understanding how

            it works).

            Now that I have this out of my system, do not expect me to look

            at subversion in next five years - or until I get annoyed

            enough about some CVS shortcoming and feel I can't fix it

            within CVS.

            Cheers,

            --Sampo

            27 Apr 2005 22:18 floyd59

            Re: Ahh, we *certainly* do need a CVS replacement...
            Just a feedback from a reader: When i read the advertisment above, i just thought: "if gnu/arch needs that kind of unfair pushing, it cant be very good". For me, it just disqualified itself and i'll definitely give subversion a try.

            Cheers, and keep it up.

            03 May 2004 21:15 eqhmcow

            Re: Etiquitte (& a lame self-justification attempt)


            >

            > Hey, thanks for trying to advertise

            > another solution here. Please keep this

            > kind of stuff to your own FM entries.

            well, I for one agree with Charles' motives. I did come to the subversion page to *research* alternatives. I appreciate someone broadening my horizons by letting me know that CVS and SVN aren't the only VC Systems on the OSS street.

            -- Dan

            Screenshot

            Project Spotlight

            OpenStack4j

            A Fluent OpenStack client API for Java.

            Screenshot

            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.