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 | Software Development Version Control |
|---|---|
| Licenses | Apache |
| Operating Systems | OS Independent |
| Implementation | C |
Recent releases
- 22 Jun 2009 15:22
Changes: Performance enhancements and bugfixes were made.
- 11 May 2009 16:52
Changes: Bugfixes and improvements.
- 10 Apr 2009 09:40
Changes: Bugs were fixed.
- 20 Mar 2009 23:11
Changes: This release includes better filesystem storage mechanisms, authentication data handling improvements, early support for tree conflict detection, and more.
- 22 Dec 2008 23:19
Changes: Various bugfixes and improvements.
- All comments
Recent commentsRe: 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.
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.
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
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.
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