Slashdot Mirror
KDE Switches to Subversion
Michael Pyne writes "It's official, after weeks of preparation, KDE has completed switching their source control repository from CVS to Subversion. KDE is one of the largest software projects to make the switch, and is the first major desktop environment to do so. Some of the goodies that CVS users are used to are still in the process of being switched over (including WebSVN), but everything seems to be working well so far." (The announcement of early April is no longer the operative statement.)
Monolithic svn databases are vulnerable to irrecoverable corruption
As I understand, subversion was more or less designed to be the successor (and replacement) of CVS. It's not a big surprise then that switching is a major issue. The users are already used to its methodology (contrary to e.g. linux kernel developers).
see a Text Widget
The only downside is that I've had some friends unable to use the WebDAV method PROPFIND because some corporate firewalls have blocked it. Regular GETs will work, but you don't have all the info about the file. And trying to get a big organization's IT dept to change a firewall setting for one project is a huge struggle.
That and some people use Novell netdrive to access subversion like a regular drive which results in tons of small uncommented commits if they have write permission.
Apparently, subversion allows you to rename files (which is a clumsy process in cvs). It's also able to keep track of directories themselves. cvs doesn't care about diretories, only about files.
There are lots more differences though, but the two I mentionend certainly sound like they made life a little easier.
You mean this?
xfce Already switched to svn weeks ago. Lightwight, slick, fast, and now hosted on SVN.
Subversion's really intended to be as close to a drop-in replacement for CVS as possible - except with most of the huge design flaws fixed.
The feature I most notice (I use Subversion at work, albeit with a fairly small dev team) is the ability to do handle file renames properly (preserving history). Atomic commits (of groups of files) are also nice.
There are lots of other important features of course, but I tend to use it just as a better CVS - which role it fills admirably.
You can play around with it at http://www.sinz.org/Michael.Sinz/Insurrection/
Note that I am still in somewhat active development but the code is also in active use. It can be checked out with:
Check this for a detailed checklist of what each of the major version control systems support/doesn't support.
The following statement is true
The preceding statement is false
Although trac is quite good and integrates well with SubVersion, it has a few disadvantages, the main one being no support for multiple projects.
Scarab, the open-source bug tracking tool that CollabNet's commercial offering uses and GForge, although cumbersome to setup are IMHO better alternatives if you're looking for bug-tracking tools to use along with SubVersion
--
Ravi
-- Ravi
This is one of the best windows based svn clients I've seen.
http://tortoisesvn.tigris.org/
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
You missed the part about "subversion"
Yeah, I'm not a big CVS fan and I'm eager to start using subversion. Unfortunately, SourceForge still doesn't support it so I (and thousands of others) are stuck with CVS for a while. However, they're looking into it. Here's an excert from their site status updates:
Subversion Service: The research, analysis, and support gear-up needed to implement a Subversion service at SourceForge.net is now in progress. As with all SourceForge.net services, extensive analysis and testing must be performed to verify suitable levels of stability and scalability before a service can be rolled-out. We are expecting the initial phases of this effort to last several weeks, to be followed by the implementation of a testing environment which will be used for a live beta test by specific selected projects. Pending successful scalability testing, service details will be finalized and service will be offered to all projects. (Refreshed 2005-04-21, to show continued in-progress status.) (Last updated: 2005-04-21 Pacific)
Hero of Allacrost, a FOSS RPG for *NIX/*BSD/OS X/Win
SubVersion is available for Windows as well.
-- Ravi
The main one tends to be lack of tracking of file/directory renames. CVS does not really handle this at all while Subversion handles this very well.
Subversion also treats a commit of changes to multiple files as an atomic operation. This is a major benefit. You can easily see what all went into a specific commit (bug fix/etc) without trying to track down each file that it happened to. You also never have to worry about part of your commit being on the server and part of it not. It either is committed or it is not. CVS can not do that. (Well, beyond a single file that is)
Another major issue is the client/server relationship. Subversion has a very clean client/server interface. It is orthogonal, well designed, and relatively low overhead. CVS can not claim this to be the case. In fact, CVS's client/server features were bolted on after-the-fact and show it.
Subversion can work via HTTP/HTTPS protocols via an Apache plugin. In fact, it is not just HTTP but WebDAV and DeltaV protocol based, which means that there are other tools that can play with the repository as a auto-revisioned filesystem.
Subversion makes it possible to do some advanced web interfaces rather easily, such as the Insurrection http://insurrection.tigris.org/ does.
For me, once Subversion 1.1 came out there was no reason to look back at CVS other than legacy systems. (Subversion 1.0 was already better but it was 1.1 that finally put be over the edge.)
Did you look into RapidSVN? I haven't tried it myself, but it may be an interesting alternative to TortoiseSVN if you want support for platforms other than windows.
There's also a Subversion plugin for Eclipse, in case you're using that.
quidquid latine dictum sit altum videtur.
What are the most important features that Subversion has and CVS hasn't? It's been a lot of buzz lately behind Subversion, but I didn't figure it out what CVS has that is so wrong/slow/bad for software versioning
There are two things that you'll find different when comming from CVS:
SubVersion as a whole has more clean, thought-out-design feel, IMHO. Being a former CVS user myself I guarantee you that after working with SubVersion for a while CVS feels a bit hacked together.
Actually monotone works on windows as both client and server.
I understand that Trac support for multiple projects (along with a few other features) is due soon - I believe as part of the upcoming 0.9 release.
Thanks for the pointers re: Scarab and GForge though, I'll have a look at them. Always nice to keep up-to-date with the alternatives. :)
Why does bugzilla scare you?
Because it's ugly and not very user friendly... if you've seen commercial bug trackers or stuff like Trac you'll notice the difference. Don't get me wrong, Bugzilla is a valuable tool and it does the job it needs to do, but the UI is horrible.
http://esvn.umputun.com/ is a pretty good frontend.
Subversion has a client, but no server [for Windows].
What!? That is complete nonsense. Subversion has excellent and complete (client + server) cross-platform support. Linux, Windows, *BSD, MacOS X, Solaris -- you name it. They achieve this by using C and APR.
Maybe you should read HOWTO Setup A Server on Windows.
-Malloc___________________ I want to be free()!
If you have a random corruption, I severely doubt you're going to be jumping into the FSFS repository and tweaking it to fix it.
My solution: rsnapshot. Because the repository is filesystem-based, all of my backup history combined only takes up the same amount of space as my actual repository (god bless hard links). With BDB, the disk usage for my backups would be insane.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
You can choose between a BDB based backend and a filesystem based backend.
Subversion has the same (poor) merging capabilities as CVS.
....
FYI, I use Subversion but merging in Subversion and CVS is not nearly as simple as with Perforce or Arch. I subscribe to the subversion dev mailing list and I think it's probably at least another 1-2 years before Subversion has merging capabiliies on par with Perforce, Arch,
If you're interested in doing lots of merging with Subversion then you'll want to look at svnmerge (http://www.dellroad.org/svnmerge/index). I haven't used it but it gets good marks from the svn users mailing list.
seth
The submitter was complaining that the SVN utilities lack features available in the party CVS utilities; such as SVNweb vs CVSweb.
:)
He wasn't complaining that SVN itself lacks useful features available in CVS. There are enough improvements (Atomic commits, versioning of directories and permissions) in SVN over CVS that switching to the new system is compelling.
The utilities don't all need to work now anyways.
Any sort of large-scale migration like this is done in phases. Phase 1, switch the repository. Phase 2, switch the utilities, Phase 3, cleanup
94% of Repubs and 21% of Dems voted to renew the Patriot Act
If you setup SSL on the web server, they should be able to check out just fine using an https:/// url, as the firewall will have no idea what PROPFINDs are flying around.
The disadvantage of the filesystem back end is the proliferation of files. You get a new file with every commit. You need to be careful that your file system works well with a directory that might contain tens of thousands of files.
But you shouldn't lose a repository if bdb corrupts -- you should just lose the commits since the last backup. If you're running without backups, then you'd better watch out for hardware failures, system theft, fires, floods, etc.
Trac provides a nice web based diff tool and a bunch of other features.
SVK works well with subversion, and has support for star merges. The ability to work offline is another cool bonus. On the flip side, documentation kinda sucks right now, but its command set for every day use works in pretty much the same way as subversion's.
Subversion is being developed by the people who created CVS. They recognized
CVS's limitations and decided that it would be more painful to fix CVS than
it would be to start from scratch.
But don't worry about CVS, it'll be around for a long time to come.
*sigh* back to work...
Well depends on how you see it, the devs currently are busy to implement everything which the eclipse CVS plugin can do, which is quite a lot. They are 95% there with small functionalities missing.
Nevertheless the plugin people usually deliver a new javasvn and subclipse version within a few days timeframe of a new svn version, and currently the plugin is pretty much the best svn crossplatform client you can get.
The fact that Subversion is "behind the curve" was one of its major selling points, as that means the design has had time to be tested, and as such we could be relatively assured that there were no major bugs lurking around.
In addition, Subversion "feels just like CVS", which was another major reason KDE made the switch. Many of KDE's most valuable contributors aren't programmers, and they generally use a GUI frontend to CVS instead of the client, so we needed something that was similar enough to what they were used to.
Then of course there are the concerns about the performance of managing one of the single largest code bases in open source, but I'm not qualified to talk about the performance of your suggestions, only to say that Subversion seems to be fast enough.
FSFS