Subversion is a version control system that is a compelling replacement for CVS in the open source community. This is a minor bugfix release.
Subversion 1.0.7 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Just a note: I’ve been following the developers mailing list, and version 1.1 is in release candidate stage, so if you’re interested in starting using Subversion for the first time, you might want to wait a few days.
I’ve been using it for several months for my own personal development and have been thrilled with it. We’re hoping to migrate our source control at work to svn soon.
Finally people want to break free of CVS, because there is a good replacement.
What’s the matter that SourceForge, for example, does not support Subversion yet? Is CVS limited enough that the admins will keep preferring it to Subversion?
specially since it a minor bugfix release…
As for choosing Subversion vs. CVS, it’s really a matter of taste, the kind of argument that leads nowhere.
I don’t know the real reason why SourceForge doesn’t support subversion – at least in parallel to CVS for projects that want it – but I know why I wouldn’t want to switch over yet (until Subversion 1.1).
pre-1.1 versions could only use Berkeley DB as a backend and as a result, there were cases when the repository could become ‘wedged’ and required an svnadmin recover command to be run. This is fine in small environments and there’s a way to detect this and automate the process, but it’s not something you’d really want for a large site like sourceforge.
Subversion is slower than CVS. Of course, on the surface, this would be bad for sourceforge but in fact, subversion requires less network bandwidth which means (presumably) sourceforge’s bandwidth costs would be reduced dramatically. But time is money too and basically pushes the cost out to a ton of developers.
Subversion eats quite a bit on the server side. I haven’t checked recently but certain operations caused the server side process to eat up a lot of memory. Most of those issues have been dealt with but I think the serverside resource consumption is more than with CVS.
Eventually I think sourceforge will switch or provide both cvs and subversion options.
I’ve heard someone lost their precious project due to subversion’s bug…and he said that he didn’t experience any such thing when he was using cvs…
There has also been 1.1rc3 released few days ago. Looks pretty good, I especially like the new filesystem support (“fsfs”) which works as native filesystem without Berkley DB.
We recently changed from CVS to SVN, and I like it very much.
developer.berlios.de (kind of sourceforge) support SVN. I found it much easier to use. In paticular branching and deleting a file from a certain version is much easier. But that’s just mine opinion afcourse
I’ve been messing around with svn last week. To replace our cvs repostories.
It runs nice.. But the eclipse plugin is buggy..
We won’t migrate yet bcause of that
someday we can get Linus to switch from BitKeepers tools to Subversion and end the countless flame wars on LKML.
>someday we can get Linus to switch from BitKeepers tools to
>Subversion and end the countless flame wars on LKML.
That won’t happen. Atleast not until subversion gains all the features of bitkeeper(which there are no indication it ever will). You can search the lkm for flamewars on
this issue as well
“i heard someone that lost his precious repository thanks to svn bug.. whatever”
man thats foo, where were the backups? any conscious guy would at least automate the process for full backup/hotcopy the repos once a day
and noone can lost a thing if a working directory is a copy of the repository, ok you lost version control, changed files etc, but everything is there, your precious code.
you just build another repos from there are you are set to go.
we do svn/webdav with a multitude of plataforms *nix (inc macosx)/windows and i must admit despite some “working copys” binary file corruption, mainly with .NET dll’s and VSNET proj files (that shouldnt be there in the first place, but thats a diff story) we happen to only have “local corruption” thats easy cleared by a process of removing the affecting files, svn cleanup and checkout again the troubleing ones.
i use svn for my own local devel too, and its a breze of relief to know that i can count on it for commited versions rollback, when i code tired and sleepie at keyboard.
Not knowing wtf i did last night that bjork all code.
apache2 + webdav + websvn a must have
Nice to have:
Trac by Edgewall
http://www.edgewall.com/projects/trac
It’s a very nice looking and functional wiki/issue reporting/subversion repository browsing web based tool written in python. Any single piece of this project is worth it and it’s getting better. But if you need web based repository browsing, this is it.
TortoiseSVN
http://tortoisesvn.tigris.org/
Windows Explorer GUI client
SCPlugin
http://scplugin.tigris.org/
OSX Finder GUI client
Catacomb
http://catacomb.tigris.org/
This is a must if you want access to WebDAV stuff from the command line. (subversion through mod_dav_svn is WebDAV enabled and gives you access to the “HEAD” revision)
Not nice to have:
Most often confused with ‘wedged’ repositories that can be fixed by running svnadmin recover on the server (a pain yes, but no data is lost). The file system backend in subversion 1.1 should virtually eliminate this issue. I have heard of really corrupted repositories but it never happened to any of the ones I deal with (several over 2GB in size with 10’s of thousands of revisions). Backing up is a must in any situation so like the last person said, at least backup the repository once a day. The project subversion (the development code of subversion itself) is effectively backed up after each revision using a post commit script.
I’ve lost a 1.04 Repository using BDDB when the sysadmin upgraded from RedHat 8 to Fedora Core 1. (I had backups and dumps, so I didn’t lose anything, but i had to recreate everything).
I’ve decided to install and compile 1.01 RC1 (at the time of the incident) and used the new fsfs. Been working (cross fingers) fantastically since then. I plan to perform a straight upgrade to 1.1 or the next ” 1.1.x stable”.
Thanks for the SCPPlugin.
Many thanks for the pointer to SCPlugin !
I love TortoiseSVN (and TortoiseCVS) and missed something similar on OS X. Not anymore.
Are there any plans to support SVN on sourceforge yet?